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

From: David Glasser <glasser@davidglasser.net>
Date: Feb 12, 2015, 22:16 UTC
Message-ID: <CAN7QDoJ+hOFqoc54sAbLeSxvj8TQKQRSVKbNQXZYfPv1uOy=WA@mail.gmail.com>
In-Reply-To: <xmqq8ug2rfi2.fsf@gitster.dls.corp.google.com>

On Thu, Feb 12, 2015 at 1:23 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 17 quoted lines

> David Glasser <glasser@davidglasser.net> writes:
>
>> Well, using -c appears to override SQUASH_MSG entirely; it replaces
>> the message as well as the author.  Often I do want to make my own
>> message based on all the messages provided by the submitter.  (And
>> typically the branch's tip is the least useful message anyway: it's
>> usually something like "respond to code review".)
>
> I wonder if there is a bug in the workflow.  Isn't the contributor
> forcing more work to the integrator that way and making it a
> responsibility of the integrator to squash multiple commits into
> one, instead of asking a cleaned-up branch to be merged in the first
> place?  It is a key to keep your project scalable to push as much
> work out of the integrator's plate to the contributors' plates.
>
> But that is an unrelated tangent.  Among the ideas floated in the
> thread, I tend to like something like what Peff mentioned earlier.

Yes, I agree that the GitHub pull request workflow has some major disadvantages. It does a good job of enabling unsophisticated contributors who aren't git experts to propose changes to a codebase, but not a very good job of encouraging them to do the work of massaging what may be a series of changes as the patch undergoes code review into a single patch (or well-structured series of patches). At this point in time, the tradeoff of requiring a little more integrator work makes sense for my project. I'd rather spend my limited "educate potential contributors" energy on ensuring that they include actual reproductions with their bug reports than on getting them to do administrative git work that isn't hard for me.

So to be concrete: What I'm proposing (and I'm excited to implement it!) is the following:

When running "git commit" and:
- You've fallen into the case where the message was read from SQUASH_MSG
- You haven't used another method of specifying the author (--author,
  -C, -c, --amend)
- You have not specified --reset-author
- You have set the "commit.useSquashAuthor" option
- Before invoking prepare-commit-msg, all of the `Author:` lines found
  in SQUASH_MSG have the same value

then that author is used, as if it were specified with --author. (And this will show up, commented-out, at the bottom of COMMIT_EDITMSG.)

If you have the config option set but you don't want this logic to take place for a particular post-squash merge, just specify --reset-author.

I think this makes git more internally consistent, since it makes `merge --squash` act more like the squash rebase action. (Personally I'd be happy if this behavior was the default, but since it is not backwards-compatible I've included a config option in my proposal.)

(It is my understanding, based on reading the code, that the format of SQUASH_MSG is not user-configurable, and that scanning for Author: lines in it is straightforward.)

--dave

-- 
glasser@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/