Despite how fantastic the tool is, git's biggest weakness is it's own opacity and steep learning curve. github's real magic is in indirectly getting git out of the way of the common coder. Sometimes it's through the GUI, and sometimes it's with helpful guides.
I suppose, when the core audience and developers are linux kernel hackers, usability is not going to be a priority.
The git commands, etc. are actually pretty straightforward. What usually causes the issues is thinking about branches. That can be a little hard to wrap your head around especially when you throw in remote repositories.
Since I've never had to do this, what happens to the downstream repos that have already pulled the bad merge? Can they do a similar git pull --force to sync up?
Nope. If they're not careful (or don't know), they'll just merge in the bad commits on the next pull. They'll have to know in advance, and do some manual resetting or use a rebase call.
This is one of problems with changing history in a "master" repository. In this case, it's necessary in order to fix a problem.
Odds are since they're reverting back to an earlier commit on the master branch, anyone who does a pull might not notice the change since they're "ahead" in their history which is okay from the standpoint of the pull (using merge). This will cause a problem for any later push since they'll place the bad commits right back into the GitHub repo. [I'd like to put together a test scenario for this to be 100% but I'm not set up for that at the moment.]
Doing a rebase will lead to the "unmerging" conflicts that they had encountered and caused all their frustration.
Everyone needs to be notified to move (rename) their current master and recreate a master tracking branch:
This just solves the problem with the master branch. Any local development branch based directly off the master will need to be rebased. Or they can create a new development branch and cherry-pick.
You can't undo history like he wanted to in a distributed version control system like git. Rather, you have to revert the content/data while moving the history forward. Resets and rebasing will only work locally if the commits haven't been pushed out to remote branches. If you could just "undo" history, how would git know?
To Ethan's credit, Git is pretty difficult to use until you understand the model behind trees, commits, and blobs. I've been in his shoes where I blew away a bunch of work and screwed up everybody's remote branches :)
6 comments
[ 3.1 ms ] story [ 24.0 ms ] threadDespite how fantastic the tool is, git's biggest weakness is it's own opacity and steep learning curve. github's real magic is in indirectly getting git out of the way of the common coder. Sometimes it's through the GUI, and sometimes it's with helpful guides.
I suppose, when the core audience and developers are linux kernel hackers, usability is not going to be a priority.
BTW, here's what they should have done:
Preserves the local history but fixes the issue on GitHub.They probably should also do a few things like:
to avoid messing things up with the next pushOdds are since they're reverting back to an earlier commit on the master branch, anyone who does a pull might not notice the change since they're "ahead" in their history which is okay from the standpoint of the pull (using merge). This will cause a problem for any later push since they'll place the bad commits right back into the GitHub repo. [I'd like to put together a test scenario for this to be 100% but I'm not set up for that at the moment.]
Doing a rebase will lead to the "unmerging" conflicts that they had encountered and caused all their frustration.
Everyone needs to be notified to move (rename) their current master and recreate a master tracking branch:
This just solves the problem with the master branch. Any local development branch based directly off the master will need to be rebased. Or they can create a new development branch and cherry-pick.Had Ethan read about git-revert he might have stumbled into this link http://www.kernel.org/pub/software/scm/git/docs/v1.6.2.3/how... that explains in more detail.
To Ethan's credit, Git is pretty difficult to use until you understand the model behind trees, commits, and blobs. I've been in his shoes where I blew away a bunch of work and screwed up everybody's remote branches :)