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
