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

111–120 of 175 posts

Re: Git Undo

#111

Post by filoeleven »

nolemurs wrote: post #85
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?

You have to think about the purpose of the history. Git history serves a few purposes. First, it provides an overview of development so that someone can use `git log` to quickly figure out what's been done. Second, it provides context to code changes so that someone using `git blame` can figure out why some code looks the way it does. Finally, it provides a set of distinct points for clean manipulation of history via…

> There's nothing wrong with keeping an accurate picture of history. It's just not actually useful.

Except for the relatively rare cases when it is incredibly useful. But that's why we have the reflog.

Re: Git Undo

#112

Post by recursive »

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

If you don't have `stage` how are you going to generate a commit which has only some of the changes you've done (potentially including partial commits from files)? `stage` is unnecessary if you have a really simple workflow, but it provides a lot of flexibility at very little cognitive cost.

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.

Re: Git Undo

#113

Post by nolemurs »

recursive wrote: post #112
nolemurs wrote: post #91

Earlier quoted context omitted.

If you don't have `stage` how are you going to generate a commit which has only some of the changes you've done (potentially including partial commits from files)? `stage` is unnecessary if you have a really simple workflow, but it provides a lot of flexibility at very little cognitive cost.

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.

Re: Git Undo

#114

Post by ngoldbaum »

agentgt wrote: post #110
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?

I too admit that I'm a huge Hg fan (will not switch the company code to git) but I also admit history rewriting is a damn worthy feature. At the very minimum I think we can agree that safe rebasing is better than a plethora of merges that really serve no purpose other than to clutter history. The more distributed and diverse/disparate your team is the more I think history editing + cheap branching is worthwhile (but…

Rollback is deprecated, it doesn't show up in the docs. Because people use it in scripts it will never be removed due to mercurial's backward compatibility guarantees.

Mercurial 3.9 ships with the journal extension, which is a bit like the git reflog: https://www.mercurial-scm.org/wiki/JournalExtension

Re: Git Undo

#115

Post by nolemurs »

StavrosK wrote: post #95
nolemurs wrote: post #90

Earlier quoted context omitted.

Once you understand Git's data model, the UI is perfectly intuitive and very efficient. When you want to do something in git, it generally requires just a single command - you just have to know what you actually want to do. Attempts at different UIs fail because they're all trying to put an abstraction over top of git that doesn't actually reflect the underlying data. As a result, they're limited to the set of git fu…

This is a good article: https://stevebennett.me/2012/02/24/10-things-i-hate-about-gi... > Once you understand Git's data model, the UI is perfectly intuitive So it's not intuitive at all. Not to mention that every damn command is inconsistent with every other command! To remove a file, git rm. To remove a branch, git branch -D. To remove a commit, git reset --hard HEAD^. How is this intuitive, consistent, or even san…

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 efficient once learned over tools that I can use without any learning.

Note that I never said git is easy to learn, just that once you take the time to understand it, it's actually quite natural and intuitive.

That article you linked is clearly from someone who liked how simple subversion was and is annoyed that git requires more than 15 minutes to learn. But there's a reason almost no one is using subversion anymore.

Re: Git Undo

#116

Post by agentgt »

ngoldbaum wrote: post #114
agentgt wrote: post #110

Earlier quoted context omitted.

I too admit that I'm a huge Hg fan (will not switch the company code to git) but I also admit history rewriting is a damn worthy feature. At the very minimum I think we can agree that safe rebasing is better than a plethora of merges that really serve no purpose other than to clutter history. The more distributed and diverse/disparate your team is the more I think history editing + cheap branching is worthwhile (but…

Rollback is deprecated, it doesn't show up in the docs. Because people use it in scripts it will never be removed due to mercurial's backward compatibility guarantees. Mercurial 3.9 ships with the journal extension, which is a bit like the git reflog: https://www.mercurial-scm.org/wiki/JournalExtension

Vaguely remember seeing that extension. I did not know it ships with Hg now! Awesome! More reasons to stick with hg longer for my company :)

Re: Git Undo

#117

Post by adrianratnapala »

chriswarbo wrote: post #33
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?

There seems to be a split among git users between those who think history should show what actually happened (i.e. it's left alone), and those who think history should tell a story about the changes (i.e. once you've finished something, turn it into a coherent set of commits like "stub out X", "add tests for X", "make first X test pass", etc.). I agree with you, that history should be left alone; mostly I think of th…

The three messages you give above are perfectly good members of a cleaned-up history. Each has a clear meaning, and small is good when it comes time do bisect.

Messages like "stuff", "it works", "xxx" and "everything I did last month" are not so good, but very common. Moreover if you are in the habit of avoiding them -- that is having each commit do one thing with a clear intension -- then you will keep finding times when you wish you had done something differently an hour ago. And then `rebase -i` is you friend.

Re: Git Undo

#118

Post by StavrosK »

parenthephobia wrote: post #105
StavrosK wrote: post #95

Earlier quoted context omitted.

This is a good article: https://stevebennett.me/2012/02/24/10-things-i-hate-about-gi... > Once you understand Git's data model, the UI is perfectly intuitive So it's not intuitive at all. Not to mention that every damn command is inconsistent with every other command! To remove a file, git rm. To remove a branch, git branch -D. To remove a commit, git reset --hard HEAD^. How is this intuitive, consistent, or even san…

`git reset` doesn't simply remove commits. Depending upon what you reset to it could result in `git log` showing additional commits, or an entirely different set of commits. Conversely, there's no invocation of `git rm` which creates files. In this case, the commands look different because they do totally different things. You'd have a better argument with `git rm`, `git branch -D` and `git remote remove`. :)

Yeah, that was the first thing that popped into my head, but examples certainly abound.

Re: Git Undo

#119

Post by adrianratnapala »

angry-hacker wrote: post #35
chriswarbo wrote: post #33

Earlier quoted context omitted.

There seems to be a split among git users between those who think history should show what actually happened (i.e. it's left alone), and those who think history should tell a story about the changes (i.e. once you've finished something, turn it into a coherent set of commits like "stub out X", "add tests for X", "make first X test pass", etc.). I agree with you, that history should be left alone; mostly I think of th…

But what good does it have for future devs if the history is -- Added this thing -- Fixed typo -- Capitalized the letter Etc.

Actually as a reviewer I don't mind that "fixed typo" style commits. It keeps them separate from the real work. I can just cleanly glide past them while scanning the history.

"Added this thing" sounds like a substantial commit -- at least in terms of meaning, even if (for some reason), the actual diff is a one-liner. In that case I would want a more explanatory commit message, but the change itself is fine.

Re: Git Undo

#120

Post by minitech »

Certhas wrote: post #108
minitech wrote: post #54

Earlier quoted context omitted.

The basics (stage, commit, merge, branch, push, pull, log, diff, bisect) aren’t confusing. (The rest isn’t that confusing either, but…) If you prefer GUIs, feel free to use them, but that’s certainly not everyone.

I disagree, the basics are confusing, because there is too much state. I think gitless ( http://gitless.com/#vs ) shows how a less confusing version looks.

State in the form of staged changes is a huge convenience to me (e.g. with git add -p), but to each their own.
Post reply on HN