Git Undo • Hacker News Board

Re: Git Undo

#101

Post by chriswarbo » Thu, Aug 25, 2016, 2:37 PM UTC

Dylan16807 wrote: post #66

chriswarbo wrote: post #65

Earlier quoted context omitted.

> The ability of devs to collapse a bunch of commits into a useful summary is near zero right now You can get quite far with 'git diff START END'. Something more task-specific can probably be done with Emacs, Magit, Ediff mode, bash, elisp, etc. Even if you think collapsing commits by rewriting history is useful for making summaries, etc. what makes you think you can produce a more useful summary right now than that…

What makes me think I can write better code than the thousand people downloading my repo later? I don't, but somebody should do the summarizing, and it might as well be me. Smashing the diffs together gets you the least useful parts of a purposeful squash commit.

> somebody should do the summarizing, and it might as well be me.

Should they? See my earlier point about gilding lilies and YAGNI ;)

Of course, there are always exceptions! The most obvious ones are processes which work per-commit, e.g. bisecting, conflict resolution, per-commit code review, etc. where having a bunch of interleaved "stories" can be tedious.

Re: Git Undo

#102

Post by jakub_g » Thu, Aug 25, 2016, 2:45 PM UTC

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 might want to have `git bisect` working, for instance. For bisect to be useful, each commit should leave the repo in a consistent, "green" state. If you commit something stupid by mistake, and add a commit later to fix it, then during the bisect you might get wrongly stopped at the stupid commit.

Arguably it's more important to have clean commit history in open source projects. I used to be hard on this at work but I relaxed a bit lately.

Generally the development in companies moves much faster than in open source libraries (in terms of # of commits per weeks), and generally in open source world it's expected to have clean, well tested, working solutions rather than hacks that can be fixed tomorrow if needed - and because of that, OS maintainers have higher standards for commits.

Re: Git Undo

#103

Post by djsumdog » Thu, Aug 25, 2016, 2:50 PM UTC

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…

As I understand it (and what I now do when on a team) is use commits as atomic, fully flushed out parts. Commit 324rte may specifically "add support for PUT operations on widgets" or asde21 may "Refactor Business Rule Unit Tests into individual files".. and looking at the log, you can cherry-pick that one commit (and deal with potential merge issues) onto your branch.

But if you're working at home on your own project and just want to sync between a few machines, what do you do? Commit, "Hashing on the Liststore kinda works, some bugs." Push. Go to your home machine, work some more, and finally squash all those kinda working commits into one commit ... potentially even need a "git push --force" (which you can safely do since you're the only developer?)

I agree with you totally though. It shouldn't just be a branch. There should be a way to group x edits into one big commit. That's the atomic unit that has a specific feature, and all the mini-commits inside of it should be totally abstracted except for specific deep searching commands.

Re: Git Undo

#104

Post by tsm » Thu, Aug 25, 2016, 2:53 PM UTC

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.

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 experimental. Nope, that's not you want it. `git checkout .` Try again.

You don't have to worry about only blasting away the failed Z attempt while preserving Y—since Y is staged, it's easy to keep around.

Re: Git Undo

#105

Post by parenthephobia » Thu, Aug 25, 2016, 2:58 PM UTC

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…

`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`. :)

Re: Git Undo

#106

Post by chriswarbo » Thu, Aug 25, 2016, 3:00 PM UTC

nzp wrote: post #98

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…

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.

I agree that if X avoids Y for some subtle edge-case or whatever, then there should be a comment explaining why.

However, in my example X is written first, but just so happens to have become redundant once Y gets written. We've just spotted this redundancy, and it's up to us to figure out whether X should be refactored to use Y or not.

If we look at an unaltered history, we would see that X was written first, so we can hypothesise that it's just a special case of Y which can be refactored away.

If we look at an altered history, the commits containing X may have been squashed/rebased/etc. into a coherent "story", which just-so-happens to appear on top of the story containing Y.

If there were a comment telling us that X was added due to some edge-case, etc. that makes Y unsuitable, we could leave it alone and get on with something else. Yet in this situation there is no such comment, but that doesn't imply that it's not there to handle some subtle edge-case; we'd need to do more investigation to convince ourselves that it is indeed redundant before we could refactor it in confidence, to counteract the contrary evidence which git is telling us.

Re: Git Undo

#107

Post by parenthephobia » Thu, Aug 25, 2016, 3:02 PM UTC

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.

I think git branch only doesn't "branch" if you already have a differing idea of what a "branch" should be from another revision control system.

For example, I consider that CSV and Subversion don't have branches, but just "copies". To my mind, what git branch does is exactly what branching is.

Re: Git Undo

#108

Post by Certhas » Thu, Aug 25, 2016, 3:02 PM UTC

minitech wrote: post #54

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.

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.

Re: Git Undo

#109

Post by an_account » Thu, Aug 25, 2016, 3:03 PM UTC

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.

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

Re: Git Undo

#110

Post by agentgt » Thu, Aug 25, 2016, 3:09 PM UTC

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 on the opposite end I think Hg consistency is better for corp).

One of my greatest challenges in using/understanding Git was(/is still) the reflog. I know the reflog isn't that complicated but there isn't anything really analogous in other SCM (of my limited knowledge of perforce, svn, hg, git). Also for some reason the presentation of the reflog UI wise is intimidating.

Reflog is nice gem for git particularly since the builtin Mercurial rollback (I wish they would just remove that command) is fairly awful (use histedit or rebase instead). That being said Mercurials new changeset evolution experimental stuff looks really promising [1].

That being said if you are looking to undo in hg like this article talks about you have to look at the

    hg unbundle backupfile

Unbundle is a pretty nasty command compared to the reflog commands but on the other it is just restoring from some backup file. I'm not too sure how you can transfer reflogs around.

[1]: https://www.mercurial-scm.org/wiki/ChangesetEvolution