8 ms·

On undoing, fixing, or removing commits in git

105 points by DanielShir 13y ago

rebelidealist 13y ago
sigh it seems to me that Git is unnecessarily complicated. Wonder what if "github" started with HG.
- lukasm 13y ago
  in many ways hg is superior, but you can't win with Linus blessing.
- jordigh 13y ago
  Hg is working on a feature that is betaish right now: http://mercurial.selenic.com/wiki/ChangesetEvolution 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-and-secret-commits 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 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.
- RyanZAG 13y ago
  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.
- skylan_q 13y ago
  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.
- pseut 13y ago
  Git is designed for project maintainers, and a lot of the complication is necessary for them (that view helps me, at least)
- tytso 13y ago
  There are two ways things can be simple or complicated. One is to have a big button labelled "DWIM", which always does the right thing --- until it doesn't, and then you have to go out of your way to work around its assumption of what you want to do. The other way is to have a number of simple concepts which can be combined in various powerful ways. Once you understand these simple concepts, you can compose them to do whatever you need. Git is simple the same way that RISC is simple, and having a manual transmission is simple. You can do a lot more with a manual transmission car than you can with an automatic --- but if you're not careful you can strip the gears. Yet a manual transmission is simpler to maintain, and more efficient (in the hands of someone who knows how to use it) than a automatic transmission. If you take a look at the post, you'll see that the various recipes only use a handful of git commands. Once you've mastered those commands, things are indeed quite simple.
  - crystaln 13y ago
    That would be true if git's command line interface were not so inconsistent and obtuse. I agree the underlying concepts are simple, which is why the command line interface is so baffling.
    - Crito 13y ago
      The standard git porcelain has it's problems, but they are largely irrelevant to the question of git's simplicity. Issues like --all/-A, or the -b flag of git-commit are unfortunate, but they do not affect the underlying simplicity that tytso is talking about. That underlying simplicity is what makes git a pleasure to work with despite weird porcelain because it allows you to reason about operations in git without reasoning about what different commands are for or can do. If you want to know if some operation can be done, you don't reason about git-reset, git-checkout, git-branch, etc.. you reason about the DAG. After you have a solid mental image of what you are attempting to do to the DAG, it is a simple matter to decompose that action into a few weird but ultimately simple incantations with the porcelain. If you are interested in optimizing how many steps you decompose operations into, then you can learn the esoteria of a few git operations, but all of the hard thinking, the real problem-solving, was done in the context of a different abstraction.
caipre 13y ago
Usability 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.
mikeash 13y ago
"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.
- _ikke_ 13y ago
  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.
  - mikeash 13y ago
    First, your use of the word "most" is inherently incompatible with the phrase "quite safe". Second, why would a version control system make it so difficult to roll back to an old version that it's easier to restore from backup? This is insane. Third, I'm well aware of this, and of course you should be making backups of your git repositories (and everything else). But those backups should be there to protect against hardware failure and other external data-loss events, not protect against git itself.
    - pyre 13y ago
      You're discounting the idea that someone might want to destructively rewrite their history. Here's an example: What if you want to retain history, but remove a password that was hardcoded into a source file? The simple options are: - Remove the hard-coded password, and create a new repository with the current state of the code as a starting point. - Start a new repository with the current code state, but keep the old repository around under lock-and-key, then perform 'complex' patch operations to move changes between the two repositories (e.g. roll back to a previous version of a file before the cut-off). - Go back through your history, and manually create a new repository from each patch, but removing the password when you get to that commit. If git always preserves all history, no matter what, then these are your only options. While operations like `git-filter-branch` sound scary, they don't delete the commit objects from your .git folder. If you created a new branch called (e.g.) master-old because running `git-filter-branch` on your repository, then you can always 'rollback' to master-old if you end up in failure. Or slightly more complex, you could use the reference listing in the reflog to 'rollback' the changes.
crystaln 13y ago
The inability to, in any remotely easy way, remove mistakenly checked in large files and private data has always seemed like a major flaw with git.
- pyre 13y ago
  Well, the solution to other systems seems to be "it's checked in, therefore it can never be un-checked-in, so deal with it!" (or at least this is the attitude of some vocal proponents of them).
