git rebase -f --autosquash

git rebase -f --autosquash

[Andy Kitchen]

Hi All, 

I commonly use:

git commit --fixup <commit>

to preen commits before pushing them. I can run

git rebase -i --autosquash HEAD@{upstream}

to apply these fixes, however, autosquash only
applies to interactive rebases.

Because I am sure that my fixes are applicable,
I would like to be able to non-interactively autosquash, possibly
like so:

git rebase -f --autosquash HEAD@{upstream}


Would anyone else find this feature useful?


Kind Regards

AK

Re: git rebase -f --autosquash

[Carlos Martín Nieto]

On Sat, 2012-05-12 at 20:38 +1000, Andy Kitchen wrote:
> Hi All, 
> 
> I commonly use:
> 
> git commit --fixup <commit>
> 
> to preen commits before pushing them. I can run
> 
> git rebase -i --autosquash HEAD@{upstream}
> 
> to apply these fixes, however, autosquash only
> applies to interactive rebases.
> 
> Because I am sure that my fixes are applicable,
> I would like to be able to non-interactively autosquash, possibly
> like so:
> 
> git rebase -f --autosquash HEAD@{upstream}
> 
> 
> Would anyone else find this feature useful?

If you're confident that an autosquash would produce the right
instructions, you can skip the editor phase by setting the EDITOR
environment variable to something that won't spawn an editor. Popular
variants are 'cat' and ':'. I prefer 'cat' because then I can see the
instruction set in the terminal and verify it's the correct one. You can
also set the rebase.autosquash config variable and then you just have to
type

    EDITOR=cat git rebase -i @{u}

or

    EDITOR=: git rebase -i @{u}

and maybe set an alias (I have a 'riu' alias for 'rebase -i @{u}').

I'm not saying an extra option wouldn't be useful, but there's already
ways of making git not spawn a text editor which works for all commands,
and you can even make an alias that will do precisely that.

   cmn

Re: git rebase -f --autosquash

[Junio C Hamano]

Carlos Martín Nieto <cmn@elego.de> writes:

>     EDITOR=: git rebase -i @{u}
>
> and maybe set an alias (I have a 'riu' alias for 'rebase -i @{u}').
>
> I'm not saying an extra option wouldn't be useful, but there's already
> ways of making git not spawn a text editor which works for all commands,
> and you can even make an alias that will do precisely that.

Given "EDITOR=: git commit args..." and "EDITOR=: git merge args..." are
equivalent to giving "--no-edit" option to these commands, I would imagine
"git rebase opts... --no-editor args..." would not be such a stretch.

Re: git rebase -f --autosquash

[Andy Kitchen]

On Tuesday, 15 May 2012 at 2:35 AM, Junio C Hamano wrote:
> Given "EDITOR=: git commit args..." and "EDITOR=: git merge args..." are
> equivalent to giving "--no-edit" option to these commands, I would imagine
> "git rebase opts... --no-editor args..." would not be such a stretch.

I agree. However, I think it would be more intuitive to make --autosquash
work with -f or even just on its own in non-interactive mode.
It definitely makes sense practically and semantically to autosquash
non-interactively. Otherwise one needs to activate interactive mode
and effectively disable it in the same command which is a bit esoteric.

I am of the opinion that autosquashing is such a useful feature,
it's even worth having a separate command:

$ git fix

For generally rebuilding commits based on directives
placed in commit messages. Especially because it integrates
nicely with `git commit --fixup' as a kind of super amend. While
this can be easily added with a bit of customisation, I think
that it is generally applicable and useful enough to warrant being
a default part of git.

In summary, I propose:

1a)

$ git rebase -f --autosquash <base>
is made to be effectively equivalent to:
$ EDITOR=: git rebase -i --autosquash <base>

1b)

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



3) A new command is created, for example one of:

$ git fix
$ git squash
$ git autosquash

For preening commits before pushing them upstream.

The default base for these operations would be HEAD@{upstream}

A config option could also be added to warn the user before pushing
commits with messages of the form /^fixup!/ etc.

It could also be less ad-hoc in its operation than --autosquash
currently is. For example, `git commit --fixup' could note the intended
target for the fix allowing `git fix' to operate correctly even when two
commits share the same message.




Of course as with any polite feature request, I am happy to write the
appropriate code, however not being familiar with the git code-base,
I would require some guidance.


Thank you for your time, suggestions welcomed

AK

Re: git rebase -f --autosquash

[Vincent van Ravesteijn]

Op 26-5-2012 9:30, Andy Kitchen schreef:
> On Tuesday, 15 May 2012 at 2:35 AM, Junio C Hamano wrote:
>> Given "EDITOR=: git commit args..." and "EDITOR=: git merge args..." are
>> equivalent to giving "--no-edit" option to these commands, I would imagine
>> "git rebase opts... --no-editor args..." would not be such a stretch.
> I agree. However, I think it would be more intuitive to make --autosquash
> work with -f or even just on its own in non-interactive mode.
> It definitely makes sense practically and semantically to autosquash
> non-interactively. Otherwise one needs to activate interactive mode
> and effectively disable it in the same command which is a bit esoteric.
> ...
> In summary, I propose:
>
> 1a)
>
> $ git rebase -f --autosquash<base>
> is made to be effectively equivalent to:
> $ EDITOR=: git rebase -i --autosquash<base>
>

I think the following one-line patch will effectively do what you want.

diff --git a/git-rebase.sh b/git-rebase.sh
index 24a2840..c4ffdcd 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -228,8 +228,9 @@ do
      -p)
          preserve_merges=t
          test -z "$interactive_rebase" && interactive_rebase=implied
          ;;
      --autosquash)
          autosquash=t
+        test -z "$interactive_rebase" && interactive_rebase=implied
          ;;
      --no-autosquash)


Vincent

Re: git rebase -f --autosquash

[Junio C Hamano]

Andy Kitchen <kitchen.andy@gmail.com> 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.

Re: git rebase -f --autosquash

[Phil Hord]

On Sun, May 27, 2012 at 2:44 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Andy Kitchen <kitchen.andy@gmail.com> 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

Re: git rebase -f --autosquash

[Junio C Hamano]

Phil Hord <phil.hord@gmail.com> writes:

> ...  That both are
> required seems to me to be an embarrassing, historical implementation
> detail.

I do not know if we are discussing the same thing.

There is nothing historical in that "--interactive" is the word used
to tell the command that the user wants to replay commits in an
order that is different from the order they were found in the
original commit DAG.  If you want to tweak the order, you use
"interactive". If you don't, you don't.

There indeed is implementation detail to worry about. The "-p" mode
that is *not* about letting the user modify the order of replayed
commits internally does use the same machinery as interactive, but
that is hidden from the end user (the "implied" value in
$interactive_rebase in git-rebase.sh makes this difference).

But this case is not about replaying the commit without reordering.

If you are proposing to rename "--interactive" to "--reorder" or
something, with a solid migration plan to keep the current users
happy, and possibly are proposing to add non-interactive autosquash
implementation outside git-rebase--interactive.sh, the issue would
entirely be different, but I somehow do not sense that is the
direction in which you are trying to go.