Re: git commit --amend safety check?

[Junio C Hamano <gitster@pobox.com>]

Shawn Pearce <spearce@spearce.org> writes:

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