Re: git rebase -f --autosquash

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

 



On Sun, May 27, 2012 at 2:44 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Andy Kitchen <kitchen.andy@xxxxxxxxx> writes:
>
>> 1a)
>>
>> $ git rebase -f --autosquash <base>
>> is made to be effectively equivalent to:
>> $ EDITOR=: git rebase -i --autosquash <base>
>
> I am not sure how you do the above without breaking the existing users and
> other people's use cases, given that giving --force option to rebase has
> totally different meaning from the above (i.e. "do not refuse to rebase
> even though the current branch is up to date with respect to <base>").
> Such an option overloading, especially for an option "force", feels adding
> confusion without much merit---it is unclear what kind of "forcing" is it
> calling for.
>
>> 1b)
>>
>> $ git rebase --autosquash <base>
>> (i.e. -f is implicit) is made to be effectively equivalent to:
>> $ EDITOR=: git rebase -i --autosquash <base>
>
> I do not think this would work.
>
> The --autosquash option is merely a way to help reordering by moving the
> "fixup!" commits in the history around without manual action You may have
> commits created with "fix" but _other_ commits in the history that you
> want to manually reorder in the insn sheet.
>
>> 3) A new command is created, for example one of:
>>
>> $ git fix
>> $ git squash
>> $ git autosquash
>
> All of these names are so broad and generic---I am not sure if any of them
> will "click" with your single narrow use case, which as far as I can see
> is "I want rebase with --autosquash but I am not going to do any other
> editing."  None of the above three words hints the new command is about
> rebasing.
>
> Even though I find the "I want rebase with --autosquash but I am not going
> to do any other editing." is a workflow element that often appears in the
> real life, I do not think it deserves its own command that is separate
> from "rebase".  It is merely a slightly different way to drive "rebase",
> after all.
>
> And that "I want rebase with --autosquash but I am not going to do any
> other editing" is where my suggestion to use "--no-edit" comes from.

Your suggestion is not that he use "rebase --autosquash --no-edit" but
that he use "rebase --autosquash --interactive --no-edit".  The last
two options appear to be opposites from the outsider's perspective and
would seem to be superfluous.  I understand from the code perspective
that "rebase" and "rebase --interactive" are in separate
implementations; but from this user's perspective, they are the same
with one distinction; the former performs an automatic sequence of
commit actions, while the latter shows the sequence first and allows
me to edit it.  So the command "git rebase --interactive --no-edit"
reads to me like "git rebase --ask-me-how --noask-me-how", which is
nonsensical, at best.

The only reason Andy would have to add --no-edit to his command is
because the --autosquash option is, inexplicably, only valid in
--interactive mode.  This seems pointless from this user's
perspective.  Why does the --autosquash option also need the
"--ask-me-how" option?  If I don't need the --ask-me-how action, I
should simply leave it off.  I should not need to also add
"--no-ask-me-how".

That would look nonsensical.

Maybe it seems explicable to you because "squash" is a todo-list
command which is only valid in --interactive.  But this, too, is a
detail best left buried in the implementation and not exposed to the
CLI, imho.

>> 1b)
>>
>> $ git rebase --autosquash <base>
>> (i.e. -f is implicit) is made to be effectively equivalent to:
>> $ EDITOR=: git rebase -i --autosquash <base>

This would be my preference, except that it is the "--interactive
--no-edit" which is made implicit when --autosquash is used without
"--interactive".  The fact that these two options are implicit should
be hidden from the user and not required of him.  That both are
required seems to me to be an embarrassing, historical implementation
detail.

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