Re: git commit --amend safety check?

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 11, 2015, 05:11 UTC
Message-ID: <xmqq8uf46ru8.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAJo=hJuwdOzNZSVBRAPDz97Gdoi6JWvYxE0ufY+Hd9K8jjCqfA@mail.gmail.com>

Shawn Pearce <spearce@spearce.org> writes:

Show 16 quoted lines

> We keep seeing reports of Gerrit Code Review users who incorrectly do
> something like:
>
>   git clone URL foo
>   cd foo
>   git commit --amend -m "My first change!" -a
>   git push URL HEAD:refs/for/master
>
> Step #3 is where they get into trouble. They just amended the
> published tip commit and pushed it back to the server. That is... lets
> just say not good.
>
> Hg is known to be more user friendly. One way its user friendly is it
> by default refuses to let you amend a change set that the client has
> reasonable assertion to believe was already published through a remote
> repository.

Well, it is not Git that is less user friendly, but Gerrit is the problem. More specifically, the last line:

>   git push URL HEAD:refs/for/master

is what catches this non-fast-forward in usual workflow with Git. Wouldn't the real problem that the refs/for/master magic accepts anything, even a non-fast-forward?

Having said that, disabling --amend and forcing to use --force or something when it is clear that the user is attempting something unusual is a good idea. But I am not sure what the definition of unusual should be. In a non-Gerrit central repository workflow, the rule might be "HEAD must not be reachable from @{upstream}" (otherwise you are rewriting what you got from elsewhere), or it may be "HEAD must not be reachable from @{publish}'s remote tracking branch", or perhaps both, as these two could be different in triangular workflow.

But I am not sure what the sensible rules are when the user prepares the commit, planning to push it to a ref like refs/for/master that does not have a counterpart on our side.