Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On undoing, fixing, or removing commits in git

sethrobertson.github.io

Post reply on HN
Print view View original

21–30 of 74 posts

Re: On undoing, fixing, or removing commits in git

#21

Post by crystaln »

tytso wrote: post #15
rebelidealist wrote: post #2

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

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 d…

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.

Re: On undoing, fixing, or removing commits in git

#23

Post by pyre »

crystaln wrote: post #22

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.

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

Re: On undoing, fixing, or removing commits in git

#24

Post by pyre »

mikeash wrote: post #11
_ikke_ wrote: post #10

Earlier quoted context omitted.

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…

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 h…

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.

Re: On undoing, fixing, or removing commits in git

#25

Post by zimbatm »

mikeash wrote: post #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.

git is safe but you have to know all the fancy commands like `git reflog`. I remember being puzzled by a merge conflict when I started learning git. I didn't know what it was and `git reset` or `git revert` weren't doing what I expected. All I wanted was to go back to the previous state. In the end it was easier to clone the repo and start over again.

Re: On undoing, fixing, or removing commits in git

#26

Post by sisk »

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

Re: On undoing, fixing, or removing commits in git

#27

Post by nknighthb »

mikeash wrote: post #19
nknighthb wrote: post #14

Earlier quoted context omitted.

1) Why are you taking a be-careful-don't-blame-me passage from a random article written by some guy as gospel? 2) All version control systems are vulnerable to data loss if you mess around with them in unusual ways. Would you say svn was fundamentally broken if somebody told you to take a backup before you screwed around with the repo?

1) It's the sort of thing I've heard many times from many people over the years. 2) The difference is that svn does not build this functionality into the main command line tool, and there is no culture of doing terrible things with svnadmin to edit svn repositories the way there is of doing terrible things with git to rewrite git history.

I can't agree that UI quibbles and your perception of the "culture" (a perception I don't share at all) are "fundamental flaws" in git.

Re: On undoing, fixing, or removing commits in git

#28

Post by zimbatm »

crazygringo wrote: post #16
mikeash wrote: post #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.

I understand your puzzlement, I found this confusing too at first. But then I realized it makes sense -- one of git's strengths is that you can rewrite the history. The " point " of a version control system, at least with git, is not backup which retains all history, but rather versioning which retains the history you want to retain. Obviously, if you choose not to edit the history, then you never need to back up in…

Actually `git reflog` contains the HEAD history. Even after a rebase it's possible to checkout to an old commit (unless git has garbage-collected).

Re: On undoing, fixing, or removing commits in git

#29

Post by perlgeek »

mikeash wrote: post #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.

On piece of data that is easy to lose, with any version control system I've worked with so far, is uncommitted data. And that's also the only data I've lost with git so far, after using it for several years. (And yes, it was my own stupidity, saying 'git checkout .' and only noticing later that there was something I wanted to keep).

The advise to take a backup doesn't hurt, and might be helpful if restoring the original state is more effort than doing it with git operations.

Re: On undoing, fixing, or removing commits in git

#30

Post by Crito »

crystaln wrote: post #21
tytso wrote: post #15

Earlier quoted context omitted.

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 d…

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.

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.

Post reply on HN