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

121–130 of 175 posts

Re: Git Undo

#121

Post by komali2 »

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…

Technically the same metaphor can be used for "commit" if we assume you stage the one thing and commit that one thing. Now look through the same workflow again but replace "stage" with "stage it and commit it."

Re: Git Undo

#122

Post by grok2 »

atsaloli wrote: post #74
panic wrote: post #38

I wonder how much time and money has been wasted trying to operate Git's confusing UI. The repository format itself seems fine, but I'm surprised we're not all using a better frontend by now.

I teach Git. I find many who have learned just enough to get by, and their shallow understanding hobbles them. It's not enough to memorize command line "incantations", you have to understand what's happening. Git is a sophisticated tool. There are over 100 subcommands! Once you fully understand the basic terms (e.g., "detached", "HEAD", "branch", "commit", etc.) Git becomes less confusing. http://www.verticalsysadmin…

I think you should read back to yourself what you wrote -- you are essentially saying git is complex. Anything complex with enough time and understanding can become easy, but do you need the complexity in the first place? Most developers usually want a simple workflow where they don't want to deal with too many idiosyncrasies of the tool they use. You want to checkin and checkout mostly, but instead one needs to understand a lot of details or you keep tripping up.

Re: Git Undo

#123

Post by lobster_johnson »

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.

"git add -p" generally negates the need for incremental staging, unless you have made two unrelated changes to the same diff hunks that need to be untangled.

Re: Git Undo

#124

Post by TurningCanadian »

shados wrote: post #70
chriswarbo wrote: post #42

Earlier quoted context omitted.

One important reason is to avoid wasting time on gilding lilies. Another reason is that the git information (e.g. from git blame) tells us when the code was written and in what order, rather than some post-hoc rearrangement. For example, we might notice that code X is doing some tricky work which elsewhere is done by a helper function Y. We look at the git info and see that X was added after Y, so we try to figure ou…

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, then we know we have to look closer at that code. Without the individual commit, all we know is that giant-project-x was accomplished with this commit, and the change to that line may or may not have the necessary update.

Re: Git Undo

#125

Post by dspillett »

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?

> 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 information than people want and can result in cognitive overload.

Different people want different detail.

Sometimes the same people want different detail for different tasks. One option might be for a feature to allow you to mark a commit as intermediate. Keep those with the flag around but don't display them or allow things like bisect to operate on it by default. Display them if an extra option is provided, allow action upon them similarly (not by default, you don't want a typo in a commit ID to result in a commit that exists but is not the one you are looking for to be accessed).

Re: Git Undo

#126

Post by StavrosK »

nolemurs wrote: post #115
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…

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 removed with "rm", a branch with "branch -D" and a remote with "remote remove"? What about its fundamental architecture makes it so that the commands can't be "git rm", "git branch rm", "git remote rm"?

Nothing, and this is the crux of the argument. Git's porcelain is inconsistent, unintuitive and poorly designed.

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

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

> That article you linked is clearly from someone who liked how simple subversion was

Maybe so, but that doesn't invalidate its arguments.

Re: Git Undo

#127

Post by agentgt »

komali2 wrote: post #121
tsm wrote: post #104

Earlier quoted context omitted.

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…

Technically the same metaphor can be used for "commit" if we assume you stage the one thing and commit that one thing. Now look through the same workflow again but replace "stage" with "stage it and commit it."

You can also use shelve in mercurial. I have never needed to use it on git though because of staging/cheap branches.

Re: Git Undo

#128

Post by rjbwork »

dspillett wrote: post #125
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?

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

Re: Git Undo

#129

Post by nolemurs »

m12k wrote: post #100
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 can definitely be value in e.g. summarizing the final result and understanding after a number of 'failed' iterations. And that the many small commits can be considered "noise" if you only care about what happened at a high level. However, rewriting history with operations like squash or rebase IMO seems like a bad solution to a real problem - it really shows that we don't yet have the right abstractions or tool…

So, here's a question. I make a commit to implement a feature, then I realize there's a bug in my implementation, so I fix the bug, and then squash it into a single commit. What is the scenario where anyone is going to be perusing the history and he'll actually want to know about that bugfix?

What's the actual value in that intermediate commit? Other than seriously contrived scenarios I can't think of any of the "legitimate use cases" you mention. If it's someone else's code I never want to see that intermediate commit.

Where's the tradeoff?

Re: Git Undo

#130

Post by krupan »

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…

I think bundles are easier to understand than the reflog. When you run a command that modifies commits, the original commits are stored off in a bundle file. When you unbundle that file, the commits show back up in your repository history. What could be simpler? The git reflog gives you a weird truncated log view of old commits that is very hard to parse (for a human at least).

That being said, I've been using changeset evolution for over a year and it is awesome. Instead of creating a bundle your commits are just hidden. You can run any of your hg log commands with --hidden and it shows you those hidden commits. You can see exactly how your rebase removed (hid) some old commits and created new ones. It's very easy.

Post reply on HN