Re: [PATCH v2 2/3] push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE

From: Jeff King <peff@peff.net>
Date: Jan 23, 2013, 06:56 UTC
Message-ID: <20130123065640.GB10306@sigill.intra.peff.net>
In-Reply-To: <1358836230-9197-3-git-send-email-gitster@pobox.com>

On Mon, Jan 21, 2013 at 10:30:29PM -0800, Junio C Hamano wrote:

Show 11 quoted lines

> When we push to update an existing ref, if:
> 
>  * we do not have the object at the tip of the remote; or
>  * the object at the tip of the remote is not a commit; or
>  * the object we are pushing is not a commit,
> 
> there is no point suggesting to fetch, integrate and push again.
> 
> If we do not have the current object at the tip of the remote, we
> should tell the user to fetch first and evaluate the situation
> before deciding what to do next.

Should we? I know that it is more correct to do so, because we do not even know for sure that the remote object is a commit, and fetching _might_ lead to us saying "hey, this is not something that can be fast-forwarded".

But by far the common case will be that it _is_ a commit, and the right thing is going to be to pull. Adding in the extra steps makes the workflow longer and more complicated, and most of the time doesn't matter. For example, imagine that Alice is working on "master", and when she goes to push, she finds that Bob has already pushed his work. With the current code, she sees:

  $ git push
  To ...
   ! [rejected]        HEAD -> master (non-fast-forward)
  error: failed to push some refs to '...'
  hint: Updates were rejected because the tip of your current branch is behind
  hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
  hint: before pushing again.

and she presumably pulls, and all is well with the follow-up push.

With your patch, she sees:

  $ git push
  To ...
   ! [rejected]        HEAD -> master (fetch first)
  error: failed to push some refs to '...'
  hint: Updates were rejected; you need to fetch the destination reference
  hint: to decide what to do.

  $ git fetch
  ...

  $ git push
  To ...
   ! [rejected]        HEAD -> master (non-fast-forward)
  error: failed to push some refs to '...'
  hint: Updates were rejected because the tip of your current branch is behind
  hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
  hint: before pushing again.
  hint: See the 'Note about fast-forwards' in 'git push --help' for details.

which is technically more correct (it's possible that in the second step, she would find that Bob pushed a tree or something). But in the common case that it is a commit, we've needlessly added two extra steps (a fetch and another failed push), both of which involve network access (so they are slow, and may involve Alice having to type her credentials).

Is the extra hassle in the common case worth it for the off chance that we might give a more accurate message? Should the "fetch first" message be some hybrid that covers both cases accurately, but still points the user towards "git pull" (which will fail anyway if the remote ref is not a commit)?

-Peff