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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 22/04/2019 02:13, Junio C Hamano wrote:
Phil Hord <phil.hord@xxxxxxxxx> 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"
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@xxxxxxxxxxxxxxxxxx/

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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux