

Git solves all your problems....Almost - eVizitei
http://codeclimber.blogspot.com/2009/05/git-solves-all-your-branching-and.html

======
kailoa
Stories like the above are way too common.

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.

~~~
lnguyen
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.

BTW, here's what they should have done:

    
    
      git checkout -b last_good_version [commit]
      git push --force origin last_good_version:master
    

Preserves the local history but fixes the issue on GitHub.

They probably should also do a few things like:

    
    
      git branch -m master master_merge_v2
      git branch -m last_good_version master
    

to avoid messing things up with the next push

~~~
dasil003
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?

~~~
pieter
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.

~~~
lnguyen
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:

    
    
      git fetch origin
      git branch -m master master_merge_v2
      git checkout -b --track master origin/master
    

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.

------
bradgessler
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?

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...](http://www.kernel.org/pub/software/scm/git/docs/v1.6.2.3/howto/revert-
a-faulty-merge.txt) 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 :)

