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

41–50 of 74 posts

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

#41

Post by mikeash »

rajivm wrote: post #33
mikeash wrote: post #32

Earlier quoted context omitted.

I'm not discounting it, I simply don't agree with how git implements it. IMO the correct option is to create a new repository that has the same history as the old repository minus the offending commit (or possibly with an edited version of that commit that leaves out the offending string). Because it creates a new repository, there's no risk of data loss in your old repository. Once you're confident that the operatio…

Re: 1 and 2 1) This is almost true. Anything that is committed to Git is recoverable. When you "re-write" history, Git is creating a new set of commits in the history, an "alternate history path." It does not destroy the original commits, but there is no named reference to them (unless you created a branch/tag pointing to this line of commits). 2) In this case, if you want to actually destroy these unreferenced commi…

Since garbage collection does happen automatically after a while, it seems that the "doesn't destroy data" bit isn't completely true. But I understand that it's a fairly rare case where you're going to screw something up and then not bother to get it back until after garbage collection cleans it up.

Thanks for clarifying that.

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

#42

Post by ams6110 »

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.

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.

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

#43

Post by Myrmornis »

simcop2387 wrote: post #35
crazygringo wrote: post #16

Earlier quoted context omitted.

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…

An easy way to do that, is the way I tend to do it; Create a new branch based off the one you're rewriting history in, and that will actually keep all of that for you even after you rewrite it all. Makes it really easy to restore later with git reset if you need it.

Yes, this is how beginners should be taught to "back up" in git.

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

#44

Post by mcv »

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.

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

#45

Post by mcv »

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.

Backups are of course always a good idea, but you don't need them specifically to work with git. Git is its own backup system. If you think you might do something potentially harmful, do it in a new branch. If something goes wrong, you can always throw it away.

If something has already gone wrong, and you didn't do it in a separate branch, you can still go back to a previous situation.

Rewriting history in any serious sense (beyond a local reset or rebase for stuff that hasn't been pushed to anyone else yet) is always a bad idea. History is history for a good reason.

Of course any existing commit can always be reverted; that's not rewriting history. A revert is simply a new commit.

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

#46

Post by crystaln »

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

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.

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.

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

#47

Post by mtdewcmu »

sofal wrote: post #37
mikeash wrote: post #32

Earlier quoted context omitted.

I'm not discounting it, I simply don't agree with how git implements it. IMO the correct option is to create a new repository that has the same history as the old repository minus the offending commit (or possibly with an edited version of that commit that leaves out the offending string). Because it creates a new repository, there's no risk of data loss in your old repository. Once you're confident that the operatio…

I know a lot of people who routinely edit their local history before pushing changes to a shared repository because they don't want other people to see their true "dirty" history. This is insane. This is no more insane than editing a source code file before you save it to the file system. Git is used as a development tool as well as version control, and developers are therefore encouraged to commit often, even if the…

Is the history stored as a text file somewhere that you can just edit? I sometimes wish git were a bit more transparent and less of a black box.

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

#48

Post by mtdewcmu »

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

You probably wanted `git merge --abort`. It's not very clear what the various states are that git can be in. There seems to be a 'fixing merge conflict' state, and it's hard to find documentation that warns you about this state and what your options are once you're in it.

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

#49

Post by mtdewcmu »

lomnakkus wrote: post #36
crystaln wrote: post #20

Earlier quoted context omitted.

I'm not 100% sure this is true, however it is also a fundamental flaw of git. There should be a way to remove commits permanently in order to remove mistakenly checked in large files or private content. It's also definitely not true with uncommitted changes, including gitignored files.

git filter-branch will let you remove content permanently and irrecoverably if you really need to. Regarding uncommitted changes: This is in the same category as forgetting to do your backup before starting to mess around, IMO. I would encourage anyone to simply get used to committing extremely often and just using a quick interactive rebase before pushing.

At the last job where I used git, I'd work in a separate branch, and I started using `git merge --squash` to merge into the main branch to keep the history from getting too difficult to follow. When git merges a bunch of different histories into one, it becomes almost impossible to make sense of if people make lots of small commits. I shy away from `git rebase`, because it seems dangerous.

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

#50

Post by mtdewcmu »

pyre wrote: post #24
mikeash wrote: post #11

Earlier quoted context omitted.

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…

It might be a better idea to just change the password.
Post reply on HN