On Thu, 2012-05-03 at 22:25 -0700, Junio C Hamano wrote:
> Michael Witten <mfwitten@xxxxxxxxx> writes:
>
> > As for a seemingly conservative suggestion, how about using a little
> > more structural white space:
> >
> > To $uri_for_central_repo
> > ! [rejected] HEAD -> feature_0 (non-fast-forward)
> >
> > error: failed to push some refs to '$uri_for_central_repo'
> >
> > To prevent you from losing history, non-fast-forward updates were rejected
> > Merge the remote changes (e.g. 'git pull') before pushing again. See the
> > 'Note about fast-forwards' section of 'git push --help' for details.
> >
> > Alas! Error output like this is constructed in the code in a way that
> > potentially makes adding such white space non-trivial.
> >
> > Perhaps the error message system needs an overhall; rather than spitting
> > out error messages from anywhere, they ought to be corralled and collated
> > by a dedicated subsystem.
>
> Didn't somebody recently rework these messages quite extensively?
If you're thinking of me, I only changed the pull/rebase side, which was
a ridiculously bad message. As this subthread looks like it might
actually have something actionable, let me look at this message with the
same critical eyes.
Most of the first sentence repeats what we can see above. Restating that
non-ff updates were rejected doesn't add information and doesn't help
people who don't already know what a non-ff update is, so it's either
redundant or not helpful[0]. So lets see if we can come up with a
friendlier way of saying it. Maybe something like:
To $uri_for_central_repo
! [rejected] HEAD -> feature_0 (non-fast-forward)
error: failed to push some refs to '$uri_for_central_repo'
Some updates which might rewrite history and lose someone else's
changes were rejected. Merge those changes (e.g. 'git pull') to
incorporate that history. See the 'Note about fast-forwards' section
of 'git push --help' for details.
It may be a bit longer, but if you don't know what a non-ff is or why
it's a problem, this text should help you a lot more than the previous
one did. Not reading the documentation (specially when the error message
points you to a specific section for a longer explanation) is still no
excuse for not known what's going on, but if you've been working on your
own for a while, you might have forgotten what this is all about.[1]
If people don't have it, I'll try to find time to create a patch.
cmn
[0] Or worse, as repeating jargon can leave the user thinking that they
don't understand anything and reduces the chanced they'd try to figure
out the missing parts. I'd qualify this with friendliness rather than
anything else, as the message isn't wrong or misleading, just rather
on-your-face.
[1] At least this is show I rationalise why doing saying "non-ff updates
rejected. Read the ff section of the push manpage for an explanation"
isn't the right thing to do.
Attachment:
signature.asc
Description: This is a digitally signed message part