- ams6110 13y ago
  The flaw is in having this "private" data in a public repo to begin with. If your data are private, don't put your project on github.
  - crystaln 13y ago
    While I'm certain you and your organization have a perfect record of never checking inappropriate things into your git repository, mine does not. Even if all the employees at your company were perfect, there is still a chance of inappropriate information getting into the repository.
sisk 13y ago
Regarding losing data: it's as simple as diving into the reflog. In order to remove something from your history, you must do so very explicitly by walking your commit history, editing each one. There is an automated workflow to accomplish that (`filter-branch`) but it's definitely not a command anyone I know has committed to memory. Accidental mutations can be undone either by `--abort`ing (if the command supports it) or by checking out an earlier revision from the reflog. The GC in git is pretty conservative and, while it can be triggered manually, still makes you jump through some hoops to actually get rid of something. Steve Klabnik wrote about it[1] a little while back. In certain cases, you don't have access to the reflog because a change wasn't made locally. Perhaps someone screwed up a remote you pull from and it destroyed your history. You can, even still, find, view, and re-associate orphaned objects. Yeah, it's not terribly intuitive and, again, not a workflow anyone has probably committed to memory, but the fact that you can recover from a disaster of that magnitude is pretty amazing. git provides we developers with a set of tools—powerful tools—and that comes with a level of responsibility. I'd rather have the ability to responsibly clean my history than the alternative. [1] - http://words.steveklabnik.com/git-history-modification-and-libuv http://words.steveklabnik.com/git-history-modification-and-l...
rspeer 13y ago
Thanks, this is a useful reference. I am sad about some of these other comments, which I might paraphrase as "This doesn't help me, and it might help people who are less skilled than me who don't deserve to be helped, therefore it's worthless". It's apparently a common sentiment on this site, but it shouldn't be.
mcv 13y ago
Rule number one: if you're not sure what you're doing, do it in a new branch. If things go wrong, you can always delete that branch. And you can always make a branch out of a previous situation. Gitk/gitx make this particularly easy.
elwell 13y ago
Sentence 2 has typo "or" -> "of"

105 points by DanielShir 13y ago

rebelidealist 13y ago

sigh it seems to me that Git is unnecessarily complicated. Wonder what if "github" started with HG.

lukasm 13y ago
in many ways hg is superior, but you can't win with Linus blessing.
jordigh 13y ago
Hg is working on a feature that is betaish right now: http://mercurial.selenic.com/wiki/ChangesetEvolution 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-and-secret-commits 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 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.
RyanZAG 13y ago
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.
skylan_q 13y ago
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.
pseut 13y ago
Git is designed for project maintainers, and a lot of the complication is necessary for them (that view helps me, at least)
tytso 13y ago
There are two ways things can be simple or complicated. One is to have a big button labelled "DWIM", which always does the right thing --- until it doesn't, and then you have to go out of your way to work around its assumption of what you want to do. The other way is to have a number of simple concepts which can be combined in various powerful ways. Once you understand these simple concepts, you can compose them to do whatever you need. Git is simple the same way that RISC is simple, and having a manual transmission is simple. You can do a lot more with a manual transmission car than you can with an automatic --- but if you're not careful you can strip the gears. Yet a manual transmission is simpler to maintain, and more efficient (in the hands of someone who knows how to use it) than a automatic transmission. If you take a look at the post, you'll see that the various recipes only use a handful of git commands. Once you've mastered those commands, things are indeed quite simple.
- crystaln 13y ago
  That would be true if git's command line interface were not so inconsistent and obtuse. I agree the underlying concepts are simple, which is why the command line interface is so baffling.
  - Crito 13y ago
    The standard git porcelain has it's problems, but they are largely irrelevant to the question of git's simplicity. Issues like --all/-A, or the -b flag of git-commit are unfortunate, but they do not affect the underlying simplicity that tytso is talking about. That underlying simplicity is what makes git a pleasure to work with despite weird porcelain because it allows you to reason about operations in git without reasoning about what different commands are for or can do. If you want to know if some operation can be done, you don't reason about git-reset, git-checkout, git-branch, etc.. you reason about the DAG. After you have a solid mental image of what you are attempting to do to the DAG, it is a simple matter to decompose that action into a few weird but ultimately simple incantations with the porcelain. If you are interested in optimizing how many steps you decompose operations into, then you can learn the esoteria of a few git operations, but all of the hard thinking, the real problem-solving, was done in the context of a different abstraction.

