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

Git Undo

megakemp.com

Post reply on HN
Print view View original

131–140 of 175 posts

Re: Git Undo

#131

Post by krupan »

an_account wrote: post #109
gwright wrote: post #77

Earlier quoted context omitted.

One clarification: amend, reset, rebase and their ilk don't 'manipulate the commit tree' other than adding commits. The manipulation is with the branch names associated with the commits. I've always hated the common description of 'rebase' as 'rewriting history'. None of the existing commits are modified by rebase, new commits are added and the branch names are shuffled around.

Rebasing also rewrites all your commits to have a different parent commit.

Nope, parent is correct. If you use hg's changeset evolution and run rebase, and then do a hg log --graph --hidden you can see that your original commits have not been touched, other than to mark them as hidden and obsolete.

Re: Git Undo

#132

Post by krupan »

rjbwork wrote: post #19

I freely admit to being an Hg fan, but that this stuff is accepted as common practice kinda blows my mind. What's so wrong with keeping an accurate picture of history that people do all kinds of manipulation to their history to keep from the VCS system from accurately reflecting history of development?

No version control system accurately reflects every bit of history that goes into creating and editing your code. You'd have to record every keystroke. The whole idea behind a vcs is to record helpful and relevant history. Is every little merge relevant and helpful history? Hard to say, maybe, but probably not.

Re: Git Undo

#133

Post by krupan »

tsm wrote: post #104
recursive wrote: post #76

Earlier quoted context omitted.

I was at least a little confused by stage for a while. I still think the distinction between stage and commit is unnecessary at best.

I had a recent epiphany about staging, which is that it really starts making sense if you stage as you go. Let's say you want to write small feature X, and it truly makes sense for X to be a single commit. But doing X involves changing around both Y and Z. Git makes the following workflow easy: * Fiddle around until you get Y working how you want it * Stage it * Fiddle around trying to get Z to work. Try something ex…

But why stage when you can just commit? You can use rebase -i to modify that commit later if you need.

Re: Git Undo

#134

Post by krupan »

nolemurs wrote: post #113
recursive wrote: post #112

Earlier quoted context omitted.

By specifying the parts you want to include when you commit. I think it's unnecessary for any reasonable work flow, and doesn't manage to break even on its benefit vs. cognitive cost.

So you want a long command line argument were you tag specific line numbers and have to get it all right at once? That sounds terrible to me. Being able to add bits and pieces to your staging area and then once you've got it all ready commit is pretty useful. I guess I just don't see the cognitive cost as being particularly high. It's a pretty simple model.

You can add bits and pieces to commits directly with commit --amend. The index is really not needed.

Re: Git Undo

#135

Post by nolemurs »

StavrosK wrote: post #126
nolemurs wrote: post #115

Earlier quoted context omitted.

I mean, I'll agree, if you insist on trying to create an abstraction to understand git, you can beat your head against the wall for days trying to figure out how it works. On the other hand, if you just take a couple hours to really try to understand what it's doing and why it's not that hard, and it's way more effective and powerful than any other tool out there. Personally I like tools that are powerful and efficie…

> Personally I like tools that are powerful and efficient once learned over tools that I can use without any learning. I prefer powerful and efficient tools that I can use without any learning, since the two aren't mutually exclusive. > if you just take a couple hours to really try to understand what it's doing and why it's not that hard, What is it in git's architecture and design that mandates that a file should be…

> prefer powerful and efficient tools that I can use without any learning, since the two aren't mutually exclusive.

They're not necessarily mutually exclusive, but in my experience there's often a trade off. I would argue that git is about as simple to as it can be without taking power away from the user by forcing an abstraction on him.

> What is it in git's architecture and design that mandates that a file should be removed with "rm", a branch with "branch -D" and a remote with "remote remove"?

Yeah... I have to agree that the choice of command line arguments is the weakest element of git.

> What does "intuitive" mean if not "easy to learn"?

The two often go together, but aren't necessarily the same thing. Something is "intuitive" if the correct thing to do is natural and obvious without a whole lot of thought. Git isn't intuitive before you understand the data model, but once you do, you don't have to spend a lot of time figuring out how to accomplish things, so it becomes intuitive. I would argue that by contrast, subversion is intuitive out of the box, but as soon as you want to do more sophisticated things it becomes rapidly counter-intuitive and very difficult to work with.

Re: Git Undo

#136

Post by sofal »

TurningCanadian wrote: post #124
shados wrote: post #70

Earlier quoted context omitted.

Personally, I only care about when the code hit master. Because that's when it could potentially have broken shit for everyone. That I committed it locally is pretty irrelevant: I could just as well NOT have committed it, made a backup of the files on the side, copied them back in...from the perspective of the rest of my team, my local history is an implementation detail. If the only thing I do is manipulate my local…

> Personally, I only care about when the code hit master. So just look for the merge commit on the master branch that brought it in. By having 300 separate commits (which you were doing anyway) it helps us know what your thought process was on the day that a given line changed. Maybe you were refactoring function X to do Y. If you don't mention that you were accounting for changes happening in someone else's branch,…

By having a history of every single key you typed to create this comment, it would help me know what your thought process was when you typed it up. Maybe you got pissed off and wrote a swear word or two and then backspaced. Maybe you worded something awkwardly and then refactored your sentence. Without all of your keystroke history, all we know is that a comment was made by you, and your opinion may or may not have taken into account certain arguments made by others in the same thread around the time that the comment was published.

Re: Git Undo

#137

Post by krupan »

Mchl wrote: post #13
richardwhiuk wrote: post #11

I worry about naming a function undo that doesn't necessarily undo what the user expects. Undo has a strong user expectation, and I'm not convinced this matches that.

Git already has `git branch` which doesn't in fact do any kind of branching but creates a label which follows commits when it's checked out.

You are absolutely right and I'm sorry to see you getting downvoted. See:

http://bryan-murdock.blogspot.com/2013/06/git-branches-are-n...

Re: Git Undo

#138

Post by dspillett »

rjbwork wrote: post #128
dspillett wrote: post #125

Earlier quoted context omitted.

> What's so wrong with keeping an accurate picture of history I think part of the problem is the distinction between history and audit. What you are thinking of is a full audit: every change made by everyone to get to and from each state. History can sometimes be this, but sometimes you just want the solid states and the extra detail of each step between including failed steps that were back-tracked is more informati…

I think that's what feature branches are for. You merge to master/default after you're done with your feature, and commit an accurate history to the branch.

Probably, though that isn't something you can do after the fact where a "treat this as a partial result" flag on a commit could be.

Re: Git Undo

#139

Post by Guyag »

gwright wrote: post #77
gwright wrote: post #60

Earlier quoted context omitted.

Opinions differ on this matter because of different concepts of what 'history' is appropriate to maintain. At one extreme, you could keep track of all your keystrokes in the editor so that you could have a full history of your work including backspaces to correct typos. On the other extreme is the mythical programmer who crafts perfect commits in exactly the correct order on the first attempt. Most mortal programmers…

One clarification: amend, reset, rebase and their ilk don't 'manipulate the commit tree' other than adding commits. The manipulation is with the branch names associated with the commits. I've always hated the common description of 'rebase' as 'rewriting history'. None of the existing commits are modified by rebase, new commits are added and the branch names are shuffled around.

I think this is pretty pedantic. I count that shuffling as rewriting history - that's not what happens in the background but that's what appears to happen, and that is what matters. What would you term it instead?
Post reply on HN