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

51–60 of 74 posts

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

#51

Post by mtdewcmu »

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…

It's hard to know how elegant and simple something can be made. git is a nice tool, but we shouldn't assume that it's the last word and can't be improved upon.

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

#53

Post by pyre »

mtdewcmu wrote: post #50
pyre wrote: post #24

Earlier quoted context omitted.

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.

There is a point past which you can be too pedantic and be confused with a troll. I think that you may be straddling that line.

Next time, rather than just assume that the poster isn't smart enough to realize that a compromised password should be changed, maybe you could take in the fact that it's probably just an example of data that you might want to extract from your history if it's automatically there. I can think of numerous scenarios where someone might want to remove a password from the history even if it's not compromised (e.g. want to publish a private repo).

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

#54

Post by phaemon »

mikeash wrote: post #40
phaemon wrote: post #34

Earlier quoted context omitted.

You don't actually know how git implements it, so how can you disagree with it? There is no such thing as "an edited version" of a commit. A commit is identified by a SHA1 hash of its index of contents. If you change one bit you get a new commit . You're a C programmer, right? If someone gave you a specification for writing a program to implement git, without telling your what it was, you'd tell them it would take 2…

I understand how it works. Of course there's such thing as "an edited version" of a commit: it's a new commit that you create by taking an existing one and altering it. If you want to argue about terminology, please be my guest, but that's all your dispute is.

If you know how it works then where did your last question come from? The bit you're "confused" about?

It's obvious what the answer is if you know how it works, so what was your point exactly?

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

#55

Post by pyre »

mtdewcmu wrote: post #47
sofal wrote: post #37

Earlier quoted context omitted.

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.

I suggest that you pick up any git tutorial out there. It will soon become less of a black box.

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

#56

Post by mikeash »

phaemon wrote: post #54
mikeash wrote: post #40

Earlier quoted context omitted.

I understand how it works. Of course there's such thing as "an edited version" of a commit: it's a new commit that you create by taking an existing one and altering it. If you want to argue about terminology, please be my guest, but that's all your dispute is.

If you know how it works then where did your last question come from? The bit you're "confused" about? It's obvious what the answer is if you know how it works, so what was your point exactly?

I know how git works in general. I wasn't 100% clear on the whole garbage collection aspect of it, which is hardly a central feature.

There's a difference between "has no idea how it works" and "understands the overall structure but doesn't know every single detail".

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

#57

Post by mtdewcmu »

pyre wrote: post #53
mtdewcmu wrote: post #50

Earlier quoted context omitted.

It might be a better idea to just change the password.

There is a point past which you can be too pedantic and be confused with a troll. I think that you may be straddling that line. Next time, rather than just assume that the poster isn't smart enough to realize that a compromised password should be changed, maybe you could take in the fact that it's probably just an example of data that you might want to extract from your history if it's automatically there. I can thin…

I meant to raise the question of whether it's worth trying to expunge something sensitive from git. You'd have to track down all the clones of that repository. Even if you thought it was gone, it would be prudent to change the password anyway.

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

#58

Post by mtdewcmu »

pyre wrote: post #55
mtdewcmu wrote: post #47

Earlier quoted context omitted.

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.

I suggest that you pick up any git tutorial out there. It will soon become less of a black box.

I've read a lot about git. The docs generally don't pick apart what's inside the .git directory.

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

#59

Post by pyre »

mtdewcmu wrote: post #58
pyre wrote: post #55

Earlier quoted context omitted.

I suggest that you pick up any git tutorial out there. It will soon become less of a black box.

I've read a lot about git. The docs generally don't pick apart what's inside the .git directory.

- The history items are stored as commit objects that are identified as a SHA-1 sum of the contents (including meta-data like Authored By, Committed By, etc).

- One of those meta-data items is "Parent Commit," so if you change one item in history, it changes the SHA-1 sum of all subsequent items (because at the very least they all need to be re-parented).

- All of the commit objects are stored under .git/objects.

- Branches are just files under .git/refs/ that contain the SHA-1 sum of the most recent commit on that branch. This is why they are called 'branch pointers.' That's basically all they are.

- If you have a history of 5 commits, and make a change to the initial commit, you now have 10 commits in your .git/ directory. Your (e.g.) 'master' branch will point to the most recent 'tree' of 5 commits. The other commits will still exist in .git/objects, but there will be no branches pointing them. You can use 'git reflog' to find them, or access them by their SHA-1 sum.

- Eventually 'git gc' (gc = garbage collect) will clean out the unreferenced commits, but this happens rarely if you don't explicitly run the command.

- When you 'git push,' you are only pushing branches to the remote repo, so commits that are stored locally, which are not referenced by one of those branches you are pushing, will not be pushed out. If you have commits that you don't want to end up in limbo like this, you should 'git tag' them or create a branch (e.g. 'archive/master-2013-12' that points to them).

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

#60

Post by pseut »

mtdewcmu wrote: post #57
pyre wrote: post #53

Earlier quoted context omitted.

There is a point past which you can be too pedantic and be confused with a troll. I think that you may be straddling that line. Next time, rather than just assume that the poster isn't smart enough to realize that a compromised password should be changed, maybe you could take in the fact that it's probably just an example of data that you might want to extract from your history if it's automatically there. I can thin…

I meant to raise the question of whether it's worth trying to expunge something sensitive from git. You'd have to track down all the clones of that repository. Even if you thought it was gone, it would be prudent to change the password anyway.

s/password/large binary/
Post reply on HN