0

On a GitHub project I administer, someone made the mistake (due to a mis-communication in directions) of adding a really large audio-file to the project - causing the project (which is less than a month old) to have a bloated repository - of a level of bloat that rivals projects that have been around much longer and cover a much wider scope.

Upon researching, I have found that the only action I can take that would remove that commit not just from the present version of the project, but from it's entire history (which I would have to do if I am to rescue the project from this bloat) involves a force-push.

My question is this -- is a force-push an action that only the administrator/owner of a GitHub project can do, or something that anyone authorized as a contributor can do? And if so, any precautions I could take against misuse of such a feature (i.e. use by anyone other than the project administrator) while still allowing it's proper use (i.e. use by the project administrator)?

Granted -- I do not believe the individual in question will mis-use such a feature. I suppose it's not impossible, as nobody's actions can be 100% predicted - but I feel fairly confident that it's very unlikely. However, as time goes on in the future, the further into the future I go, the more likely it is that I will make the mistake of trusting someone who would mis-use such a feature -- so I consider it best to know now how much the danger is - and if the danger is real, what precautions I can take against it.

Sophia_ES
  • 1,193
  • 3
  • 12
  • 22
  • Are you using GitHub Enterprise? Do you have a user account or an organization account? See https://help.github.com/articles/what-are-the-different-access-permissions – jub0bs Sep 25 '14 at 18:55
  • My question is very specifically about doing a force-push. Neither the page you point to nor *either* of the pages *it* points to even *mentions* a force-push. Therefore, the link you gave me doesn't at all address my question. – Sophia_ES Sep 25 '14 at 21:27
  • The answer to your question will likely depend on what you're using; hence the link. So, what type of account are you using? – jub0bs Sep 25 '14 at 21:30
  • My GitHub account is a free account. ---- oops --- pressed [return] prematurely. – Sophia_ES Sep 25 '14 at 21:37
  • My GitHub account is a free account. I don't mind anyone being able to *see* what's in the repository since the project is Open Source -- just with being able to rescue the project from an over-bloating commit without opening the door to someone else clearing the history of things that *do* need to be there. As for whether it is a user or an organization account -- it is currently a user account, but I am willing to switch it over to an organization account if that will solve my problem. – Sophia_ES Sep 25 '14 at 21:41
  • This appears to be a duplicate of [GitHub - prevent collaborators from using push -f](http://stackoverflow.com/questions/5094524/github-prevent-collaborators-from-using-push-f) – remram Sep 26 '14 at 02:53
  • Yes, we need to avoid redundant questions. But being *too* hasty to regard a question as a "duplicate" also has it's dangers. -- For starters, there can be questions that at first-glance seem very similar, but which (if read carefully) important differences can be found. -- Even more relevant in this case is the fact that the other question and it's answer are over 3 years old, which is a long time considering the rate at which Git is currently evolving. Even if the question was identical (which they are not) a correct answer from 3 years ago could not be trusted to be current now. – Sophia_ES Sep 26 '14 at 03:43
  • 1
    You asked one question, then you added other questions. That's not how you ask questions and it should instead focus on the one thing. Now you're asking too broad. – random Sep 26 '14 at 12:42
  • possible duplicate of [Github, Collaborators have commit access?](http://stackoverflow.com/questions/5010754/github-collaborators-have-commit-access) – jub0bs Sep 26 '14 at 18:15
  • @Jubobs - that question is *also* over 3 years old - as is the answer provided. Do the procedures of StackExchange *seriously* not take into account how much can change in Git during three years during this phase of it's life? Please people, check the date of other questions before suggesting that this one is a duplicate of it. – Sophia_ES Sep 27 '14 at 15:43
  • @Sophia_ES Please keep cool, and see my answer. – jub0bs Sep 27 '14 at 16:20
  • @Jubobs - Sorry it's been so long - been a crazy day. Just looked at your answer -- and yes, it answers my question. The danger I perceived does exist - so now I must assess the pros and cons of my possible risk-minimization strategies. I can either use the strategy you suggest (has it's pros and cons) or I can once in a while burn a CD/DVD of the repository as is. --- As for my mood during my previous comment - I apologize that over a text-only communication I seemed to be more upset than I was and/or would have seemed in person. (More in next comment.) – Sophia_ES Sep 28 '14 at 16:25
  • @Jubobs - When I asked if StackOverflow has a way of taking into account how much something like Git could have changed over the past three years (and even if this particular issue hasn't changed, a lot else in Git has -- like issues pulling and pushing from shallow clones has changed over the past year - and is likely to change further in the nest year or so as post-1.9.0 Git versions are more promulgated) --- Was just asking of StackOverflow has a way of revisiting questions already answered but which *might* be out-of-date - & suggesting such a protocol is needed if it doesn't exist. – Sophia_ES Sep 28 '14 at 16:31

1 Answers1

0

Is a force-push an action that only the administrator/owner of a GitHub project can do, or something that anyone authorized as a contributor can do?

Free and paid GitHub accounts

The answer to your question depends on the type of GitHub account you're using. You write, in your comment, that you're using a free account. Such an account doesn't allow you much control; it doesn't even allow you to set the receive.denyNonFastFowards switch in order to forbid all force pushes; although, apparently, GitHub staff will set it for you if you send them an email.

A paid, GitHub-Enterprise account will give you finer control over force pushes: with such an account, you can specify which collaborators are allowed to force-push to which branches in which repositories.

If you're not willing to switch to a paid account...

If you and your collaborators are set on working with free accounts, I think you're going about it the wrong way: you should move away from the centralized workflow you're currently using,

enter image description here

and adopt an Integration-Manager workflow.

enter image description here

In this workflow, instead of having one canonical repository that all collaborators can push to,

  • each collaborator has her/his own public repository (or fork) that only s/he can (force-)push to;
  • some trusted collaborator (you, in his scenario), is responsible for integrating changes from contributors into the blessed/canonical repository.

If you use the Integration-Manager workflow (or the more sophisticated Dictator-and-lieutenants workflow), you will no longer step on each other's toes.

(Diagrams are taken from the Pro Git book, chapter 5 - Distributed Git.)

Community
  • 1
  • 1
jub0bs
  • 60,866
  • 25
  • 183
  • 186
  • Thank you for making it clear - the danger I was concerned about does exist. You have let me know the danger exists and offered one strategy for dealing with it. I now know I must weigh the pros and cons versus the strategy you offer versus one other possible strategy - once in a while burning a CD/DVD of the repository as-is. – Sophia_ES Sep 28 '14 at 16:35
  • I think you should adopt the Integration-Manager workflow, and set up some backup strategy for that repository, but burning a CD/DVD for that seems so antiquated. Don't hesitate to also upvote my answer. – jub0bs Sep 28 '14 at 16:39
  • For the old thing to be antiquated, it's not enough for a newer thing to exist. The newer thing would have to be unambiguously better for any situation -- in short, the newer alternative would have only pros and no cons. Now, it is possible that the pros of the Integration-Manager workflow outweigh the cons (I am still evaluating that) -- but to call burning a CD/DVD an antiquated solution is kinda a denial that the cons nonetheless exist. The Integration-Manager workflow seems like a *lot* more work every time someone makes even a *small* contribution. – Sophia_ES Sep 29 '14 at 22:34
  • Actually - I've been thinking since my last comment --- you're probably right. Yes, the Integration-Manager workflow *does* involve a lot more work every time someone makes a contribution --- however, it is *possible* that I *might* be able to write a suite of scripts that will take most of this work off the hands of human-beings --- thereby in *effect* having a project to which all collaborators can push but only the *leader* of the project can force-push. – Sophia_ES Sep 29 '14 at 23:11