Shawn Pearce <spearce@xxxxxxxxxxx> 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.
--
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