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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 24, 2013, 17:19 UTC
Message-ID: <7vvcamcxct.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130124065842.GC610@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 10 quoted lines

> I wonder if we can reword it to explain more about why we do not have
> the object, without getting too inaccurate. Something like:
>
>   Updates were rejected because the remote contains objects that you do
>   not have locally. This is usually caused by another repository pushing
>   to the same ref. You may want to first merge the remote changes (e.g.,
>   'git pull') before pushing again.
>
> I was also tempted to s/objects/work/, which is more vague, but is less
> jargon-y for new users who do not know how git works.

After all this is "hint", and there is a value in being more approachable at the cost of being less accurate, over being impenetrable to achieve perfect correctness.

> Also, how should this interact with the checkout-then-pull-then-push
> advice? We make a distinction for the non-fastforward case between HEAD
> and other refs. Should we be making the same distinction here?

Possibly, but I am not among the people who cared most about the distinction there; with the default behaviour switching to 'simple', that distinction will start mattering even less, I suspect.