caipre 13y ago

Usability 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.

mikeash 13y ago

"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.

_ikke_ 13y ago
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.
- mikeash 13y ago
  First, your use of the word "most" is inherently incompatible with the phrase "quite safe". Second, why would a version control system make it so difficult to roll back to an old version that it's easier to restore from backup? This is insane. Third, I'm well aware of this, and of course you should be making backups of your git repositories (and everything else). But those backups should be there to protect against hardware failure and other external data-loss events, not protect against git itself.
  - pyre 13y ago
    You're discounting the idea that someone might want to destructively rewrite their history. Here's an example: What if you want to retain history, but remove a password that was hardcoded into a source file? The simple options are: - Remove the hard-coded password, and create a new repository with the current state of the code as a starting point. - Start a new repository with the current code state, but keep the old repository around under lock-and-key, then perform 'complex' patch operations to move changes between the two repositories (e.g. roll back to a previous version of a file before the cut-off). - Go back through your history, and manually create a new repository from each patch, but removing the password when you get to that commit. If git always preserves all history, no matter what, then these are your only options. While operations like `git-filter-branch` sound scary, they don't delete the commit objects from your .git folder. If you created a new branch called (e.g.) master-old because running `git-filter-branch` on your repository, then you can always 'rollback' to master-old if you end up in failure. Or slightly more complex, you could use the reference listing in the reflog to 'rollback' the changes.

crystaln 13y ago

The inability to, in any remotely easy way, remove mistakenly checked in large files and private data has always seemed like a major flaw with git.

pyre 13y ago
Well, the solution to other systems seems to be "it's checked in, therefore it can never be un-checked-in, so deal with it!" (or at least this is the attitude of some vocal proponents of them).
ams6110 13y ago
The flaw is in having this "private" data in a public repo to begin with. If your data are private, don't put your project on github.
- crystaln 13y ago
  While I'm certain you and your organization have a perfect record of never checking inappropriate things into your git repository, mine does not. Even if all the employees at your company were perfect, there is still a chance of inappropriate information getting into the repository.

sisk 13y ago

Regarding losing data: it's as simple as diving into the reflog. In order to remove something from your history, you must do so very explicitly by walking your commit history, editing each one. There is an automated workflow to accomplish that (`filter-branch`) but it's definitely not a command anyone I know has committed to memory. Accidental mutations can be undone either by `--abort`ing (if the command supports it) or by checking out an earlier revision from the reflog. The GC in git is pretty conservative and, while it can be triggered manually, still makes you jump through some hoops to actually get rid of something. Steve Klabnik wrote about it[1] a little while back. In certain cases, you don't have access to the reflog because a change wasn't made locally. Perhaps someone screwed up a remote you pull from and it destroyed your history. You can, even still, find, view, and re-associate orphaned objects. Yeah, it's not terribly intuitive and, again, not a workflow anyone has probably committed to memory, but the fact that you can recover from a disaster of that magnitude is pretty amazing. git provides we developers with a set of tools—powerful tools—and that comes with a level of responsibility. I'd rather have the ability to responsibly clean my history than the alternative. [1] - http://words.steveklabnik.com/git-history-modification-and-libuv http://words.steveklabnik.com/git-history-modification-and-l...

rspeer 13y ago

Thanks, this is a useful reference. I am sad about some of these other comments, which I might paraphrase as "This doesn't help me, and it might help people who are less skilled than me who don't deserve to be helped, therefore it's worthless". It's apparently a common sentiment on this site, but it shouldn't be.

mcv 13y ago

Rule number one: if you're not sure what you're doing, do it in a new branch. If things go wrong, you can always delete that branch. And you can always make a branch out of a previous situation. Gitk/gitx make this particularly easy.

elwell 13y ago

Sentence 2 has typo "or" -> "of"