From: Junio C Hamano Date: Thu, 24 Jan 2013 17:19:30 GMT Subject: Re: [PATCH v4 3/3] push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE Message-ID: <7vvcamcxct.fsf@alter.siamese.dyndns.org> In-Reply-To: <20130124065842.GC610@sigill.intra.peff.net> Jeff King writes: > 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.