Git Feature Request (Fixdown in interactive rebase)

Git Feature Request (Fixdown in interactive rebase)

[Mike McLean]

I initially raised this as a FR with my git UI of choice, and was told
that it was actually something that git itself would need to do ...
and that the standard way to raise Feature Requests was to email this
list.

Apologies if that's not actually what I should be doing - please let
me know if this is not an intended use.

=-=-=-=-=-=-=-=

During an interactive rebase, the text file defining the operations
has a command option for "fixup".
This will squash the target commit into the previous commit (listed
above it in the file), and automatically use the commit message of the
previous commit (thus bypassing the "choose the commit message"
dialog/file).

Can we have a similar convenience-command that squashes, and retains
the second commit's message? Purpose is the same as the fixup command
- saving a bit of time and unnecessary typing during a common
operation.

Am happy to suggest names and/or shorthand keys for it, if the idea is
acceptable.

Yours,
Brondahl

Re: Git Feature Request (Fixdown in interactive rebase)

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]

On 2020-12-23 at 23:08:58, Mike McLean wrote:
> I initially raised this as a FR with my git UI of choice, and was told
> that it was actually something that git itself would need to do ...
> and that the standard way to raise Feature Requests was to email this
> list.

This is absolutely the right place.

> During an interactive rebase, the text file defining the operations
> has a command option for "fixup".
> This will squash the target commit into the previous commit (listed
> above it in the file), and automatically use the commit message of the
> previous commit (thus bypassing the "choose the commit message"
> dialog/file).
> 
> Can we have a similar convenience-command that squashes, and retains
> the second commit's message? Purpose is the same as the fixup command
> - saving a bit of time and unnecessary typing during a common
> operation.

Maybe I'm misunderstanding what you want, but I think the "squash"
command does what you want.  It does invoke the editor to edit it, which
tends to be useful when working on projects that use a sign-off, since
otherwise your second commit message would be tacked on after the
sign-off and other trailers.

If you really want to avoid the editor prompt, you can run your rebase
like so:

  GIT_SEQUENCE_EDITOR="$(git var GIT_EDITOR)" GIT_EDITOR=true git rebase -i

which will avoid spawning an editor except for the todo list and will
implicitly concatenate the two messages.  That will also make any
"reword" options a no-op, though.

If you were looking for an editor command that just concatenates the two
messages without an editor prompt, then no, we don't have that, and that
would be a new feature.  I wouldn't use it because most of my projects
use sign-offs, but I'll let other folks weigh in if that's a feature
they'd like to see.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: Git Feature Request (Fixdown in interactive rebase)

[Mike McLean]

I think I was unclear  :)
I mean that the new command would take *only* the 2nd commit message.
(By analogy to `fixup` which takes *only* the 1st commit message)

I agree that `squash` currently gives you the concatenation of both
commits ("all", if squashing >2 commits)

On Wed, Dec 23, 2020 at 11:25 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> On 2020-12-23 at 23:08:58, Mike McLean wrote:
> > I initially raised this as a FR with my git UI of choice, and was told
> > that it was actually something that git itself would need to do ...
> > and that the standard way to raise Feature Requests was to email this
> > list.
>
> This is absolutely the right place.
>
> > During an interactive rebase, the text file defining the operations
> > has a command option for "fixup".
> > This will squash the target commit into the previous commit (listed
> > above it in the file), and automatically use the commit message of the
> > previous commit (thus bypassing the "choose the commit message"
> > dialog/file).
> >
> > Can we have a similar convenience-command that squashes, and retains
> > the second commit's message? Purpose is the same as the fixup command
> > - saving a bit of time and unnecessary typing during a common
> > operation.
>
> Maybe I'm misunderstanding what you want, but I think the "squash"
> command does what you want.  It does invoke the editor to edit it, which
> tends to be useful when working on projects that use a sign-off, since
> otherwise your second commit message would be tacked on after the
> sign-off and other trailers.
>
> If you really want to avoid the editor prompt, you can run your rebase
> like so:
>
>   GIT_SEQUENCE_EDITOR="$(git var GIT_EDITOR)" GIT_EDITOR=true git rebase -i
>
> which will avoid spawning an editor except for the todo list and will
> implicitly concatenate the two messages.  That will also make any
> "reword" options a no-op, though.
>
> If you were looking for an editor command that just concatenates the two
> messages without an editor prompt, then no, we don't have that, and that
> would be a new feature.  I wouldn't use it because most of my projects
> use sign-offs, but I'll let other folks weigh in if that's a feature
> they'd like to see.
> --
> brian m. carlson (he/him or they/them)
> Houston, Texas, US

