On 03/04/2014 03:08 AM, Duy Nguyen wrote:
> On Tue, Mar 4, 2014 at 3:28 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
>> On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> wrote:
>>> "git rebase -e XYZ" is basically the same as
>>>
>>> EDITOR="sed -i '1s/pick XYZ/edit XYZ/' $@" \
>>> git rebase -i XYZ^
>>>
>>> In English, it prepares the todo list for you to edit only commit XYZ
>>> to save your time. The time saving is only significant when you edit a
>>> lot of commits separately.
>>
>> Is it correct to single out only "edit" for special treatment? If
>> allowing "edit" on the command-line, then shouldn't command-line
>> "reword" also be supported? I, for one, often need to reword a commit
>> message (or two or three); far more frequently than I need to edit a
>> commit.
>>
>> (This is a genuine question about perceived favoritism of "edit", as
>> opposed to a request to further bloat the interface.)
>
> Heh I had the same thought yesterday. The same thing could be asked
> for "git commit --fixup" to send us back to the fixed up commit so we
> can do something about it. If we go along that line, then "git commit"
> may be a better interface to reword older commits..
I disagree. "git commit --fixup" doesn't rewrite history. It just adds
a new commit with a special commit message that will make it easier to
rewrite history later. I think it would be prudent to keep the
history-rewriting functionality segregated in "git rebase", which users
already know they have to use with care [1].
But the next question is whether "git rebase" should have shortcuts for
*most* of its line commands. All of the following seem to make sense:
git rebase --edit COMMIT
A long-form for the -e option we have been talking about.
It is unfortunately that this spelling sounds like the
"--edit" option on "git commit --edit" and "git merge --edit",
so people might use it when they really mean
"git rebase --reword COMMIT".
git rebase --reword COMMIT
git rebase --fixup COMMIT
git rebase --squash COMMIT
git rebase --kill COMMIT
Remove the commit from history, like running "git rebase
--interactive" then deleting that line.
I'm quite confident that I would use all of these commands.
Moreover, it would logically be reasonable to allow multiple of these
options, at least as long as they have distinct COMMIT arguments.
Though, as Duy points out, it might in practice be easier to edit the
todo list in an editor rather than trying to do multiple "edits" at a
time via the command line.
Some thought would have to go into the question of if/how these commands
should interact with "git rebase --autosquash" (which, don't forget, can
also be requested via rebase.autosquash).
Michael
[1] OK, granted, there is "git commit --amend", which rewrites history
too. But it rewrites only the last commit, which is less likely to be
problematic.
--
Michael Haggerty
mhagger@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html