Git Undo • Hacker News Board

Re: Git Undo

#151

Post by blakeyrat » Thu, Aug 25, 2016, 6:26 PM UTC

niftich wrote: post #150

blakeyrat wrote: post #148

Earlier quoted context omitted.

A CLI is a user interface. The problem with Git (well, one of many many problems with Git) is that it conflates its user interface with machine interfaces-- which means tools that have to work with Git (like those GUI clients) have to use the CLI to do so. They don't have a more powerful option, like an officially-supported API or a shared library they could call into. This is terrible software design.

libgit2 [1] In fact, there exist many alternative 'frontends' to Git. There are even protocol translators like Hg-Git [2], and many importers that typically use the fast-import format to ingest Git-impl primitives [3] [1] https://libgit2.github.com/ [2] http://hg-git.github.io/ [3] https://github.com/frej/fast-export

libgit2 is not official, not in-sync with the main Git tool development, and doesn't support many of the features Git supports. So no, it isn't a solution to the problem.

Separating the UI and machine interface is something that should have been done from day one. In fact, I've been told Git's codebase actually already does that (it just doesn't expose the machine interface to the outside world.) Human beings are not machines. They have entirely different needs.

Re: Git Undo

#152

Post by eridius » Thu, Aug 25, 2016, 7:54 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.

Given that commits are immutable objects, the only sane interpretation of "rewriting history" is that it rewrites your view of the history rather than somehow rewriting immutable content-addressed objects.

Re: Git Undo

#153

Post by eridius » Thu, Aug 25, 2016, 7:56 PM UTC

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…

The order in which code was written is pretty meaningless. What matters is how the function of the code changed over time. If I run `git blame` I should not be presented with a whole series of "fixed typo", "changed whitespace", etc commits. That makes it really hard to work with. When I use `git blame` I want to be presented with the commit that actually made a meaningful change to the code.

Re: Git Undo

#154

Post by xorcist » Thu, Aug 25, 2016, 9:51 PM UTC

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,…

> it helps us know what your thought process was on the day that a given line changed

This is not something someone who actually spends his days reading code would say.

Code is hard to read as it is. Presenting it in well packages, readable commits is the very least one can do.

Re: Git Undo

#155

Post by minitech » Thu, Aug 25, 2016, 11:37 PM UTC

krupan wrote: post #133

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…

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

You might not want to commit all of your changes at once.

Re: Git Undo

#156

Post by gwright » Fri, Aug 26, 2016, 12:42 AM UTC

rkangel wrote: post #83

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.

It doe rewrite history in the sense of which events followed which events. Imagine the following sequence of events: I make a commit on my local master Someone else makes a commit on their master They push I 'pull --rebase' That history now shows their commits before mine in the history, even though I made my commits first, directly on top of master.

Let me see if I can clarify. Here is a summary of the situation you described before any push or pull.

    origin repo: M (master)
    your repo:   M---C1 (master)
    other repo:  M---C2 (master)
    
 If other pushes `master` to origin we have:
 
    origin repo: M---C2 (master)
    your repo:   M---C1 (master)
    other repo:  M---C2 (master)

If you then run, from master, `pull --rebase` we have:

    origin repo: M---C2 (master)
    your repo:   M---C1
                  \
                   C2---C1' (master)
    other repo:  M---C2 (master)

Your master branch will be positioned at C1'. As you can see from the diagram, the `pull --rebase` didn't change any existing commits, it just added C2 (same SHA as in the origin and other repos) and added C1', which are the changes in C1 applied to C2 instead of M. If those changes can't be made automatically, you'll get a conflict that has to be resolved before C1' can be created.

I don't think it is helpful to describe this as adjusting the order of commits or re-writing history or any similar language that suggests some sort of mutation to the commit tree. The only thing that has happened here is that additional commits have been added to the tree and the label `master` has been moved to a new leaf commit.

I realize some other commenters have said I'm being pedantic but I would instead say that I'm being accurate. You can't really understand how rebase, rebase -i, rebase --onto, fixups, reflog manipulations, and so on work if you don't have the correct mental model of the git commit tree.

Re: Git Undo

#157

Post by gwright » Fri, Aug 26, 2016, 12:49 AM UTC

Guyag wrote: post #139

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.

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?

What actually happens does matter. You can't understand how lots of git commands work if you don't understand that the git commit tree is an append-only data structure and that branches are just labels of leaves in the tree.

Re: Git Undo

#158

Post by gwright » Fri, Aug 26, 2016, 12:52 AM UTC

eridius wrote: post #152

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.

Given that commits are immutable objects, the only sane interpretation of "rewriting history" is that it rewrites your view of the history rather than somehow rewriting immutable content-addressed objects.

Sure, but lots of people using git don't really understand that commits are immutable or that the commit tree is an append-only data structure. The pervasive use of the phrase 'rewrite history' hinders this understanding.

Re: Git Undo

#159

Post by [deleted] » Fri, Aug 26, 2016, 1:23 AM UTC

p4bl0 wrote: post #28

I have this alias in my ~/.gitconfig: cancel = reset --soft HEAD^ I don't want an alias to hard reset, it seems to dangerous and a good way to lose some work. However a soft reset like this allow me to cancel the last commit and add an omitted file, or remove one from the commit, or simply to correct the commit message easily.

[deleted]

Re: Git Undo

#160

Post by Dylan16807 » Fri, Aug 26, 2016, 2:33 AM UTC

m_mueller wrote: post #94

dan00 wrote: post #73

Earlier quoted context omitted.

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

If you want to undo without reflog entries, just snip the most recent line off the reflog.

If you want to put annotations on commits, use tags with message bodies.

So yes, there are ways to accomplish what you want.