Amending commit messages non-destructively?

[Joshua J. Kugler]

I had a user ask:

"We were wondering if it is possible to configure (or modify?) Gerrit to allow
pushing patches with amended commit comments (i.e. from "git commit --amend"
that only modifies the commit comments) that does not clear the inspection and
build/test flags on the change? This would allow developers to improve their
commit comments without the extra effort of testing."

In reading the docs and poking around in the config, I don't think this is
currently possible. is this feasible? Is it on a road map? Is these even
desired, as I seem to recall that git best practice was not modifying the
commit message after pushing.

Any comments welcome.

Thanks!

j

--
Joshua J. Kugler - Fairbanks, Alaska
Azariah Enterprises - Programming and Website Design
jos...@azariah.com - Jabber: peda...@gmail.com
PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A

[Conley Owens]

A commit message is part of a change. It may warrant approval. I
think it should be up to the build tools you are using to decide
whether or not to carry forward approvals without retesting.

~cco3

> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en

[Joshua J. Kugler]

I would tend to agree with you.

The behavior they were interested in was not clearing the inspection flags,
which means it hasn't even gotten to the build/test stage yet.

j

[Conley Owens]

Is "inspection" your own custom label (like code-review, verified)?
You can create a hook that will carry forward that label when a new
patchset is added.

http://gerrit-documentation.googlecode.com/svn/Documentation/2.4.2/config-hooks.html

[Martin Fick]

On Thursday, October 04, 2012 05:34:42 pm Conley Owens
wrote:

> Is "inspection" your own custom label (like code-review,
> verified)? You can create a hook that will carry forward
> that label when a new patchset is added.
>
> http://gerrit-documentation.googlecode.com/svn/Documentat
> ion/2.4.2/config-hooks.html
>
> On Thu, Oct 4, 2012 at 4:31 PM, Joshua J. Kugler
<jos...@azariah.com> wrote:
> > I would tend to agree with you.
> >
> > The behavior they were interested in was not clearing
> > the inspection flags, which means it hasn't even
> > gotten to the build/test stage yet.
> >
> > j

The trivial rebase hook might be what you want, look in
contrib.

-Martin


--
The Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation

[Luciano Carvalho]

We use the trivial-rebase hook for that. It works beautifully.

[Pursehouse, David]

> I seem to recall that git best practice was not modifying the commit message after pushing

In pure git context this probably means pushing into the repository; i.e. a forced push in Gerrit terms. In that case, no, the commit message should not be modified afterwards because it would be "rewriting history". See [1] about the problems that can cause.

However when working with Gerrit, it's quite common to push a change for review and then, before the change is submitted, push new patch sets in which the commit message is changed.

[1] http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#problems-With-rewriting-history