Re: Git Feature Request (Fixdown in interactive rebase)

[Junio C Hamano]

Mike McLean <stixmclean@googlemail.com> writes:

> Can we have a similar convenience-command that squashes, and retains
> the second commit's message? Purpose is the same as the fixup command
> - saving a bit of time and unnecessary typing during a common
> operation.

We can view "fixup" as a slight variant of "squash" that gives us
the right tree by applying the change in the second commit while
reusing the message from the first commit, and the reason why its
existence makes sense is because it often happens that users find
small mistakes in the committed content that needs "fixing up" but
the small mistakes do not change the intent of the original change
so the message does not need any "fixing up".

It also often happens that users find small mistakes in the log
message text that needs "fixing up", but there is no need to change
the committed content (iow the recorded tree object), and that is
why "reword" is a useful command to have.

You are bringing up another variant of "squash" that gives us the
right tree by applying the change in the second commit while
discarding the message from the first commit and replacing it with
the message from the second commit.  Can we justify existence of
such a mode in a similar way (like I showed above to justify why
"fixup" and "reword" make sense)?  

What is the most unclear to me is where the log message in the
second commit comes from.  Was it first copied from the first commit
and then edited?  IOW, did the user do something like this?

	$ work work work
	$ git commit -e
	... record and explain the work of the first commit
	... with sufficient detail
	$ work a bit more to fix things
	$ git commit -c HEAD
	... record and explain the work of both the first and
	... the second by copying the existing first commit's log
	... and expanding to cover what the user further did

Or did the user do something more like this, in which case the log
message of the second was written pretty much from scratch to cover
work done by both commits?

	$ work work work
	$ git commit -m snapshot
	... record but give it a meaningless and expendable log
	... message
	$ work a lot more to advance
	$ git commit -e
	... record and explain what was done on the branch as
	... a whole; the log message of this commit fully describes
	... what the both commit did

Both workflows may benefit from such a feature, but at the same
time, it is unclear how realistic they are.

If two commits did comparable amount of work with similar
complexity, it would be more realistic for them to have their own
explanation that is usable as a part of the final, squashed commit,
and that is why "squash" exists.  It just is not obvious when the
new variant would be useful.  Especially if the workflow it expects
to support is the latter kind I gave (i.e. the user delays writing
meaningful log message until the last commit in the series and then
squashes everything down to one), it smells good enough to use
"squash" and get rid of a few lines at the beginning.  So there must
be some realistic workflow that benefits from the new variant, but I
do not think of one myself.

When such an explanation is given, I may agree that such a mode is a
good thing to add, but "similar to fixup" does not look like a good
enough reason.

Thanks.

Re: Git Feature Request (Fixdown in interactive rebase)

[Mike McLean]

I agree that "realism and frequency of use case" is a critical metric :D

For me it's very much the 2nd case you described and there are 2
scenarios that it comes up in most frequently:

1) WIP commits.
For whatever reason I want to create a commit even though the work is
nowhere near ready or functional. It's not that I've done part of the
task and there's a separate extra bit pending - I'm just creating a
temporary save point.
Maybe I'm putting work down in the middle due to some external factor.
(Perhaps a colleague needed some help for something, for which jumping
over onto their branch was the most useful thing to do. Perhaps a
blocking bug was just found in our UAT that needs a 2 line fix put in
right *now*. Whatever... :D)
Or Maybe I'm part way through some work and want to attempt a
different approach but I want a "save point" if I get part way through
and decide I was right the first time.

