13 ms·

The git history command

457 points by turbocon 2mo ago

jocelyner 2mo ago
[dead]
runtime_lens 2mo ago
[flagged]
deleted 2mo ago
[deleted]
nine_k 2mo ago
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.
- BobbyTables2 2mo ago
  Wonder if the history command is all that useful. I prefer the interactive rebase and use it frequently. Would much rather “visually” move commits around than accidentally aim “git history” at an orphaned commit hash no longer in my local branch.
  - WorldMaker 2mo ago
    The implication seems to be that `git history` is the higher level, safer `git rebase` for common scenarios. If you are already comfortable with `git rebase` you might just keep using it and never need `git history`. If you are learning git as a junior developer (or teaching/mentoring a junior developer on it) `git history` becomes a good, safe stepping stone for a handful of common tasks. I've been in workplaces where I wished I could disable `git rebase` for all junior developers because they kept learning its footguns faster than its capabilities. A stepping stone seems like a really good idea to me.
skydhash 2mo ago
> Working with lots of changes in parallel on git can be painful. You end up juggling branches and commits, and running scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze. I think that only happens when you work on code as text files (i.e character streams) instead of code (i.e structured content with meaning). Like you have commit A and commit B that is in conflict, you should be glad because that's a rough signal that the intent of A and B differs. Your goal should be to think about how to compose A and B so that both intent survives (unless one supersedes the other). Which means you should be at least familiar with A and B. The issue I found with people that fears conflict is that they often don't understand either A or B (or both). So they are a bad candidate to actually do the operation. It's not a matter of git's cli interface, it's a matter of codebase comprehension and how well you're familiar with the changes in question.
- thfuran 2mo ago
  Git is the one treating code like a text file instead of code.
  - UnfitFootprint 2mo ago
    I pull out difftastic when it’s all too hard for this. Diffs based off tree sitter
    - NateEag 2mo ago
      Don't forget mergiraf, for tree-sitter-based conflict resolution: https://mergiraf.org/ https://mergiraf.org/
      - klibertp 2mo ago
        I absolutely love the images on the landing page. "Inappropriate use of blame, push and pull to resolve a conflict" is pure genius. Even the name had a lot of thought put into it (didn't know about "Giraffe language" before). Beautiful! :)
jolmg 2mo ago
> 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.
- catlifeonmars 2mo ago
  Do you use git reflog?
  - jolmg 2mo ago
    One can also use that, or just `git log -n1` and taking note of the commit hash. So many options.
    - jmholla 2mo ago
      Fun fact: you don't even need the `-n`. `git log -1` does the same thing, for any number. -<number>, -n <number>, --max-count=<number> Limit the output to <number> commits.
    - inigyou 2mo ago
      For scripting: git rev-parse HEAD
  - ibizaman 2mo ago
    I do when I forget to run the git branch comment before. But I find it still hard to understand exactly which commit to reset to in the reflog.
    - _ikke_ 2mo ago
      The branch reflog (git reflog <branchname> or git log -g <branchname>) is a lot easier to follow in the case of rebase than the HEAD reflog (which gets an entry for each commit that gets checked out / applied).
- 2mo ago
paularmstrong 2mo ago
`git history split` is really going to help me help juniors break up their large PRs into smaller more concise changes. If only it had the option to split an entire branch in two easily.
- catlifeonmars 2mo ago
  What does it mean to split a branch in two?
  - rmunn 2mo ago
    Probably to take a series of commits and decide "this one goes on branch A, this one on branch B", e.g. if you intermingled fixing bug A and B in the same branch, you could more easily go through and assign each commit to a new branch. The existing workflow for that would be (there are several possible workflows, but this is what I would do): git checkout intermingled-branch git branch bugfix-A git branch bugfix-B git checkout bugfix-A git rebase -i # Edit the file, keep commits that fix bug A, drop commits that fix bug B git push origin bugfix-A:bugfix-A git checkout bugfix-B git rebase -i # Edit the file, keep commits that fix bug B, drop commits that fix bug A git push origin bugfix-B:bugfix-B
    - LtWorf 2mo ago
      So git cherry-pick?
    - WorldMaker 2mo ago
      Fun fact, you can also automate more of that existing workflow with the rebase interactive TODO list. Roughly something like: pick $ACOMMIT1 edit $ABMIXEDCOMMIT # split out A parts pick $ACOMMIT2 exec make test # test everything compiles update-ref bugfix/A exec git switch --detach main # new branch point pick $BCOMMIT1 edit $ABMIXEDCOMMIT # split out B parts pick $BCOMMIT2 exec make test update-ref bugfix/B exec git merge bugfix/A pick $FOLLOWUPCOMMIT exec make test update-ref intermingled-branch # or bugfix/C It's been a while since I've attempted a rebase TODO list that wild, so I may have forgotten something, but rebase interactive is pretty wild what it will let you try to automate.
bentt 2mo ago
Granted, I have a perspective of a game dev, but this kind of repo defiling just gives me the willies. IMO instead of finding a common ancestor and altering it, just make the desired change upstream and merge it to where it’s needed. If you can’t do that then you have already made a deal with the devil and might reconsider your approach. KISS
hahahaa 2mo ago
I like to be like an accountant. No editing history. Create a new "journal entry" (i.e. commit) to fix.
- what 2mo ago
  You probably shouldn’t be committing things that are broken…
  - moezd 2mo ago
    With tools like GitHub Actions and some added constraints, it's not always possible. You literally need a commit to trigger the CI workflow and it starts to trash your branch. Besides, aren't we all familiar with git commit -m "typo"?
    - ninkendo 2mo ago
      > With tools like GitHub Actions and some added constraints, it's not always possible. You literally need a commit to trigger the CI workflow and it starts to trash your branch I'm with you on your overall point, but as a side note: this state of affairs is so tragic. It's been normalized for there to be test suites that nobody can run except the CI runner, and the only real way to run all the tests is to have GitHub do it. It's pure lock-in, and it's very sad that everything's moved this way. CI actions should be a simple file of "action: command" lines, with at most a separate file that describes when given actions should run. All actions should be runnable locally just as easily as they are in CI. Or if the actions are so complicated they need a complex-ish environment, that environment should be the kind of thing you could run locally too with your hypervisor of choice, without having to think about it. But every VCS host that has an actions/pipelines product is financially incentivized to encourage you not to set things up this way, to preserve their lock-in.
  - hahahaa 2mo ago
    Commit yes you absolutely can. Merge to trunk? Probably not, depends on your strategy.
  - 2mo ago
shepmaster 2mo ago
> That last part goes further than git rebase --update-refs, which only moves refs sitting inside the range you’re actively rebasing. git history instead finds and rewrites every local branch descended from the commit (while also having an option to limit it to only the current branch). I'm reading that to mean that when I use `git rebase --update-refs` in this situation, where I've currently checked out `D` and update `B` to `B'`: A ──► B ──► C ──► D │ └───► E I'll end up with this state, where `E` remains untouched? A ──► B' ─► C' ─► D' │ └───► B ──► E (EDIT: Originally I had `E` point to `B'`, which doesn't make sense) If I use `git history fixup`, it would also update `E` and end up with this? A ──► B' ─► C' ─► D' │ └───► E' If that's the case, is there a way to get `git rebase` to have the same behavior? I've got decades of `git rebase` burned into my fingers at this point.
- jolmg 2mo ago
  > I'll end up with this state, where `E` remains untouched? Can't, because a commit's hash takes into account the parent hashes. Haven't used --update-refs, but reading it, it should result in your third graph. So, > is there a way to get `git rebase` to have the same behavior? is already the case.
  - rmunn 2mo ago
    Unless E remained untouched because it was not rewritten, and ended up staying parented on B instead of getting reparented onto B'. Which is usually not what you want; most of the time you want E', which is E reparented onto B'. But sometimes you want E to remain untouched and stay parented on the original B. Depends on the situation.
    - jolmg 2mo ago
      Exactly, but the second graph where untouched E is reparented to B' is not something that git would allow.
      - 2mo ago
nativeit 2mo ago
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.
- quacked 2mo ago
  How do you use it for music composition?
  - knodi123 2mo ago
    there are plenty of text-based digital music notation systems. Then, you commit periodically as your composition evolves, and you can have all the history/fork/undo whatever that you might want.
    - seba_dos1 2mo ago
      Also, files don't have to be text-based at all to version them with Git. When you're versioning things for your own sake, there's often not much difference between keeping text and binary files there, as it's not like you'll have to resolve an unexpected conflict.
      - rmunn 2mo ago
        I find it really useful to be able to diff two commits, which if you're using a binary format is only possible if you have a meaningful-diff tool for that format. Some formats have one already created, more formats don't. (Though these days, an LLM might be able to produce something suitable).
  - tunesmith 2mo ago
    I use it for lilypond for notation. I always considered it superior to Finale and Sibelius anyway. Not sure how it stacks up against the more modern commercial notation apps. But I love having a real trackable version history of my pieces. What's also cool is the more advanced llms know lilypond and music theory too, so they can do things like... I don't know, check for counterpoint errors. I've used it with limited success to expand my jazz lead sheets into two-hand piano arrangements just for practice exercises.
_nivlac_ 2mo ago
I like `git history reword`, would've found that useful in the past (e.g. fixing a bad typo in an older commit). It sounds like there was probably an equivalent using an existing command but this is easier for me to understand. Thanks for sharing!
paxys 2mo ago
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.
- CuriouslyC 2mo ago
  Squashing everything has a significant downside compared to functional atomic commits: git-bisect gets WAY less useful.
- jolmg 2mo ago
  > No one is ever going back and reading individual commits. Straight from the git-log, maybe not, but sometimes you see code that makes you wonder how it came to be and it can help a lot to see it in context of the commit that introduced it. That'd be less helpful if that commit were some huge thing making lots of different changes at once.
  - paxys 2mo ago
    Seeing the individual change in the context of the larger feature is actually more helpful. Otherwise you find a tiny commit that changes A to B and then have to chase down 13 other commits around it to figure out why that change was even made.
    - jolmg 2mo ago
      Yeah, there's a balance. I try to make my commits so they make sense on their own. > commits around it to figure out why that change was even made. A commit should be such that the message can articulate the why.
- seba_dos1 2mo ago
  Of course we do and it helps tremendously when the graph is reasonable.
- Myrmornis 2mo ago
  One good reason is to keep your tests separate from the fixes that make your tests pass. That way you can check your test fails before the next commit makes it pass, eliminating the risk of a false negative (test passes that would have anyway).
chandlerswift 2mo ago
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 --oneline --show-signature # oops! where'd they go? 5662b2c (HEAD -> main) Second commit 6bf6830 Initial commit amended This has pushed me back to the time-honored `git rebase -i` since I do want to keep my commits signed.
- jmholla 2mo ago
  Woah! That feels like a huge oversight and like it bypasses standard commit logic. The man pages do say `git history` is experimental. Sounds worth a bug report.
smcameron 2mo ago
> Working with lots of changes in parallel on git can be painful. You end up juggling branches and commits, and running scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze. I mean, just use stgit[1] to maintain a stack of patches instead of parallel branches, it's so much better. You can easily wrangle thousands of patches (aka commits) with stgit. A lot of people, on first encountering stgit, read a bit about it, think "why do I need this? I can do the same thing with just plain ol' git.". Yeah, you can. But not at scale. Not practically. Not with thousands of commits. And it makes the case when you just have a few tens of commits absolutely trivial. Try it for awhile and you'll find it indispensible. [1] https://stacked-git.github.io/ https://stacked-git.github.io/
froh 2mo ago
TIL, thx :-) somewhat related Q: how do you give two files the same ancestor? so git log will for each show the history to the beginnings of the originally unsplit file? useful for splitting large files.
- bonzini 2mo ago
  That's not possible, because files don't have ancestors in git. Each commit's tree is tracked independently and copy/move is just something that's detected via heuristics.
  - account42 2mo ago
    But those heuristics could be better than they are now so that a git log <file> will show the shared history for both copies.
  - froh 2mo ago
    I meanwhile understood that you can commit a copy of a file and then edit both, and then the ancestry tracking options to git log resolve the two split parts ancestry just fine.
krick 2mo ago
> scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze Complete bullshit. Might as well say "scary screwdriver that can turn up in your recturm if you so much as sneeze". Sure, I believe that might have happened to you (heard stories from friends that work in the emergency room), but I run rebase -i 10 times during the time I work on each branch (literally: I don't even care to write "proper" commit messages while writing the code, will reorganize and clean them up later anyway), and it never happened to me.
- eviks 2mo ago
  > commit messages while writing the code, will reorganize and clean them up later anyway That's just too primitive of a workflow, so repeating it will not run into the risk. You need to add an actual conflict in some feature branch and get stuck being forced to resolve it to compete the rebase to appreciate the op warning
rushil_b_patel 2mo ago
the "reword" option is same as git rebase -i HEAD~n, and then instead of pick replace it with reword to change the commit messsage. BTW I have made a notion doc on git commands: https://rushilpatel.notion.site/git https://rushilpatel.notion.site/git
eviks 2mo ago
> Every 3 months, for the last 1.5 years, I try it out for a few days, really trying to make it part of my workflow but eventually I give up and go back to git.1 That's not really trying, let's assume you need 1 week to change ingrained workflows, so you just waste time every 3 months stopping right before the threshold. Better try once every year, but for a few*4 days...
kazinator 2mo ago
The thing is, when you are rewriting history to change an old commit, you have to solve the little problem that git commit messages refer to hashes such as: This regression was caused in <hash> on December 19, 2017. The fixup and rewrite of history has to ferret out these has references and fix them to the new hash of the same commit. I have scripted this before!
- inigyou 2mo ago
  Don't change old commits. Change commits you haven't pushed yet.
  - kazinator 2mo ago
    That's not for you to dictate to someone about some project you have no idea about. Git is not a religion or cult. Whether you're rewriting published or unpublished commits, this particular problem is the same. If the commit series contains self-references---later commits in the series have commit messages which refer to the hashes of earlier commits---those references make no sense at all when the series is pushed upstream; they will refer to garbage objects that exist in your repo only, and which will eventually disappear for you too.
    - inigyou 2mo ago
      If you think me telling you how to use a product is religious or cult indoctrination, I dont really see how you are getting anything done while dodging the high priests of "man" and "info"
      - kazinator 2mo ago
        "Never rewrite public history", while it is a directive that talks about how to use a product or not used it, is just your personal preference, and nothing correct or incorrect. Just like "never type a profane word into Vim" is ostensibly a statement about how to use Vim, but of no technical value related to Vim use. It is nothing similar to advice such as using a screwdriver to drive screws and a hammer for nails. Some people regard the git repository as the object they are working on and want to create the perfect history in it, yet also to ship regularly. That requires shipped history be revised. It's entirely possible to work productively with an upstream that revises history, producing non-fast-forward changes. There are things you have to do and know that are not required in FF-only workflows, but nothing too terrible.
bad_username 2mo ago
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 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.
- xyzsparetimexyz 2mo ago
  No it doesn't. Half the git commands are low level, half are high level. It's not 1:1 at all.
  - palata 2mo ago
    So when someone tells you "understanding X helped me a lot", your answer is "no, it did not"? > It's not 1:1 at all. I don't see any mention of "1:1" in the parent.
    - jesse_ash 2mo ago
      > The UI of git directly reflects its internals Maybe?
    - debugnik 2mo ago
      They're replying to > The UI of git - for better or worse - directly reflects its internals.
      - palata 2mo ago
        > Half the git commands are low level, half are high level. Can't we say that the low level level commands reflect its internal? ...
        twister2920 2mo ago
        of course we can, that's not what the original comment said though
SCUSKU 2mo ago
These graphics are great. Makes for a skimmable high signal article, nice work!
xyzsparetimexyz 2mo ago
Tldr; use jj
jonathanlydall 2mo ago
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.html 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 <current reference> onto this" option: https://tortoisegit.org/docs/tortoisegit/tgit-dug-showlog.html 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.
- Cthulhu_ 2mo ago
  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.
- crabbone 2mo ago
  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.
Sharlin 2mo ago
Huh, TIL about `git commit —fixup`.
- Cthulhu_ 2mo ago
  Yeah I learned that one a few months ago, before that I'd use interactive rebase and shuffle the commits around manually in the editor that opens. I appreciate that these commands are just utilities / conveniences on top of a stable base though.
deleted 2mo ago
[deleted]
rom1v 2mo ago
> `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).
anuramat 2mo ago
is there a way to use it with lazygit? unfortunately I'm addicted atp, and "autorebase branches" is exactly what I was missing the entire time
- niels_bom 2mo ago
  lazygit can already reword
quibono 2mo ago
> scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze I'm glad to hear it, I thought that was just me. It gets especially hairy when moving commits around... Plus I have 3-way diffs enabled and I usually get confused by which section is which at least once a day. Also: does anyone know if `magit` has history support?
- deleted 2mo ago
  [deleted]
- seanc 2mo ago
  Not as such, but out of the box you get reword and fixup as first-class rebase macros. I use them all the time. If you wanted to split a commit you'd still have to use a magit-assisted rebase. So if magit added explicit 'history' support I just about wouldn't notice, it would mostly be under the hood.
  - quibono 2mo ago
    100% agree, the fixup macro is amazing. It even fails gracefully when unable to commit for whatever reason. The split one would be handy though.
whilenot-dev 2mo ago
Cool, didn't know about `history fixup`! I only ever did the manual dance with `rebase -i` and `rebase` for all other branches. That and `history split` will sure come handy! What happens with a conflicting fix though? Do I still need to resolve all conflicts on the base branch and `reset --hard` all other branches?
tangsoupgallery 2mo ago
[flagged]
klibertp 2mo ago
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's strengths and use it in favorable conditions - it is young, after all). Get acquainted with `jj` on its terms, and if things click for you, you'll be a bit better prepared for the bumpy road that is Git interop later on. [1] https://news.ycombinator.com/item?id=48903054 https://news.ycombinator.com/item?id=48903054
- steeleduncan 2mo ago
  In princple JJ has non-Git backends, but the only backend they state as being production ready is the Git backend. JJ without the Git interop is more a concept than a reality right now. I love JJ, and the mental model of source control it presents, and I will continue to use it. However, still needing to "drop down" to Git every now and again to get something done makes it feel very much like a convenient wrapper on top of Git rather than a new SCM. If Git adds commands to support the JJ workflow, it would be hard to justify having JJ installed any more.
  - klibertp 2mo ago
    The backend itself is fine, it's just trying to use JJ as a Git frontend for projects developed on Github (among 20 other devs using git, where each of them uses git through different interface and/or in different style) that's currently not ideal :( > However, still needing to "drop down" to Git every now and again to get something done makes it feel very much like a convenient wrapper on top of Git rather than a new SCM. Yeah, but I think that's fine. Git is a solid foundation; it's not wrong to try to build on it initially. It gets you a usable implementation faster. It is a pain point, though. > If Git adds commands to support the JJ workflow, it would be hard to justify having JJ installed any more. Is that a danger? I don't see Git as a fast-moving target. And among all the "convenient wrappers on top of Git", JJ seems to have the design least tied to Git, so I think it has the highest chance of breaking out of the Git dependency in the future.
cnxiaom 2mo ago
[flagged]
blackcube42 2mo ago
[flagged]
warmwaffles 2mo ago
All I want to do is reword and correct commit messages / improve them without rebasing everything. When working with teams this is a sure fire way to create absolute chaos.

457 points by turbocon 2mo ago

jocelyner 2mo ago

[dead]

runtime_lens 2mo ago

[flagged]

deleted 2mo ago

[deleted]

nine_k 2mo ago

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.

BobbyTables2 2mo ago
Wonder if the history command is all that useful. I prefer the interactive rebase and use it frequently. Would much rather “visually” move commits around than accidentally aim “git history” at an orphaned commit hash no longer in my local branch.
- WorldMaker 2mo ago
  The implication seems to be that `git history` is the higher level, safer `git rebase` for common scenarios. If you are already comfortable with `git rebase` you might just keep using it and never need `git history`. If you are learning git as a junior developer (or teaching/mentoring a junior developer on it) `git history` becomes a good, safe stepping stone for a handful of common tasks. I've been in workplaces where I wished I could disable `git rebase` for all junior developers because they kept learning its footguns faster than its capabilities. A stepping stone seems like a really good idea to me.

skydhash 2mo ago

> Working with lots of changes in parallel on git can be painful. You end up juggling branches and commits, and running scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze. I think that only happens when you work on code as text files (i.e character streams) instead of code (i.e structured content with meaning). Like you have commit A and commit B that is in conflict, you should be glad because that's a rough signal that the intent of A and B differs. Your goal should be to think about how to compose A and B so that both intent survives (unless one supersedes the other). Which means you should be at least familiar with A and B. The issue I found with people that fears conflict is that they often don't understand either A or B (or both). So they are a bad candidate to actually do the operation. It's not a matter of git's cli interface, it's a matter of codebase comprehension and how well you're familiar with the changes in question.

thfuran 2mo ago
Git is the one treating code like a text file instead of code.
- UnfitFootprint 2mo ago
  I pull out difftastic when it’s all too hard for this. Diffs based off tree sitter
  - NateEag 2mo ago
    Don't forget mergiraf, for tree-sitter-based conflict resolution: https://mergiraf.org/ https://mergiraf.org/
    - klibertp 2mo ago
      I absolutely love the images on the landing page. "Inappropriate use of blame, push and pull to resolve a conflict" is pure genius. Even the name had a lot of thought put into it (didn't know about "Giraffe language" before). Beautiful! :)

jolmg 2mo ago

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

catlifeonmars 2mo ago
Do you use git reflog?
- jolmg 2mo ago
  One can also use that, or just `git log -n1` and taking note of the commit hash. So many options.
  - jmholla 2mo ago
    Fun fact: you don't even need the `-n`. `git log -1` does the same thing, for any number. -<number>, -n <number>, --max-count=<number> Limit the output to <number> commits.
  - inigyou 2mo ago
    For scripting: git rev-parse HEAD
- ibizaman 2mo ago
  I do when I forget to run the git branch comment before. But I find it still hard to understand exactly which commit to reset to in the reflog.
  - _ikke_ 2mo ago
    The branch reflog (git reflog <branchname> or git log -g <branchname>) is a lot easier to follow in the case of rebase than the HEAD reflog (which gets an entry for each commit that gets checked out / applied).
2mo ago

paularmstrong 2mo ago

`git history split` is really going to help me help juniors break up their large PRs into smaller more concise changes. If only it had the option to split an entire branch in two easily.

catlifeonmars 2mo ago
What does it mean to split a branch in two?
- rmunn 2mo ago
  Probably to take a series of commits and decide "this one goes on branch A, this one on branch B", e.g. if you intermingled fixing bug A and B in the same branch, you could more easily go through and assign each commit to a new branch. The existing workflow for that would be (there are several possible workflows, but this is what I would do): git checkout intermingled-branch git branch bugfix-A git branch bugfix-B git checkout bugfix-A git rebase -i # Edit the file, keep commits that fix bug A, drop commits that fix bug B git push origin bugfix-A:bugfix-A git checkout bugfix-B git rebase -i # Edit the file, keep commits that fix bug B, drop commits that fix bug A git push origin bugfix-B:bugfix-B
  - LtWorf 2mo ago
    So git cherry-pick?
  - WorldMaker 2mo ago
    Fun fact, you can also automate more of that existing workflow with the rebase interactive TODO list. Roughly something like: pick $ACOMMIT1 edit $ABMIXEDCOMMIT # split out A parts pick $ACOMMIT2 exec make test # test everything compiles update-ref bugfix/A exec git switch --detach main # new branch point pick $BCOMMIT1 edit $ABMIXEDCOMMIT # split out B parts pick $BCOMMIT2 exec make test update-ref bugfix/B exec git merge bugfix/A pick $FOLLOWUPCOMMIT exec make test update-ref intermingled-branch # or bugfix/C It's been a while since I've attempted a rebase TODO list that wild, so I may have forgotten something, but rebase interactive is pretty wild what it will let you try to automate.

bentt 2mo ago

Granted, I have a perspective of a game dev, but this kind of repo defiling just gives me the willies. IMO instead of finding a common ancestor and altering it, just make the desired change upstream and merge it to where it’s needed. If you can’t do that then you have already made a deal with the devil and might reconsider your approach. KISS

hahahaa 2mo ago

I like to be like an accountant. No editing history. Create a new "journal entry" (i.e. commit) to fix.

what 2mo ago
You probably shouldn’t be committing things that are broken…
- moezd 2mo ago
  With tools like GitHub Actions and some added constraints, it's not always possible. You literally need a commit to trigger the CI workflow and it starts to trash your branch. Besides, aren't we all familiar with git commit -m "typo"?
  - ninkendo 2mo ago
    > With tools like GitHub Actions and some added constraints, it's not always possible. You literally need a commit to trigger the CI workflow and it starts to trash your branch I'm with you on your overall point, but as a side note: this state of affairs is so tragic. It's been normalized for there to be test suites that nobody can run except the CI runner, and the only real way to run all the tests is to have GitHub do it. It's pure lock-in, and it's very sad that everything's moved this way. CI actions should be a simple file of "action: command" lines, with at most a separate file that describes when given actions should run. All actions should be runnable locally just as easily as they are in CI. Or if the actions are so complicated they need a complex-ish environment, that environment should be the kind of thing you could run locally too with your hypervisor of choice, without having to think about it. But every VCS host that has an actions/pipelines product is financially incentivized to encourage you not to set things up this way, to preserve their lock-in.
- hahahaa 2mo ago
  Commit yes you absolutely can. Merge to trunk? Probably not, depends on your strategy.
- 2mo ago

shepmaster 2mo ago

> That last part goes further than git rebase --update-refs, which only moves refs sitting inside the range you’re actively rebasing. git history instead finds and rewrites every local branch descended from the commit (while also having an option to limit it to only the current branch). I'm reading that to mean that when I use `git rebase --update-refs` in this situation, where I've currently checked out `D` and update `B` to `B'`: A ──► B ──► C ──► D │ └───► E I'll end up with this state, where `E` remains untouched? A ──► B' ─► C' ─► D' │ └───► B ──► E (EDIT: Originally I had `E` point to `B'`, which doesn't make sense) If I use `git history fixup`, it would also update `E` and end up with this? A ──► B' ─► C' ─► D' │ └───► E' If that's the case, is there a way to get `git rebase` to have the same behavior? I've got decades of `git rebase` burned into my fingers at this point.

jolmg 2mo ago
> I'll end up with this state, where `E` remains untouched? Can't, because a commit's hash takes into account the parent hashes. Haven't used --update-refs, but reading it, it should result in your third graph. So, > is there a way to get `git rebase` to have the same behavior? is already the case.
- rmunn 2mo ago
  Unless E remained untouched because it was not rewritten, and ended up staying parented on B instead of getting reparented onto B'. Which is usually not what you want; most of the time you want E', which is E reparented onto B'. But sometimes you want E to remain untouched and stay parented on the original B. Depends on the situation.
  - jolmg 2mo ago
    Exactly, but the second graph where untouched E is reparented to B' is not something that git would allow.
    - 2mo ago

nativeit 2mo ago

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.

quacked 2mo ago
How do you use it for music composition?
- knodi123 2mo ago
  there are plenty of text-based digital music notation systems. Then, you commit periodically as your composition evolves, and you can have all the history/fork/undo whatever that you might want.
  - seba_dos1 2mo ago
    Also, files don't have to be text-based at all to version them with Git. When you're versioning things for your own sake, there's often not much difference between keeping text and binary files there, as it's not like you'll have to resolve an unexpected conflict.
    - rmunn 2mo ago
      I find it really useful to be able to diff two commits, which if you're using a binary format is only possible if you have a meaningful-diff tool for that format. Some formats have one already created, more formats don't. (Though these days, an LLM might be able to produce something suitable).
- tunesmith 2mo ago
  I use it for lilypond for notation. I always considered it superior to Finale and Sibelius anyway. Not sure how it stacks up against the more modern commercial notation apps. But I love having a real trackable version history of my pieces. What's also cool is the more advanced llms know lilypond and music theory too, so they can do things like... I don't know, check for counterpoint errors. I've used it with limited success to expand my jazz lead sheets into two-hand piano arrangements just for practice exercises.

_nivlac_ 2mo ago

I like `git history reword`, would've found that useful in the past (e.g. fixing a bad typo in an older commit). It sounds like there was probably an equivalent using an existing command but this is easier for me to understand. Thanks for sharing!

paxys 2mo ago

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.

CuriouslyC 2mo ago
Squashing everything has a significant downside compared to functional atomic commits: git-bisect gets WAY less useful.
jolmg 2mo ago
> No one is ever going back and reading individual commits. Straight from the git-log, maybe not, but sometimes you see code that makes you wonder how it came to be and it can help a lot to see it in context of the commit that introduced it. That'd be less helpful if that commit were some huge thing making lots of different changes at once.
- paxys 2mo ago
  Seeing the individual change in the context of the larger feature is actually more helpful. Otherwise you find a tiny commit that changes A to B and then have to chase down 13 other commits around it to figure out why that change was even made.
  - jolmg 2mo ago
    Yeah, there's a balance. I try to make my commits so they make sense on their own. > commits around it to figure out why that change was even made. A commit should be such that the message can articulate the why.
seba_dos1 2mo ago
Of course we do and it helps tremendously when the graph is reasonable.
Myrmornis 2mo ago
One good reason is to keep your tests separate from the fixes that make your tests pass. That way you can check your test fails before the next commit makes it pass, eliminating the risk of a false negative (test passes that would have anyway).

chandlerswift 2mo ago

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 --oneline --show-signature # oops! where'd they go? 5662b2c (HEAD -> main) Second commit 6bf6830 Initial commit amended This has pushed me back to the time-honored `git rebase -i` since I do want to keep my commits signed.

jmholla 2mo ago
Woah! That feels like a huge oversight and like it bypasses standard commit logic. The man pages do say `git history` is experimental. Sounds worth a bug report.

smcameron 2mo ago

> Working with lots of changes in parallel on git can be painful. You end up juggling branches and commits, and running scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze. I mean, just use stgit[1] to maintain a stack of patches instead of parallel branches, it's so much better. You can easily wrangle thousands of patches (aka commits) with stgit. A lot of people, on first encountering stgit, read a bit about it, think "why do I need this? I can do the same thing with just plain ol' git.". Yeah, you can. But not at scale. Not practically. Not with thousands of commits. And it makes the case when you just have a few tens of commits absolutely trivial. Try it for awhile and you'll find it indispensible. [1] https://stacked-git.github.io/ https://stacked-git.github.io/

froh 2mo ago

TIL, thx :-) somewhat related Q: how do you give two files the same ancestor? so git log will for each show the history to the beginnings of the originally unsplit file? useful for splitting large files.

bonzini 2mo ago
That's not possible, because files don't have ancestors in git. Each commit's tree is tracked independently and copy/move is just something that's detected via heuristics.
- account42 2mo ago
  But those heuristics could be better than they are now so that a git log <file> will show the shared history for both copies.
- froh 2mo ago
  I meanwhile understood that you can commit a copy of a file and then edit both, and then the ancestry tracking options to git log resolve the two split parts ancestry just fine.

krick 2mo ago

> scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze Complete bullshit. Might as well say "scary screwdriver that can turn up in your recturm if you so much as sneeze". Sure, I believe that might have happened to you (heard stories from friends that work in the emergency room), but I run rebase -i 10 times during the time I work on each branch (literally: I don't even care to write "proper" commit messages while writing the code, will reorganize and clean them up later anyway), and it never happened to me.

eviks 2mo ago
> commit messages while writing the code, will reorganize and clean them up later anyway That's just too primitive of a workflow, so repeating it will not run into the risk. You need to add an actual conflict in some feature branch and get stuck being forced to resolve it to compete the rebase to appreciate the op warning

rushil_b_patel 2mo ago

the "reword" option is same as git rebase -i HEAD~n, and then instead of pick replace it with reword to change the commit messsage. BTW I have made a notion doc on git commands: https://rushilpatel.notion.site/git https://rushilpatel.notion.site/git

eviks 2mo ago

> Every 3 months, for the last 1.5 years, I try it out for a few days, really trying to make it part of my workflow but eventually I give up and go back to git.1 That's not really trying, let's assume you need 1 week to change ingrained workflows, so you just waste time every 3 months stopping right before the threshold. Better try once every year, but for a few*4 days...

kazinator 2mo ago

The thing is, when you are rewriting history to change an old commit, you have to solve the little problem that git commit messages refer to hashes such as: This regression was caused in <hash> on December 19, 2017. The fixup and rewrite of history has to ferret out these has references and fix them to the new hash of the same commit. I have scripted this before!

inigyou 2mo ago
Don't change old commits. Change commits you haven't pushed yet.
- kazinator 2mo ago
  That's not for you to dictate to someone about some project you have no idea about. Git is not a religion or cult. Whether you're rewriting published or unpublished commits, this particular problem is the same. If the commit series contains self-references---later commits in the series have commit messages which refer to the hashes of earlier commits---those references make no sense at all when the series is pushed upstream; they will refer to garbage objects that exist in your repo only, and which will eventually disappear for you too.
  - inigyou 2mo ago
    If you think me telling you how to use a product is religious or cult indoctrination, I dont really see how you are getting anything done while dodging the high priests of "man" and "info"
    - kazinator 2mo ago
      "Never rewrite public history", while it is a directive that talks about how to use a product or not used it, is just your personal preference, and nothing correct or incorrect. Just like "never type a profane word into Vim" is ostensibly a statement about how to use Vim, but of no technical value related to Vim use. It is nothing similar to advice such as using a screwdriver to drive screws and a hammer for nails. Some people regard the git repository as the object they are working on and want to create the perfect history in it, yet also to ship regularly. That requires shipped history be revised. It's entirely possible to work productively with an upstream that revises history, producing non-fast-forward changes. There are things you have to do and know that are not required in FF-only workflows, but nothing too terrible.

bad_username 2mo ago

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

xyzsparetimexyz 2mo ago
No it doesn't. Half the git commands are low level, half are high level. It's not 1:1 at all.
- palata 2mo ago
  So when someone tells you "understanding X helped me a lot", your answer is "no, it did not"? > It's not 1:1 at all. I don't see any mention of "1:1" in the parent.
  - jesse_ash 2mo ago
    > The UI of git directly reflects its internals Maybe?
  - debugnik 2mo ago
    They're replying to > The UI of git - for better or worse - directly reflects its internals.
    - palata 2mo ago
      > Half the git commands are low level, half are high level. Can't we say that the low level level commands reflect its internal? ...
      - twister2920 2mo ago
        of course we can, that's not what the original comment said though

SCUSKU 2mo ago

These graphics are great. Makes for a skimmable high signal article, nice work!

xyzsparetimexyz 2mo ago

Tldr; use jj

jonathanlydall 2mo ago

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.html 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 <current reference> onto this" option: https://tortoisegit.org/docs/tortoisegit/tgit-dug-showlog.html 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.

Cthulhu_ 2mo ago
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.
crabbone 2mo ago
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.

Sharlin 2mo ago

Huh, TIL about `git commit —fixup`.

Cthulhu_ 2mo ago
Yeah I learned that one a few months ago, before that I'd use interactive rebase and shuffle the commits around manually in the editor that opens. I appreciate that these commands are just utilities / conveniences on top of a stable base though.

deleted 2mo ago

[deleted]

rom1v 2mo ago

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

anuramat 2mo ago

is there a way to use it with lazygit? unfortunately I'm addicted atp, and "autorebase branches" is exactly what I was missing the entire time

niels_bom 2mo ago
lazygit can already reword

quibono 2mo ago

> scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze I'm glad to hear it, I thought that was just me. It gets especially hairy when moving commits around... Plus I have 3-way diffs enabled and I usually get confused by which section is which at least once a day. Also: does anyone know if `magit` has history support?

deleted 2mo ago
[deleted]
seanc 2mo ago
Not as such, but out of the box you get reword and fixup as first-class rebase macros. I use them all the time. If you wanted to split a commit you'd still have to use a magit-assisted rebase. So if magit added explicit 'history' support I just about wouldn't notice, it would mostly be under the hood.
- quibono 2mo ago
  100% agree, the fixup macro is amazing. It even fails gracefully when unable to commit for whatever reason. The split one would be handy though.

whilenot-dev 2mo ago

Cool, didn't know about `history fixup`! I only ever did the manual dance with `rebase -i` and `rebase` for all other branches. That and `history split` will sure come handy! What happens with a conflicting fix though? Do I still need to resolve all conflicts on the base branch and `reset --hard` all other branches?

tangsoupgallery 2mo ago

[flagged]

klibertp 2mo ago

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's strengths and use it in favorable conditions - it is young, after all). Get acquainted with `jj` on its terms, and if things click for you, you'll be a bit better prepared for the bumpy road that is Git interop later on. [1] https://news.ycombinator.com/item?id=48903054 https://news.ycombinator.com/item?id=48903054

steeleduncan 2mo ago
In princple JJ has non-Git backends, but the only backend they state as being production ready is the Git backend. JJ without the Git interop is more a concept than a reality right now. I love JJ, and the mental model of source control it presents, and I will continue to use it. However, still needing to "drop down" to Git every now and again to get something done makes it feel very much like a convenient wrapper on top of Git rather than a new SCM. If Git adds commands to support the JJ workflow, it would be hard to justify having JJ installed any more.
- klibertp 2mo ago
  The backend itself is fine, it's just trying to use JJ as a Git frontend for projects developed on Github (among 20 other devs using git, where each of them uses git through different interface and/or in different style) that's currently not ideal :( > However, still needing to "drop down" to Git every now and again to get something done makes it feel very much like a convenient wrapper on top of Git rather than a new SCM. Yeah, but I think that's fine. Git is a solid foundation; it's not wrong to try to build on it initially. It gets you a usable implementation faster. It is a pain point, though. > If Git adds commands to support the JJ workflow, it would be hard to justify having JJ installed any more. Is that a danger? I don't see Git as a fast-moving target. And among all the "convenient wrappers on top of Git", JJ seems to have the design least tied to Git, so I think it has the highest chance of breaking out of the Git dependency in the future.

cnxiaom 2mo ago

[flagged]

blackcube42 2mo ago

[flagged]

warmwaffles 2mo ago

All I want to do is reword and correct commit messages / improve them without rebasing everything. When working with teams this is a sure fire way to create absolute chaos.