From: Phillip Wood Date: Mon, 22 Apr 2019 14:44:00 GMT Subject: Re: [PATCH/RFC 0/2] rebase: add switches to control todo-list setup Message-ID: <623d6ebd-60c4-916d-6295-4c648dbf3932@gmail.com> In-Reply-To: On 22/04/2019 02:13, Junio C Hamano wrote: > Phil Hord writes: > >> Currently it supports these switches: >> >> usage: git rebase [-i] [options] [--exec ] ... >> : >> --break stop before the mentioned ref >> --drop drop the mentioned ref from the todo list >> --edit edit the mentioned ref instead of picking it >> --reword reword the mentioned ref instead of picking it >> >> I have plans to add these, but I don't like how their "onto" will be >> controlled. More thinking is needed here. >> >> --fixup fixup the mentioned ref instead of picking it >> --squash squash the mentioned ref instead of picking it >> --pick pick the mentioned ref onto the start of the list > > Yeah, I can see that it may be very useful to shorten the sequence > to (1) learn what commits there are and think what you want to do > with each of them by looking at "git log --oneline master.." output > and then to (2) look at and edit todo in "git rebase -i master". >> I personally would be fine without the step (1), as what "rebase -i" > gives me in step (2) essentially is "log --oneline master..". So I > am not quite getting in what way these command line options would be > more useful than without them, though, especially since I do not see > how well an option to reorder commits would fit with the way you > structured your UI. Doing "git rebase -i master" and then editing the todo list has the side effect of rebasing the branch. Often I find I want to amend or reword a commit without rebasing (for instance when preparing a re-roll). To do this I use a script that runs something like GIT_SEQUENCE_EDITOR="sed -i s/pick $sha/edit $sha/" git rebase -i $sha^ and I have my shell set up to interactively select a commit[1] so I don't have to cut and paste the output from git log. I've found this really useful as most of the time I just want to amend or reword a commit or squash fixups rather than rearranging commits. The script knows how to rewind a running rebase so I can amend several commits without having to start a new rebase each time. So I can see a use for --edit, --reword & --drop if they selected a suitable upstream to avoid unwanted rebases (I'm not so sure about the others though). If you want to rebase as well then I agree you might as well just edit the todo list. Best Wishes Phillip [1] Something like https://public-inbox.org/git/87k3xli6mn.fsf@thomas.inf.ethz.ch/ > Having already said that, if I were to get in the habit of looking > at "log" first to decide and then running "rebase -i" after I made > up my mind, using a tweaked "log --oneline" output that looks > perhaps like this: > > $ git log --oneline master.. | tac | cat -n > 1 xxxxxx prelim cleanly > 2 xxxxxx implement the feature > 3 xxxxxx document and test the feature > 4 xxxxxx the final step > 5 xxxxxx fixup! implement the feature > > I think I may appreciate such a feature in "rebase -i" even more, if > the UI were done a bit differently, e.g. > > $ git rebase -i --edit="1 3 2 b f5 b r4" master.. > > to mean "pick the first (i.e. bottommost) one, pick the third one > for testing, pick the second one, then break so that I can test, > fixup the fifth one, break to test, and finally pick the fourth > one but reword its log message", to come up with: > > pick xxxxxx prelim cleanly > pick xxxxxx document and test the feature > pick xxxxxx implement the feature > break > fixup xxxxxx oops, the second one needs fixing > break > reword xxxxxx the final step > > I am guessing that the way you did it, the above would be impossible > (as it requires reordering) but given that you would leave most of > the 'pick's intact and only tweak them in-place into drop, edit, > reword, etc., that may not be too bad, but I suspect that it would > become very verbose. > > $ git rebase -i \ > --pick HEAD~4 --pick HEAD~3 --break --fixup HEAD \ > ... > > The --edit alternative I threw in in the above would make it > necessary for the user to spell out all the picks, and that would be > more cumbersome given our assumption that most picks will be left > intact, but then we could do something like > > --edit="1-4 5e 6 8-" master.. > > to say "pick 1 thru 4, edit 5, pick 6, drop 7 and pick 8 thru the > end". > > I dunno. >