From: Junio C Hamano Date: Wed, 11 Mar 2015 05:11:43 GMT Subject: Re: git commit --amend safety check? Message-ID: In-Reply-To: Shawn Pearce 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.