全部文章0
Hacker Newsturbocon··访问 1

The git history command

原网页

Article URL: https://lalitm.com/post/git-history/

Comments URL: https://news.ycombinator.com/item?id=48901010

Points: 416

# Comments: 294

Hacker News 讨论

419 points · 295 comments · 查看原帖

  1. bad_username

    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.

  2. jolmg

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

  3. nativeit

    I don’t consider myself a coder or programmer, but learning git was like an organizational superpower for my particular brain wiring. I use it for websites, design projects, electronics engineering, music composition, personal knowledge bases, remote administration scripts, config management, snippets, so many applications and so many features for one system. It’s not always perfect, but I tell everyone I work with they should learn it.

  4. chandlerswift

    I've been theoretically a big fan of these commands; I use the `jj` equivalents all the time. The roadblock I've run into is that I as far as I can tell (from the man pages and the git source code) there's no way to get `git history` commands to sign commits they modify: $ git log --oneline --show-signature # look ma, I signed my commits! 3a1dd8f gpg: Signature made Mon 13 Jul 2026 10:45:50 PM CDT gpg: using RSA key FBF32CDBCC134B44FD29B66FA851D929D52FB93F gpg: issuer "chandler@chandlerswift.com" gpg: Good signature from "Chandler Swift <chandler@chandlerswift.com>" [ultimate] Second commit 03c3f6e gpg: Signature made Mon 13 Jul 2026 10:45:16 PM CDT gpg: using RSA key FBF32CDBCC134B44FD29B66FA851D929D52FB93F gpg: issuer "chandler@chandlerswift.com" gpg: Good signature from "Chandler Swift <chandler@chandlerswift.com>" [ultimate] Initial commit $ git history reword HEAD~ $ git log --oneli

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

  6. nine_k

    In short, newer versions of git implemented three really frequent use cases of `git rebase --interactive` as separate lower-friction commands. Apparently they only work when there are no conflicts.

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

  8. klibertp

    IME, the only real pain point with JJ is Git integration. I love it, it's great in almost everything it does. Formalizing all the DSLs and using them consistently throughout the config and CLI is exactly how filesets, revsets, and templating should be implemented. The focus on exposing concepts as interfaces (without "directly reflecting internals"[1] in the UI) is only as good as the concepts themselves, and in JJ's case, they are powerful. The problem is that they are too flexible, so Git interop relies heavily on convention and discipline... which is fatal. The fact that (almost?) all states of JJ are representable in Git makes it easy to mess up your remote, and then you need a very solid understanding of Git to fix it. If you can give `jj` a try on a greenfield, single-developer project, you probably should. It feels exactly like Git felt compared to Subversion (when you focus on JJ