Re: [RFC/PATCH] revision.c: add --format option for 'git log'

[Felipe Contreras <felipe.contreras@gmail.com>]

On Tue, Feb 24, 2009 at 10:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Quoting Junio C Hamano <gitster@pobox.com>:
>>
>>>>>> People already are used to finding the shed in the scenery by looking for
>>>>>> that original color, however ugly the color might be.  The answer to your
>>>>>> question has to become quite different when you take that into account;
>>>>>> otherwise you are being irresponsible to your users.
>>>>
>>>> People somehow got used to the ugly color, they'll get used to the
>>>> pretty one, in fact, they would probably like it better,...
>>>
>>> You do not have to send two messages in a row to reaffirm that you are of
>>> irresponsible kind.  I heard you enough already.
>>>
>>> Go away.
>>
>> Junio, what got into you?
>>
>> I've always admired your calm and reasoned way to deal with even the
>> most obnoxious people, and unlike more abrasive people on this list I've
>> never seen you say "Go away" to anybody here.
>>
>> Especially because I agree with you that calling pretty-printing as
>> "pretty" isn't so broken to make such a big deal out of, it would be
>> better not to chase a potentially useful contributor away on such a
>> minor issue.
>
> I may try to be more diplomatic than other people, but it does not mean I
> do not reserve the right to get annoyed enough from time to time.
>
> When you hear people complain, and you take a poll and see there are many
> people who agree with you, a naive thing to do is to assume that you now
> got the majority vote.  Over time, you will learn that majority were
> happy, were not complaining, and they merely did not bother to object to
> the complainers who want to change things.  And the last thing you want is
> to find these things out the hard way by bringing a sudden change to them
> and giving them something to compalin about, like we did with 1.6.0.  You
> need to learn to take "let's improve this thing, as many people want it"
> with a huge grain of salt.
>
> This cannot be stressed enough; if somebody is incapable of understanding
> it, then we would be better off without him or her.

I've discussed with many people regarding git; git-haters, people that
don't care about vcs, new git users, etc. So you might say that I have
an 'outsider' point of view, that shouldn't necessarily be a bad
thing.

The 'problems' about git that I've heard is that #1 lack of win32
support (now fixed), #2 complicated user interface (fixable), #3 lack
of storing renames (yes, people do complain about that). I don't
really care about #3, but I do care about #2.

Now, a google for 'git user interface' returns a few interesting
results, and one of them is Jon Loeliger asking for more grained
detail about the areas of improvement in the Git Survey, but somehow
nobody listened and now we don't have any nice graph about people
wanting UI improvements:
http://marc.info/?l=git&m=121691093706811&w=2

However, we do have comments in the survey about how to improve git:
 * #1 documentation #2 interface:  a. having tons of git-* binaries in
/usr/bin confuses tab-completion in the shell  b. the whole index
concept is a major pain point, i'm constantly trying to get around
having to deal with it
 * 1) CLI interface 2) More consistent terminology 3) Better
documentation with examples and use cases
 * a more intuitive command line interface
 * Better consistency of the interface. Documentation intended for
users, rather than being addressed to people who already understand
what a reflog is.
 * Better docs, better official interface
 * better docs, better usage hints, more consistent terminology/interface
 * Better user interface (on command line). More safety against user errors.
 * bzr like plugin ability, consistent interface with all commands as
well as consistent naming of commands.
 * cleaner interface, of course the docs could be better in places.
Better responsiveness: my buddy submitted a patch to add a "git svn
diff" command and received no response from the mailing list, either
positive or negative.
 * Cleaner, more consistent, easier to learn user interface.  Man
pages should be more user-oriented than developer-oriented.  Sparse
checkout can't come soon enough.
 * Cleanup the interface, not so many commands that do the same thing
or almost the same thing.
 * CLI user interface.  git-svn corrupts history if svn repository was
created according to instructions in the svn manual:
https://bugs.launchpad.net/ubuntu/+source/git-core/+bug/163341
Windows support is better than last year, but still causes problems
(especially with ssh keys and line-endings). We can't move to git from
svn until the Windows users are happy too.
...

And the list goes on and on.

One of the lessons learned from the switch from 'git-foo' is that the
change should have been more visible to users, a big annoying 'this is
deprecated' warning would have been more than enough, because that
will force users to shout if they don't like it or accept the
resolution once it's finally deprecated. Since can't possibly miss the
warning they would have no excuse to shout after the obsolescence.

I understand the "you can't change the status quo so easily kid"
argument, and I'm Ok with that. That's why I'm suggesting to deprecate
--pretty; users would still be able to use it but will receive a
warning. If as you say users are happy with --pretty, then they'll
shout when they realize someone is taking their precious option away,
we could wait until 1.8.0 to make it obsolete (remove it completely).

IMHO these kinds of improvements *need to be done*, even if they are
painful and take a lot of time. That doesn't mean 'git-foo' will be
repeated again; we can learn from the mistakes of the past.

Cheers.

-- 
Felipe Contreras