Git solves all your problems....Almost
codeclimber.blogspot.com
Git solves all your problems....Almost
1–7 of 7 posts
Re: Git solves all your problems....Almost
#2Despite 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.
Re: Git solves all your problems....Almost
#3Stories 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.
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 pushRe: Git solves all your problems....Almost
#4Stories 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 prob…
Re: Git solves all your problems....Almost
#5Earlier quoted context omitted.
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 prob…
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?
Re: Git solves all your problems....Almost
#6Had 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 :)
Re: Git solves all your problems....Almost
#7Earlier quoted context omitted.
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.
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.