Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The git history command

lalitm.com

Post reply on HN
Print view View original

151–160 of 330 posts

Re: The git history command

#151

Post by jonathanlydall »

I've been doing regular significant re-writes to my local Git commit history with relative ease for over a decade even without this new Git command.

I'm convinced that a big part of people often finding Git and rebase difficult is a user interface issue, having to know all the correct command line options and having to make your own mental model of what's happening and what you want to do, all makes it difficult to get a firm grasp on things.

I can't comment on what equivalent alternatives (especially on macOS/Linux as I'm a Windows user), but in terms of a UI for Git which exposes enormous power in an easy-to-use way I've found TortoiseGit to be spectacular and I especially like its rebase dialog:

https://tortoisegit.org/docs/tortoisegit/tgit-dug-rebase.htm...

Which you kick off from a context menu option from the commit line on the commit log you want to rebase onto with a simply named "Rebase onto this" option:

https://tortoisegit.org/docs/tortoisegit/tgit-dug-showlog.ht...

It's super easy to re-order, split, combine, edit commits from here and it's obvious that will happen. If for whatever reason you decide you want to back out midway, you just abort and you're back to where you were.

I will concede there are aspects of a TortoiseGit I find a bit annoying, particularly that I feel I have to click around too much, instead of a shell extension I would prefer an app you launch with tabs or something, but I think this is a fundamental design principle of TortoiseGit, which followed the same principle as TortoiseSVN.

There is Git Extensions for Windows which seems nice at a glance, I tried it briefly, but I think I didn't stick with it either due to being unable to find an option I regularly used or I was just so used to TortoiseGit already.

Re: The git history command

#152

Post by dalmo3 »

jolmg wrote: post #6

> scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze `git rebase --abort` exists. One can also set a tag or something before doing the rebase, do whatever, then `git reset --hard $set_tag` to go back. Nothing to be scared of. Not like the prior state is lost.

> `git rebase --abort` exists

Exactly. 50% of the times I type git rebase it is followed by --abort.

Re: The git history command

#153

Post by Cthulhu_ »

jonathanlydall wrote: post #151

I've been doing regular significant re-writes to my local Git commit history with relative ease for over a decade even without this new Git command. I'm convinced that a big part of people often finding Git and rebase difficult is a user interface issue, having to know all the correct command line options and having to make your own mental model of what's happening and what you want to do, all makes it difficult to g…

Same, but at the same time the existing workflow is a bit more clumsy / these commands are a bit more ergonomic.

Fixup was already possible through `git commit --fixup`, and before that through `git rebase -i`; reword also through `git rebase -i`. I suppose the developers got enough feedback that editing a file to decide what to do with each commit was a bit frustrating for some users.

It's a higher level command on existing functionality I suppose.

Re: The git history command

#154

Post by crabbone »

jonathanlydall wrote: post #151

I've been doing regular significant re-writes to my local Git commit history with relative ease for over a decade even without this new Git command. I'm convinced that a big part of people often finding Git and rebase difficult is a user interface issue, having to know all the correct command line options and having to make your own mental model of what's happening and what you want to do, all makes it difficult to g…

In terms of UI for Git, I've never seen anything getting remotely close to Magit. It's both in-depth and a simplified stateful interface.

Here's what I mean by "stateful": one of the huge problems with command-line tools is that their output becomes mostly inaccessible upon subsequent invocations. Suppose you ran git-log, and now you want to apply the knowledge gained from reading its output to your next action (say, you want to cherry-pick a commit). But you are lucky if the hash of the commit in question is still somewhere in the terminal. Otherwise... you aren't writing that from memory...

Stateful UI to command-line tools allows multiple interactions in parallel and preservation of information obtained in previous interactions.

Git needs a lot of state. You need to remember facts s.a. what branch you are on, what branch did you switch from, what files have been modified, what commits haven't been pushed etc. The requirement to remember all of this is overwhelming and makes the effective use of the tool difficult. This is where various tools come to help (eg. Shell plug-ins that provide auto-completion or modify the prompt to incorporate some of that state info).

I believe that people complaining about difficulties of using Git are often handicapped in their use of surrounding tools that would otherwise mitigate the problems above: they don't know how to add Shell plug-ins that display the current branch, they don't know how to have multiple tabs/panes open in a single terminal session, how to copy text between those tabs/panes, they don't know how to invoke / search auto-complete options.

Genuinely, if you don't have tools to help you use Git, something that people who are used to navigating the world of terminal UI, using Git becomes very unpleasant.

Re: The git history command

#156

Post by dkdbejwi383 »

paxys wrote: post #43

I don't get all the effort people spend in perfectly curating git history. No one is ever going back and reading individual commits. Just squash everything before merging and call it a day.

I could count the number of times I've written a detailed summary in the body of a commit message, and had it read by my colleague reviewing who then didn't need to leave a comment on the PR asking why I did _x_ on zero hands.

Re: The git history command

#158

Post by black_knight »

vasco wrote: post #147
bad_username wrote: post #129

I was uncomfortable with git until I read (the first 3 chapters of) the pro git book ( free here : https://git-scm.com/book/en/v2 ). It provides a great mental model of how git works under the hood. The UI of git - for better or worse - directly reflects its internals. And when I understood them, everything clicked into place.

Mercurial had by far the best UX, never had to read anything to learn it. I just pretend that I'm using mercurial when using git and nuke local repo if I mess up. Been doing it for my whole career.

I love darcs! Somehow its interface just vibes with me. It is interactive by default, and the commands like “record”, “rollback”, etc, are somehow intuitive. Darcs also tried to put more semantic content in the patches, like file operations or search replace parches.

It is always satisfying to rename something, then merge in some work where someone used the old variable name in the meanwhile, and the merge would go through automatically applying the rename!

Re: The git history command

#159

Post by yurishimo »

vasco wrote: post #147
bad_username wrote: post #129

I was uncomfortable with git until I read (the first 3 chapters of) the pro git book ( free here : https://git-scm.com/book/en/v2 ). It provides a great mental model of how git works under the hood. The UI of git - for better or worse - directly reflects its internals. And when I understood them, everything clicked into place.

Mercurial had by far the best UX, never had to read anything to learn it. I just pretend that I'm using mercurial when using git and nuke local repo if I mess up. Been doing it for my whole career.

I've often found that many problems when working in teams can be traced back to `rebase`. I understand the benefits, but if you're already working on a team where history is not used in any serious way, then you cut out a lot of foot-guns by only using `merge`.

Re: The git history command

#160

Post by rom1v »

> `git history fixup` fixes an old commit that has something wrong in it, then autorebases all your branches to match.

Simplifying `git rebase -i` is a great idea, but unfortunately, that does not match my workflow.

I always keep an history of my branches. For example, when I develop a feature, the first version of the branch is `myfeature.1`, then `myfeature.2`, and so on. This is useful because I can retrieve an old version when something behaves differently in a newer one. (And no, `git reflog` will not help)

This has saved me multiple times. For example, I can determine that a problem was introduced between `myfeature.58` and `myfeature.59`. If the "feature" contains 15 commits, I do:

    git range-diff myfeature.58~15..myfeature.58 myfeature.59~15..myfeature.59
This lets me see the changes between the 2 versions, commit by commit (even if they don't have the same base).

I don't want all the branches containing a commit to be rebased automatically (I already try using tags for old versions instead, but this does not quite fit).

Post reply on HN