Whatever the case, I've created a WIP commit because I don't want the
hassle of crafting a good commit message right now. When I come back
to it, I forget there was a WIP commit, and finish the work and create
a sensible commit message. When reviewing my commit history prior to
review, I notice the WIP commit and want to squash it into the final
commit.

2) Interactive rebases
I make heavy use of interactive rebases, in order to make committing
be a REALLY low effort task. If I don't have to clean up my commits
when I make them, then I can commit really easily, which means I
commit frequently, which is a good thing :D But then I have a messy
git history. Especially if I'm juggling a bunch of small fixes at
once, and I end up with bits of one fix/refactor in a commit that was
mostly about another thing.

Not a problem: Interactive rebase to the rescue!

I use `edit` mode to split stuff apart and then squash mode to push
the relevant bits back together again.
But a downside of this is that frequently I end up with the commit
with the good message being *after* the scrappy bit that's just been
split off from another commit.
Sometimes I can just pull that scrappy bit past the main commit and
then `fixup` that bit, but often that would cause merge conflicts, so
it'd be easier to have a fixdown that does exactly what I'm going to
do with `squash`.

=-=-=-=-=-=-=-=-=-=-=

I recognise that these might be very niche or non-standard usages, and
if you don't think there would be much demand for such functionality
then I'm fine with that :D
Just figured I'd throw it in and see whether there was an appetite.

On Wed, Dec 23, 2020 at 11:57 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Mike McLean <stixmclean@googlemail.com> writes:
>
> > Can we have a similar convenience-command that squashes, and retains
> > the second commit's message? Purpose is the same as the fixup command
> > - saving a bit of time and unnecessary typing during a common
> > operation.
>
> We can view "fixup" as a slight variant of "squash" that gives us
> the right tree by applying the change in the second commit while
> reusing the message from the first commit, and the reason why its
> existence makes sense is because it often happens that users find
> small mistakes in the committed content that needs "fixing up" but
> the small mistakes do not change the intent of the original change
> so the message does not need any "fixing up".
>
> It also often happens that users find small mistakes in the log
> message text that needs "fixing up", but there is no need to change
> the committed content (iow the recorded tree object), and that is
> why "reword" is a useful command to have.
>
> You are bringing up another variant of "squash" that gives us the
> right tree by applying the change in the second commit while
> discarding the message from the first commit and replacing it with
> the message from the second commit.  Can we justify existence of
> such a mode in a similar way (like I showed above to justify why
> "fixup" and "reword" make sense)?
>
> What is the most unclear to me is where the log message in the
> second commit comes from.  Was it first copied from the first commit
> and then edited?  IOW, did the user do something like this?
>
>         $ work work work
>         $ git commit -e
>         ... record and explain the work of the first commit
>         ... with sufficient detail
>         $ work a bit more to fix things
>         $ git commit -c HEAD
>         ... record and explain the work of both the first and
>         ... the second by copying the existing first commit's log
>         ... and expanding to cover what the user further did
>
> Or did the user do something more like this, in which case the log
> message of the second was written pretty much from scratch to cover
> work done by both commits?
>
>         $ work work work
>         $ git commit -m snapshot
>         ... record but give it a meaningless and expendable log
>         ... message
>         $ work a lot more to advance
>         $ git commit -e
>         ... record and explain what was done on the branch as
>         ... a whole; the log message of this commit fully describes
>         ... what the both commit did
>
> Both workflows may benefit from such a feature, but at the same
> time, it is unclear how realistic they are.
>
> If two commits did comparable amount of work with similar
> complexity, it would be more realistic for them to have their own
> explanation that is usable as a part of the final, squashed commit,
> and that is why "squash" exists.  It just is not obvious when the
> new variant would be useful.  Especially if the workflow it expects
> to support is the latter kind I gave (i.e. the user delays writing
> meaningful log message until the last commit in the series and then
> squashes everything down to one), it smells good enough to use
> "squash" and get rid of a few lines at the beginning.  So there must
> be some realistic workflow that benefits from the new variant, but I
> do not think of one myself.
>
> When such an explanation is given, I may agree that such a mode is a
> good thing to add, but "similar to fixup" does not look like a good
> enough reason.
>
> Thanks.

