Git solves all your problems....Almost | Hacker News Reader

Git solves all your problems....Almost

codeclimber.blogspot.com

13 pointseVizitei6 comments

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.

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

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:

  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.

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... 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 :)

Reply on news.ycombinator.com