On Tue, Aug 11, 2009 at 12:03:13PM +0900, Nanako Shiraishi wrote:
> error("failed to push some refs to '%s'", url[i]);
> + if (nonfastforward) {
> + printf("To prevent you from losing history, non-fast-forward updates were rejected.\n"
> + "Merge the remote changes before pushing again.\n"
> + "See 'non-fast forward' section of 'git push --help' for details.\n");
> + }
I saw this message in regular use for the first time today, and I
thought it was terribly ugly. The sheer number of lines, coupled with
the extremely ragged right edge made it much harder to pick out the
nicely formatted status table. And of course the information in the
message was totally worthless to me, as an experienced git user.
So rather than re-open the debate on whether this message should exist
or not, here is a patch series which tries to address the issue:
[1/4]: push: fix english in non-fast-forward message
Hopefully non-controversial.
[2/4]: push: re-flow non-fast-forward message
This makes it prettier, IMHO. I suspect the message was flowed as
it was originally on purpose so that each sentence began on its own
line. I think making it easier on the eyes is more important,
though.
[3/4]: push: make non-fast-forward help message configurable
I feel like we have had this exact sort of tension before: we want
one thing to help new users and experienced users want another
thing. We have resisted an "expert user" config variable in the past
because proposals usually involved a change of behavior, which could
lead to quite confusing results. However, I think the case of
"helpful messages" is much simpler. The message is meant purely for
human consumption and is redundant with information already given,
so an expert sitting at a novice's terminal (or vice versa) will not
encounter any surprises.
This actually introduces infrastructure for other, similar messages,
so that we can make existing ones optional, or build new ones as
appropriate.
[4/4]: status: make "how to stage" messages optional
This uses the infrastructure in 3/4 to lose the "use git add to add
untracked files" advice.
I think (1) and (2) are pretty straightforward. (3) and (4) are more
questionable, and I am undecided whether I am over-reacting to being
annoyed by the message. I do know this is not the first time I have had
the urge to write such a patch, so maybe others feel the same.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html