Re: Git Feature Request (Fixdown in interactive rebase)

[Johannes Sixt]

Am 24.12.20 um 01:13 schrieb Mike McLean:
> I agree that "realism and frequency of use case" is a critical metric :D
> 
> For me it's very much the 2nd case you described and there are 2
> scenarios that it comes up in most frequently:
> 
> [...]
> 2) Interactive rebases
> I make heavy use of interactive rebases, in order to make committing
> be a REALLY low effort task. If I don't have to clean up my commits
> when I make them, then I can commit really easily, which means I
> commit frequently, which is a good thing :D But then I have a messy
> git history. Especially if I'm juggling a bunch of small fixes at
> once, and I end up with bits of one fix/refactor in a commit that was
> mostly about another thing.
> 
> Not a problem: Interactive rebase to the rescue!
> 
> I use `edit` mode to split stuff apart and then squash mode to push
> the relevant bits back together again.
> But a downside of this is that frequently I end up with the commit
> with the good message being *after* the scrappy bit that's just been
> split off from another commit.
> Sometimes I can just pull that scrappy bit past the main commit and
> then `fixup` that bit, but often that would cause merge conflicts, so
> it'd be easier to have a fixdown that does exactly what I'm going to
> do with `squash`.
> 
> =-=-=-=-=-=-=-=-=-=-=
> 
> I recognise that these might be very niche or non-standard usages, and
> if you don't think there would be much demand for such functionality
> then I'm fine with that :D

I would not say that your workflow is exceptional; quite the contrary: I
do exactly like you explained. And I guess that many others do as well
(interactive rebase was invented for uses cases like yours).

I don't mind using 'squash' to consolidate commits where the meat of the
change and the commit message is not in the first one.

But consider a situation like this, which I find myself in regularly:

    $ work
    $ git commit -m "WIP begin feature"
    $ work -- ah, this can be done independently:
    $ git commit -m "refactor stuff"
    $ do the real feature (takes time, many commits)
    # finally:
    $ git commit -m "the real feature"

Here I wish that the final commit carries an author date that should be
after the "refactor" commit to be realistic. But 'squash' takes
authorship including the date from the first commit (the "WIP" commit in
this example). That is where the suggested feature could help. I admit,
though, that it's not a huge deal.

-- Hannes

Re: Git Feature Request (Fixdown in interactive rebase)

[Junio C Hamano]

Johannes Sixt <j6t@kdbg.org> writes:

> But consider a situation like this, which I find myself in regularly:
>
>     $ work
>     $ git commit -m "WIP begin feature"
>     $ work -- ah, this can be done independently:
>     $ git commit -m "refactor stuff"
>     $ do the real feature (takes time, many commits)
>     # finally:
>     $ git commit -m "the real feature"
>
> Here I wish that the final commit carries an author date that should be
> after the "refactor" commit to be realistic. But 'squash' takes
> authorship including the date from the first commit (the "WIP" commit in
> this example). That is where the suggested feature could help. I admit,
> though, that it's not a huge deal.

Yeah, I actually find that an interesting scenario.

In such a workflow, you'd want to view all the previous steps
building pieces as preparing for the final step that makes the
cumulative effort into presentable whole.  Whether you want to use
the log message only from the last step or want to use the "squash"
to collect pieces from all the WIP commits, you would want the other
aspects of the resulting single commit to be more similar to the
final one rather than the earlier one(s), as if you did something
like "commit --reset-author --amend" (yes, I am including the case
where the work on the branch was a team effort and the one that
collects them into a single resulting commit would become the
"corresponding author").

