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

> > 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.

> > 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).

> > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to