Re: Re* [PATCH] "not uptodate" changed to "has local changes"

From: Sverre Rabbelier <alturin@gmail.com>
Date: May 17, 2008, 20:29 UTC
Message-ID: <bd6139dc0805171329i29b518a2l7b28e7e71756adac@mail.gmail.com>
In-Reply-To: <7v63tcda7e.fsf_-_@gitster.siamese.dyndns.org>

On Sat, May 17, 2008 at 9:03 PM, Junio C Hamano <gitster@pobox.com> wrote:

> Don't feed the troll by responding to a cheap shot.

Yes, a cheap shot, but I think one trying to make a point.

Show 6 quoted lines

> The plumbing output is sacred as it is an API.  We _could_ change it if it
> is broken in such a way that it cannot convey necessary information fully,
> but we just do not _reword_ for the sake of rewording.  If somebody does
> not like it, s/he is complaining too late.  S/he should have been here in
> early May 2005 and make the language used by the API closer to what humans
> read.  S/he wasn't here.  Too bad, and it is too late.

Mhh.. I guess I didn't realize how strongly git still is "many commands that are good at what they do" that together form a coherent entity.

> If you do not see something wrong with this output, your brain has already
> been rotten with use of git for too long a time.  Nobody asked us to
> "merge" but why are we talking about "Cannot merge"?

Very good point, perhaps we should consider double-checking them all and improving them for one of the next 1.x releases.

Show 9 quoted lines

> Try a different approach along this patch instead.
>
>    $ git-checkout pu
>    error: You have local changes to 'Makefile'; cannot switch branches.
>
> There are other places that ask unpack_trees() to n-way merge, detect
> issues _and_ let it issue error message on its own, which people who
> complained in this thread can identify and improve, but I did this as a
> demonstration and replaced only one message.

The patch looks like a step in the right direction, but if there is interest in improving the error messaging system why not do it right and make it generic. Instead of each file reinventing the wheel create a more generic system that uses a configuration file (I think this was suggested earlier). If we choose something like that, perhaps it would be nice to add a 'scripting' mode, which provides with a CLI-like messages instead of the usual human-readable ones (and thus less easy to parse).

<snip patch>

-- 
Cheers,

Sverre Rabbelier