Jeff King <p...@peff.net> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html