Re: [PATCH 3/3] rebase: new convenient option to edit a single commit

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

 



On Tue, Mar 4, 2014 at 3:59 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote:
>> On Tue, Mar 4, 2014 at 3:28 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
>>> 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].

Just to be clear I didn't mean to modify --fixup behavior. It could be
--amend-old-commit or something like that. It's actually --amend that
made me want to put the UI in "git commit". But it's a bad idea
(besides what you pointed out) because after you're done, you still
need to do "git rebase --continue".

> 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

Sounds good.

>     git rebase --fixup COMMIT
>     git rebase --squash COMMIT

This is not interactive (except when merge conflicts occur), is it?

A bit off topic. I sometimes want to fix up a commit and make it stop
there for me to test it again but there is no such command, is there?
Maybe we could add support for "fixup/edit" (or "fe" for short) and
"squash/edit" ("se"). Not really familiar with the code base to do
that myself quickly though.

>     git rebase --kill COMMIT
>
>         Remove the commit from history, like running "git rebase
>         --interactive" then deleting that line.

Yes! Done this sometimes (not so often) but a definitely nice thing to
have. I'd go with --remove or --delete though.
-- 
Duy
--
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




[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]