Re: Keep original author with git merge --squash?

Jeff King [off-list ref] writes:

What happens if there is no "Author:" line in the output?

I've been assuming that we would do what the current code does.
"git commit --amend" for example internally remembers who the
original author was and uses that, without paying any attention to
the result from the editor.  If there is no "Author:", that would
not change.

And I do not think we need to be able to say "Oops, I forgot to pass
the --reset-author option from the command line", personally, so...

So probably a saner thing is that a missing "Author:" line does nothing,

yes and

and using "Author: " (with no text) does a reset.

no (I do not think it is wrong per-se, but I do not think such a
good idea).

Also, on the topic of "merge --squash". I never use it myself, but
having experimented with it due to this thread, I found the template it
sticks into COMMIT_EDITMSG to be horribly unfriendly for munging. For
example, with two simple commits, I get:

    Squashed commit of the following:
    
    commit 6821a8ac920ed00675e4aec10dcef705211105cd
    Author: Jeff King [off-list ref]
    Date:   Thu Feb 12 17:39:28 2015 -0500
    
        commit subject 2
    
        commit body 2
    
    commit b0840bb4bbfe00b6ed8c7c4d483f11d126fa2d69
    Author: Jeff King [off-list ref]
    Date:   Thu Feb 12 17:39:28 2015 -0500
    
        commit subject 1
    
        commit body 1

I guess that is helpful if you want to keep a complete log of what got
squashed, but I doubt that is the common case (if you did, then doing a
real merge would probably be in order).

I think it should show exactly the same thing as "rebase -i" squash
insn would give you.  People already know how to munge that, right?

It also raises a question for the proposal in this thread: if there are
multiple "Author:" lines, which one do we take? The first, or the last?

I was siding with David's "pay attention to in-buffer Author: only
when all of them agree".  When squash-merging a branch with two or
more authors, we would attribute the authorship silently and
automatically to you if you do not do anything special otherwise.

Possible alternatives when multiple "Author:"s do not agree are:

 - use you who is playing the integrator;

 - use the tip;

 - use the one that most often appears; or

 - error out and ask the user to leave only one (or zero--if you
   want to take the authorship) by re-attempting "git commit".

On Thu, Feb 12, 2015 at 03:32:37PM -0800, Junio C Hamano wrote:

quoted

and using "Author: " (with no text) does a reset.

no (I do not think it is wrong per-se, but I do not think such a
good idea).

Fair enough. It is probably a minority use case, and one that is likely
to cause confusion.

quoted

Also, on the topic of "merge --squash". I never use it myself, but
having experimented with it due to this thread, I found the template it
sticks into COMMIT_EDITMSG to be horribly unfriendly for munging. For
example, with two simple commits, I get:

[...]
I think it should show exactly the same thing as "rebase -i" squash
insn would give you.  People already know how to munge that, right?

Yeah, that was exactly what I expected to see (but didn't). They should
probably have the same format, though we may want to enhance both to
contain more information (like author names).

quoted

It also raises a question for the proposal in this thread: if there are
multiple "Author:" lines, which one do we take? The first, or the last?

I was siding with David's "pay attention to in-buffer Author: only
when all of them agree".  When squash-merging a branch with two or
more authors, we would attribute the authorship silently and
automatically to you if you do not do anything special otherwise.

That's probably reasonable. I was thinking more of a case where you made
some fixups on top of somebody else's branch, and then used "git rebase
-i" to squash them together. But I think we already use the authorship
for the root of the squash in that case.

This case collapses nicely if we make a slight tweak to your proposed
behavior (or maybe this is what you meant). If there are multiple
authors listed, we behave as if none was listed. That would leave the
authorship as it behaves today (with the author of the first commit) if
you do nothing, or you can override it by dropping all but one.

-Peff