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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 22, 2019, 01:13 UTC
Message-ID: <xmqqk1fm9712.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20190422000712.13584-1-phil.hord@gmail.com>

Phil Hord <phil.hord@gmail.com> writes:

Show 15 quoted lines

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

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.