{"thread":{"id":"65749","subject":"git history feedback","startedAt":"2026-06-04T08:17:17Z","lastAt":"2026-06-04T09:34:56Z","messageCount":3,"participants":["Rasmus Villemoes","Patrick Steinhardt","Kristoffer Haugsbakk"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"544697","messageId":"87ecimhg8s.fsf@rasmusvillemoes.dk","threadId":"65749","inReplyTo":null,"subject":"git history feedback","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2026-06-04T08:17:07Z","receivedAt":"2026-06-04T08:17:17Z","isPatch":false,"body":"Hi\n\nAs soon as I saw the announcement of 'git history', I knew that was\nsomething I was gonna use a lot. Especially the split functionality has\nalways been somewhat of a hassle (at least for me) to do via an\ninteractive rebase. I've played around with it a little, and it seems to\nwork as it says on the tin.\n\nSo today I had occasion to put it to real use, and then I found two\nthings I'd like to be able to do with it:\n\nWhen a commit needs to be split into three or more commits, it is a\nlittle cumbersome to do iteratively, since the new commit to split\nobviously has a new sha, so one first has to figure out what that new id\nis and then do another \"git history split\". For higher values of \"three\"\nthat becomes rather tedious. So it would be nice if there was an\niterative mode, which after splitting off the first commit would\nautomatically start again with the new child commit.\n\nIf \"git add -p\" had an answer meaning \"yes to this hunk and all\nfollowing in this file and all remaining files as well\", this could\nprobably even be the default behaviour of \"git history split\", as it\nwould just require that one extra answer to be given after the first\ncommit is split off in order to keep the current behaviour. Otherwise,\nI'd also be happy to have \"git history iter-split\" or \"git history split\n--iter\" or any other spelling.\n\nThe other thing I'd like is a sort of ultimate version of the above:\nWhat I needed in the concrete case at hand was actually to split two\ncommit into n individual hunks each, then do an interactive rebase to combine\nthose 2n commits to n commits (I had done changes \"row-wise\", but needed\nto change them to \"column-wise\"). For that, I would like to have had a\ncompletely automatic \"git history atomize\" that would split a commit\ninto individual hunks, prefixing the commit subject with\ne.g. \"[<filename> -- hunk #nn]\". A subsequent 'git rebase -i' could then easily\nrearrange those and squash the related hunks.\n\nAside: are experimental commands eligible for teaching the completion\nlogic about them? I.e., can we add a __git_history() to\ngit-completion.bash? Aside from the obvious \"let it know about existing\nsubcommands\", I'd love for \"git history split <TAB>\" to show the most\nrecent ~20 (or something) commits in one-line format, stopping if\nthere's a merge commit.\n\nThanks,\nRasmus\n"},{"id":"544699","messageId":"aiE5w_8Oxv-I54zy@pks.im","threadId":"65749","inReplyTo":"87ecimhg8s.fsf@rasmusvillemoes.dk","subject":"Re: git history feedback","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-06-04T08:39:31Z","receivedAt":"2026-06-04T08:39:39Z","isPatch":false,"body":"On Thu, Jun 04, 2026 at 10:17:07AM +0200, Rasmus Villemoes wrote:\n> Hi\n> \n> As soon as I saw the announcement of 'git history', I knew that was\n> something I was gonna use a lot. Especially the split functionality has\n> always been somewhat of a hassle (at least for me) to do via an\n> interactive rebase. I've played around with it a little, and it seems to\n> work as it says on the tin.\n\nHappy to hear!\n\n> So today I had occasion to put it to real use, and then I found two\n> things I'd like to be able to do with it:\n> \n> When a commit needs to be split into three or more commits, it is a\n> little cumbersome to do iteratively, since the new commit to split\n> obviously has a new sha, so one first has to figure out what that new id\n> is and then do another \"git history split\". For higher values of \"three\"\n> that becomes rather tedious. So it would be nice if there was an\n> iterative mode, which after splitting off the first commit would\n> automatically start again with the new child commit.\n\nThat's fair, and also something that was discussed when initially\nintroducing the \"split\" subcommand. We don't have that mode right now,\nbut I think it would make sense to maybe add a new option that makes us\nsplit repeatedly until all chunks have been exploded into separate\ncommits.\n\n> If \"git add -p\" had an answer meaning \"yes to this hunk and all\n> following in this file and all remaining files as well\", this could\n> probably even be the default behaviour of \"git history split\", as it\n> would just require that one extra answer to be given after the first\n> commit is split off in order to keep the current behaviour. Otherwise,\n> I'd also be happy to have \"git history iter-split\" or \"git history split\n> --iter\" or any other spelling.\n\nYeah. From my perspective, having this available as an option would be\nthe best path forward. But I'm also open to alternatives as you suggest.\n\n> The other thing I'd like is a sort of ultimate version of the above:\n> What I needed in the concrete case at hand was actually to split two\n> commit into n individual hunks each, then do an interactive rebase to combine\n> those 2n commits to n commits (I had done changes \"row-wise\", but needed\n> to change them to \"column-wise\"). For that, I would like to have had a\n> completely automatic \"git history atomize\" that would split a commit\n> into individual hunks, prefixing the commit subject with\n> e.g. \"[<filename> -- hunk #nn]\". A subsequent 'git rebase -i' could then easily\n> rearrange those and squash the related hunks.\n\nIt could easily be another option: `git history split --explode` for\nexample, which seems to be a common term for such an operation.\n\nRegarding the subsequent rebase: I have one more patch series cooking\nlocally that implements `git history move` to move around commits, and I\ndid have the plan to eventually also implement `git history squash` to\nsquash commit A into commit B. But when handling many commits it might\neven be easier to use interactive rebases instead.\n\nWell, unless we eventually maybe even get something like a graphical\ninterface. I was playing around with a TUI interface for git-history(1)\nthat lets you move commits around without the hassle of the command\nline. But that's certainly something that's still going to take a while\nto materialize, if it ever does.\n\n> Aside: are experimental commands eligible for teaching the completion\n> logic about them? I.e., can we add a __git_history() to\n> git-completion.bash? Aside from the obvious \"let it know about existing\n> subcommands\", I'd love for \"git history split <TAB>\" to show the most\n> recent ~20 (or something) commits in one-line format, stopping if\n> there's a merge commit.\n\nI just haven't gotten around to it yet. I'd certainly welcome the\naddition of command line completion.\n\nThanks for your feedback!\n\nPatrick\n"},{"id":"544705","messageId":"0299ea0d-a042-4457-bd7e-0904b38a219b@app.fastmail.com","threadId":"65749","inReplyTo":"87ecimhg8s.fsf@rasmusvillemoes.dk","subject":"Re: git history feedback","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2026-06-04T09:34:35Z","receivedAt":"2026-06-04T09:34:56Z","isPatch":false,"body":"On Thu, Jun 4, 2026, at 10:17, Rasmus Villemoes wrote:\n>[snip]\n>\n> So today I had occasion to put it to real use, and then I found two\n> things I'd like to be able to do with it:\n>\n> When a commit needs to be split into three or more commits, it is a\n> little cumbersome to do iteratively, since the new commit to split\n> obviously has a new sha, so one first has to figure out what that new id\n> is and then do another \"git history split\". For higher values of \"three\"\n> that becomes rather tedious. So it would be nice if there was an\n> iterative mode, which after splitting off the first commit would\n> automatically start again with the new child commit.\n\nFor commit subject `anchor` I would do something like this.\n\n1. `git history split :/anchor`\n2. Split out the first commit with a new message; keep the `anchor`\n   subject of the original\n3. Repeat (1)\n\n>[snip]\n"}]}