Hi Chris, On 30/11/2017 23:40, Chris Nerwert wrote: > > I'm actually doing the described workflow quite often with git rebase > when working on a topic. Given the following structure: > > ---o (master) > \ > o---A---B---C (topic) > > When I want to make changes to commit A one option is to make them > directly on topic, then do "git commit --fixup A", and then eventual > interactive rebase onto master will clean them up: > > ---o (master) > \ > o---A---B---C---f!A (topic) > > However, sometimes this breaks when changes in B or C conflict > somehow with A (which may happen quite a lot during development of a > topic), so the rebase will not apply cleanly. So sometimes I make a > temporary branch from A, commit the fixup there: > > ---o (master) > \ > o---A---B---C (topic) > \ > f!A (temp) > > and then use "git rebase --onto temp A topic" to move the topic back > on track: > > ---o (master) > \ > o---A---f!A (temp) > \ > B'---C' (topic) > > after which the final cleanup rebase is much easier to do. > > Obviously, all the branch switching and rebasing does take its tall > on file modifications. >From use case you described (and which I often experience myself), it seems plain "git commit --onto A" would be of help here, committing fixup onto A directly, without a need to switch to it (branch or not), a case I`m discussing with Hannes in that other sub-thread[1] of this e-mail, too. But from there, your flow takes a different direction, using rebase, while this whole thread started around some merge-like functionality. I can imagine a user interface doing what you (and I) would like, something like: (1) git commit --onto A --rebase ..., where your changes would first be committed onto commit A, and then commits from A (excluded) to HEAD (included) rebased onto this new commit. BUT, as far as it seems to me, rebase currently touches working tree for each operation (am I wrong here?), so once the rebase sequence is initiated, it would internally still need to checkout to your new fixup commit (on top of A), and then proceed applying changes and changing working tree with each commit being rebased, overall failing to address your main concern - needless (untouched) file modifications, even in case of no conflicts. I find this scenario quite interesting as well, but I`m afraid it may currently be out of scope of what I`m trying to accomplish with "git commit --onto[-parent]", for the most part because it looks like it would need "index only rebase" first (not touching working tree, that is)...? If we had that, it would/should be pretty easy to add it into the mix with "git commit --onto" here, ending up with something as imagined in command line (1) above :) I`ll make a note of it, thanks. Any further help appreciated, of course :) Regards, Buga [1] https://public-inbox.org/git/0F30BEF8-A9F7-43B9-BC89-4B9CD7AF3E16@xxxxxxxxx/T/#me830a80d745df60ae8bd6a2e67eee4bd4dabf56c
