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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Glasser <glasser@xxxxxxxxxxxxxxxx> 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.

> I assume you are already munging in your editor the template provided by
> "git commit" after the squash? What would be really nice, IMHO, is if
> there was a way to set the author during that edit (e.g., by moving one
> of the "Author:" lines to the top of the file). That would cover your
> use case, I think, and would also be useful in general.

I don't know if the exact solution Peff mentioned is good [*1*], but
being able to do an equivalent of setting --author="<author>" and
"--date=<date>" from the command line inside the log message editor
would be a huge win.


[Footnote]

*1* You would see

	gostak: do not distim doshes unconditionally

	Usually it is a good idea to let gostak distim doshes,
        but it should cause the program segfault when there is
        no doshes to be distimmed.  Detect this case and error
        out.

	Signed-off-by: David Glasser <glasser@xxxxxxxxxxxxxxxx>

        # Please enter the commit message ...
        #
        # Author:    David Glasser <glasser@xxxxxxxxxxxxxxxx>
        # Date:      Thu, 12 Feb 2015 04:28:24 -0500
        # ...

when you start "git commit --amend" or "git merge --squash", and the
proposal, as I understand it, is to allow you to do this:

        From: David Glasser <glasser@xxxxxxxxxxxxxxxx>
        Date: Thu, 12 Feb 2015 04:28:24 -0500

	gostak: do not distim doshes unconditionally

	Usually it is a good idea to let gostak distim doshes,
        but it should cause the program segfault when there is
        no doshes to be distimmed.  Detect this case and error
        out.

	Signed-off-by: David Glasser <glasser@xxxxxxxxxxxxxxxx>

        # Please enter the commit message ...
        #
        # ...

which is the same format of the _body_ of the message "git am" would
take.  The reason I am not so sure about such a change is that
having to move and edit things would be error prone.  Some may
forget to do s/Author:/From:/ and we would end up having to support
both.  Some existing commit may validly have lines that begin with
these tokens ("git am" does not have such a problem because it is
not the underlying "git commit" or "git commit-tree" that interprets
these in-body headers).  Some users may forget to leave a blank line
between the in-body headers and the subject line.

I suspect that it _might_ work better if we always look for the pair
of "# Author: " and "# Date:" lines (taking the commentchar setting
in to account, of course) immediately at the beginning of the
trailing comment block, and if exists, use that to override the
authorship identity.  If the user does not do anything when running
"git commit --amend", the resulting commit will get the original
authorship.  If the user strips all the lines in the trailing
comment block, we would do the same thing as we have always done and
retain the original authorship.

I dunno.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]