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

91–100 of 175 posts

Re: Git Undo

#91

Post by nolemurs »

recursive wrote: post #76
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 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.

Re: Git Undo

#92

Post by WillAbides »

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.

What do you think `git branch` should do?

Re: Git Undo

#93

Post by StavrosK »

newjersey wrote: post #63
Dylan16807 wrote: post #44

Earlier quoted context omitted.

What does accurate history mean? Do you commit after every 20 seconds of typing? Why not? The people cleaning up history have the same motivation.

The last time we had this discussion the consensus bottom line was that you try to avoid rewriting history once you have pushed it to a place where others have access to it. Once you've published it, let it go. Do not mess with history. I think we can all agree on that. The disagreement is whether I should squish my commits before I push it and I put that in the same pile of questions as am I obligated to my signific…

You aren't obligated, you just might make people not like you very much.

Re: Git Undo

#94

Post by m_mueller »

dan00 wrote: post #73
m_mueller wrote: post #64

Earlier quoted context omitted.

Is there maybe a way to annotate the commit message of HEAD without influencing the reflog?

You can't change the commit message of a commit without changing the commit, which in most cases is a bad idea, if you don't know pretty much exactly what your doing. Replacing one heuristic with another won't make this a stable operation. A lot of people had already the idea to encode relevant information inside of documentation and it was always a bad idea in the long run.

I get that, I just wondered whether it's technically possible (with supported git operations, not hacking down at FS / byte level).

Re: Git Undo

#95

Post by StavrosK »

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

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 sane?

"I understand git" and "git is easily understandable" are completely different. Git is not easily understandable, at all.

Re: Git Undo

#96

Post by ISL »

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.

It creates a branch of zero length.

Re: Git Undo

#97

Post by dilap »

if you're on a mac, the excellent & open-source GitUp graphical git client has undo built right in. it also makes it easy to slice-&-dice your commit graph.

Re: Git Undo

#98

Post by nzp »

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

Earlier quoted context omitted.

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

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…

That code X should be clearly commented to explain the state you describe. That's the proper, most ergonomic, solution to the problem. Sure, it might not be documented and archaeology might be needed, but it shouldn't be considered as an excuse to not write comments and/or documentation.

Re: Git Undo

#100

Post by m12k »

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 tools for doing this. If all the small commits are considered "noise" then it shows that we don't have good enough tooling for filtering and grouping when perusing our VC history. The information that people are currently putting into a squash commit is an aggregate or derivative of the original, and as such shouldn't replace it, it should supplement it. There are legitimate use cases where the details of those small commits are indeed valuable, even if the more high-level "just tell me the final result" use case is more common - you shouldn't have to be forced into making that tradeoff.

I know some people are using merge commits or pull requests as a place to put this information - but maybe we need a an explicit mechanism for grouping together commits and summarizing them? I'm imagining something along the lines of code folding. Such a grouping might have other uses too (e.g. signal that there's a grouping of commits where the tests will fail, so skip to the last commit if bisecting)

Post reply on HN