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