Re: [PATCH/RFC 0/2] rebase: add switches to control todo-list setup

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Apr 22, 2019, 14:44 UTC
Message-ID: <623d6ebd-60c4-916d-6295-4c648dbf3932@gmail.com>
In-Reply-To: <xmqqk1fm9712.fsf@gitster-ct.c.googlers.com>

On 22/04/2019 02:13, Junio C Hamano wrote:

Show 22 quoted lines

> Phil Hord <phil.hord@gmail.com> writes:
> 
>> Currently it supports these switches:
>>
>>      usage: git rebase [-i] [options] [--exec <cmd>] ...
>>         :
>>      --break <revision>    stop before the mentioned ref
>>      --drop <revision>     drop the mentioned ref from the todo list
>>      --edit <revision>     edit the mentioned ref instead of picking it
>>      --reword <revision>   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 <revision>    fixup the mentioned ref instead of picking it
>>      --squash <revision>   squash the mentioned ref instead of picking it
>>      --pick <revision>     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"

Show 5 quoted lines

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

Show 51 quoted lines

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