On undoing, fixing, or removing commits in git
sethrobertson.github.io
On undoing, fixing, or removing commits in git
1–10 of 74 posts
Re: On undoing, fixing, or removing commits in git
#2sigh it seems to me that Git is unnecessarily complicated. Wonder what if "github" started with HG.
Re: On undoing, fixing, or removing commits in git
#3sigh it seems to me that Git is unnecessarily complicated. Wonder what if "github" started with HG.
in many ways hg is superior, but you can't win with Linus blessing.
Re: On undoing, fixing, or removing commits in git
#4sigh it seems to me that Git is unnecessarily complicated. Wonder what if "github" started with HG.
Hg is working on a feature that is betaish right now:
http://mercurial.selenic.com/wiki/ChangesetEvolution
It's been brewing for some time. Basically, the idea is to be able to make it easy to safely edit history collaboratively, with a consistent UI. Facebook is pumping a lot of money into hg right now, and seems particularly interested in getting this feature off the ground.
A number of pieces have been falling into place for this to occur. The first was to have phases, indicators of which commits are safe to edit collaboratively or not, a feature that some git users have wanted:
https://github.com/peff/git/wiki/SoC-2012-Ideas#published-an...
Mercurial now has this feature and uses it as part of the logic for the evolve extension. With this in place, hg is able to transmit metadata that indicates automatically which commits need to be fixed up if you want to edit a commit that someone else has also edited, or if someone edited a commit on top of which you've based off other commits.
The idea is to make something like "git push --force" obsolete. History is safe to edit, and commits can't get lost, not even by accident:
http://www.infoq.com/news/2013/11/use-the-force
By the way, an epilogue to that Jenkins story is that it wasn't completely trivial to recover all lost history, and at least for some of the smaller repos, they never managed to figure out exactly which version was the canonical one.
Re: On undoing, fixing, or removing commits in git
#5sigh it seems to me that Git is unnecessarily complicated. Wonder what if "github" started with HG.
I love this kind of attitude: something seems complex? Throw it out and start again!
Unfortunately, it's usually the problem domain that is complex and starting over just means you have to rediscover all of that complexity all over again. HG has more than its fair share of complicated tasks.
Re: On undoing, fixing, or removing commits in git
#6sigh it seems to me that Git is unnecessarily complicated. Wonder what if "github" started with HG.
Anyone unfamiliar with the most basic of workflows would find this needlessly complex. Just a couple of months ago, I would have.
Now that I have familiarity with local branching, remote branches, how the 3-way merge works (conceptually) and rebasing, this article comes off as a guide on how to do things that you wouldn't have to do to often anyways.
Re: On undoing, fixing, or removing commits in git
#7Usability note: after a few clicks through this (so my path had a few entries) I instinctively clicked up a few levels in the path expecting to be taken to that point. Instead, that entry was appended as another child.
Re: On undoing, fixing, or removing commits in git
#8sigh it seems to me that Git is unnecessarily complicated. Wonder what if "github" started with HG.
Git is designed for project maintainers, and a lot of the complication is necessary for them (that view helps me, at least)
Re: On undoing, fixing, or removing commits in git
#9"Strongly consider taking a backup of your current working directory and .git to avoid any possibility of losing data as a result of the use or misuse of these instructions."
WTF?
What is the point of a version control system if you have to take backups of it to avoid losing data when performing certain operations?
I use git, I like git, but certain aspects of it are fundamentally broken.
Re: On undoing, fixing, or removing commits in git
#10"Strongly consider taking a backup of your current working directory and .git to avoid any possibility of losing data as a result of the use or misuse of these instructions." WTF? What is the point of a version control system if you have to take backups of it to avoid losing data when performing certain operations? I use git, I like git, but certain aspects of it are fundamentally broken.
Git is quite safe, and most operations that involve doing things to history can be undone. Unsafe operations happen when the working tree and uncomitted changes are involved.
Also, sometimes it's easier for a user to roll back to an older back up than to untangle the mess they have created.
Third, git itself is not a backup. When your repository gets corrupted, you're out-of-luck when you don't have backups for those files. So it's still good to take backups of your repositories.