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

81–90 of 175 posts

Re: Git Undo

#81

Post by _asummers »

Cthulhu_ wrote: post #45
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…

I think a solid middle ground can be found. By focusing on making clean commits, instead of being tempted to make "whoops fixed" commits, you will become a better developer and your code will be cleaner. And your history, too. At the very least, review your commits and clean then up before pushing - merge 'fix' commits if you didn't --amend them and review commit messages. What the commit does should be obvious from…

One way I enforce the review of my own commits in my own work flow is not using the CLI for committing. My git client shows me the difference in the status window and also when writing the commit message. Then also making it easy to stage specific junks without having to go down the add -p route. I personally use magit in emacs but I'm sure gitk and some of the more graphical ones have this ability. Not to say any of these don't exist in the CLI, the ergonomics are just not the same as getting the output of multiple commands in a single well designed interface.

Re: Git Undo

#82

Post by garaetjjte »

ekzy wrote: post #34
garaetjjte wrote: post #4

It should automatically skip reflogs created by undo itself, so git undo; git undo be equivalent to git undo 2, and for undoing undo there should be seperate git redo.

I agree with that. So you could undo step by step without thinking about the number to put next to your undo command. It seems a bit trickier to implement, though

Only a bit of awk magic:

~/git-undo.awk:

  BEGIN { jmp = 0 }
  {
    match($2, "{([0-9]+)}", c);
    if (c[1] == jmp)
    {
      jmp++;
      if ($3 == "reset:")
      {
        match($6, "{([0-9]+)}", x);
        jmp += x[1];
      }
      else
        i--;
      if (i == 0)
      {
        print jmp;
        exit;
      }
    }
  }

  git config --global alias.undo '!f() { git reset --hard $(git rev-parse --abbrev-ref HEAD)@{$(git reflog | awk -v i=${1-1} -f ~/git-undo.awk)}; }; f'
Redo is also possible, but i don't have time now to do it.

Re: Git Undo

#83

Post by rkangel »

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.

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.

Re: Git Undo

#84

Post by dozzie »

Dylan16807 wrote: post #68
dozzie wrote: post #62

Earlier quoted context omitted.

1. calculating differences 2. merging two or more different branches 3. transporting code (publishing it) 3a. accepting somebody else's patches 4. descriptions of history points 4a. pointers to parent code trees (especially with tree merges) 5. history traversals (bisecting, among the others) Not to mention that you need either administrative privileges for creating a snapshot or a special kind of filesystem that sup…

What are you talking about? amelius is mentioning an alternative to the hacky "git undo", not an alternative to git. You put your git repo onto the filesystem. As far as administration, most devs will have elevated rights or can use FUSE or something. We could talk about needing administrative privileges to install git, too, but it's pretty far removed from the central topic.

> amelius is mentioning an alternative to the hacky "git undo", not an alternative to git.

Ah, so I misunderstood. Still, changing the filesystem under $HOME (or whatever is the working directory) is more difficult than using some user-level tool.

Re: Git Undo

#85

Post by nolemurs »

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 `git revert`, `git bisect` etc.

From the point of those purposes, there's no real value in a history which accurately reflects the development process. The ideal commit has a few properties: it should address only one concern, it should contain all the immediate code changes addressing that concern, and it should not be overly long. Commits like that make navigating and manipulating the git history easy.

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

Re: Git Undo

#86

Post by Bartweiss »

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…

As I understand "undo" it's a convenient feature for addressing quickly-discovered errors.

If you rapidly realize that you committed to the wrong branch, or left a line of code half-finished, or misspelled a word, there's very little value in logging that. If you had seen it two seconds before the commit you would have fixed it without a second thought, so why insist on preserving it seconds after the commit?

Presumably (if only for safety) no one is using 'undo' on anything pushed to a shared repo. I can appreciate the argument that we shouldn't rewrite history into a nice, streamlined narrative, but I don't see much reason to avoid tools like 'amend' for fixing commit messages, or 'revert' when some silly line of test code gets committed (and not pushed).

When I'm dealing with other people's Git histories, I appreciate the middle ground approach most. There's no point in spinning some imaginary, elegant story - if it's not real history then write up an essay instead of storing it in your 'history'. But I also don't need to see every line of "oops, un-stubbed X" - my experience is that at least for immediate fixes it only makes things harder to read.

Re: Git Undo

#87

Post by rjbwork »

recursive wrote: post #75
yoavm wrote: post #49

Earlier quoted context omitted.

I never had the urge to rewrite the history of my code until I started using CI & CD. Since then, it happened to me few times that I wanted to fix something small and ended up trying multiple times, pushing a new "maybe this time?!" commit over and over again. Obviously it's not best practice, but it something you do when there's a rush. Having 10 tiny commits like that are just failed attempts to fix a bug isn't pra…

I'm using CI and CD. If I want to find out if I've fixed a bug, I just run the build locally before pushing.

Ideally, sure. But I've had to do this before due to the fact that a configuration value in the PaaS I was using was unmodifiable on remote, but modifiable locally, so I had to do a sort of binary search to narrow it down by observing the behavior of the server via changing my code's value a number of times.

He makes a good point, but ultimately I have to agree with someone's point about "pointlessly gilding lillies".

Re: Git Undo

#88

Post by chubot »

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?

How do you accurately reflect the history of development when it's nonlinear?

I was an hg person too, but I came over to the git side when I needed to collaborate with people. git's killer feature is merges. And merges benefit from fine-grained commits that rewrite history.

Re: Git Undo

#89

Post by rjbwork »

sethammons wrote: post #72
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?

In my opinion, it is only valuable to present a pristine history to make sure that every "official" commit provides an application that can be ran. This allows git bisect to do amazing things. In other words, I will git merge --squash. When someone rewrites history after pushing, all they do is make everyone else have a bad day.

If I'm pushing non-building commits on a feature branch in Hg, why should it matter? It documents the history of the development of that feature without interfering with default/master.

Re: Git Undo

#90

Post by nolemurs »

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 functionality that overlaps their abstraction, and the tools are less powerful.

Post reply on HN