I wonder if we deliberately designed how each insn you can write in
the todo list should come up with the authorship data (i.e. ident
and timestamp), or if we are just using the natural consequence of
how the implementation happens to work?  I think it makes sense for
"fixup", as an instruction used to make a small tweak to the bulk of
work you've done some time ago, to use the authorship information of
the original commit that gets fixed up. I don't know offhand what
other insns like "edit", "reword", etc. do, and if there is a room
to improve them.

Re: Git Feature Request (Fixdown in interactive rebase)

[Johannes Sixt]

Am 24.12.20 um 23:21 schrieb Junio C Hamano:
> I wonder if we deliberately designed how each insn you can write in
> the todo list should come up with the authorship data (i.e. ident
> and timestamp), or if we are just using the natural consequence of
> how the implementation happens to work?  I think it makes sense for
> "fixup", as an instruction used to make a small tweak to the bulk of
> work you've done some time ago, to use the authorship information of
> the original commit that gets fixed up. I don't know offhand what
> other insns like "edit", "reword", etc. do, and if there is a room
> to improve them.

For 'squash' it was a deliberate decision to keep authorship of the
first commit, see 81ab1cb43a87. Initially, 'edit' changed authorship
including the date to the current author and date; that was changed to
preserve them, but I cannot find the responsible commit.

-- Hannes

Re: Git Feature Request (Fixdown in interactive rebase)

[Johannes Schindelin]

Hi,

On Thu, 24 Dec 2020, Johannes Sixt wrote:

> Am 24.12.20 um 23:21 schrieb Junio C Hamano:
> > I wonder if we deliberately designed how each insn you can write in
> > the todo list should come up with the authorship data (i.e. ident
> > and timestamp), or if we are just using the natural consequence of
> > how the implementation happens to work?  I think it makes sense for
> > "fixup", as an instruction used to make a small tweak to the bulk of
> > work you've done some time ago, to use the authorship information of
> > the original commit that gets fixed up. I don't know offhand what
> > other insns like "edit", "reword", etc. do, and if there is a room
> > to improve them.
>
> For 'squash' it was a deliberate decision to keep authorship of the
> first commit, see 81ab1cb43a87. Initially, 'edit' changed authorship
> including the date to the current author and date; that was changed to
> preserve them, but I cannot find the responsible commit.

Note that a new verb is not even necessary, thanks to the `exec` verb:
Something like this:

	pick <moved-here>
	squash <use-this-commits-message>
	exec git commit --amend -C <use-this-commits-message>

As to the implementation of a hypothetical `fixdown`? It would be a bit
hairy, I think: right now, we rely on the fact that we can find the target
of every fixup!/squash! in the already-parsed todo list. If we do not find
it there, the fixup!/squash! simply won't be auto-squashed. The desired
feature, however, would have to look in the opposite direction. I'd rather
avoid that complexity.

Ciao,
Johannes

Re: Git Feature Request (Fixdown in interactive rebase)

[Charvi Mendiratta]

Hi,

On Thu, 24 Dec 2020 at 04:42, Mike McLean <stixmclean@googlemail.com> wrote:
[...]
> =-=-=-=-=-=-=-=
>
> During an interactive rebase, the text file defining the operations
> has a command option for "fixup".
> This will squash the target commit into the previous commit (listed
> above it in the file), and automatically use the commit message of the
> previous commit (thus bypassing the "choose the commit message"
> dialog/file).
>
> Can we have a similar convenience-command that squashes, and retains
> the second commit's message? Purpose is the same as the fixup command
> - saving a bit of time and unnecessary typing during a common
> operation.
>

It seems that this FR is addressed by the patches as here[1], which are
under review. It adds the options to fixup command i.e fixup [-C|-c] in the
interactive rebase that gives the flexibility to select or edit the
commit message
while fixing up the commit using fixup command. So, changing `pick` command
to `fixup -C` will fixup the content and replace the previous commit
message with
the second commit message(ie. the fixup commit message).

Thanks and Regards,
Charvi

[1] https://lore.kernel.org/git/20210124170405.30583-1-charvi077@gmail.com/