The log --long vs log --short (default) debate

[Ian Clatworthy]

Tim Penhey wrote:
> On Wed, 21 Jan 2009 03:45:16 John Arbash Meinel wrote:
>> I think having a knob to tweak is nice, I'm just thinking we probably
>> want to default to preserving the old behavior unless strongly warranted.
>>
>> John
>> =:->
> 
> I think preserving the existing behaviour here is exactly the wrong thing to 
> do.  When I initially read Ian's email where merged revisions were not shown 
> by default I was so happy.

I think it's important to separate the issues here: adding the functionality vs
changing the default. I have a patch up for review for the first of these so
this email focusses on the latter issue.

> We need to think of the new users, and those who are looking to adopt a DVCS.  
> When people go `$vcs log` we want to be comparable.  Those doing these tests 
> don't often even look at the results, the only compare times.  Having the no-
> merge option as the default I think is the right thing to do.

I'm working on improving log speed, regardless of the default. Speed is a means
to an end though: I want bzr log to be a useful tool that's a pleasure to use
with the "right" UI. Selecting the "right" UI is tricky though ...

I like UIs that provide a summary and let me drill down, so *I* want to:

1. See the mainline only (log --short) 90% of the time
2. Drill down on the one or two merges of interest (log --long -rx.y.z).

It's no different when I'm exploring a filesystem using
ls/dir/Natilius/Dolphin/Finder/Explorer/etc. - I want to see the top level
and drill, not see everything expanded by default. Of course, expanding
everything by default is slower but that's *not* the main reason why it's
a bad design UI wise.

Now different people view the world different ways. Working my way feels
natural to those of us who have migrated from a central VCS: we get what we
expect and so much more. OTOH, it seems that those who have used a DVCS
forever expect to see every revision and that, to some at least, the idea of
hiding information by default is wrong. After all, history in a DVCS is
(strictly speaking) a graph and not a tree so it's arguably a bit different
from the filesystem metaphor I've used. Furthermore for an Emacs user like
Vincent, log is just a command for loading a buffer - Emacs searching does
the leg work. Fair enough.

So my plan for log looks like this:

1. Make it a pleasure to use by:
   - making it faster, particularly at seeing something
   - adding missing functionality, e.g. log -p, log DIR

2. Minimise the functional differences between --long, --short and (where
   sensible) --line, e.g. my log -n/--levels patch, showing tags in all
   formats

3. Change the default format/behaviour if and when there's consensus about
   that and the consequences for doing so are clearly understood. (I don't
   expect that to be in 1.12 btw.)

(3) is important but completing (1) and (2) are more so IMO. We should
certainly continue debating (3) but we shouldn't block (1) and (2) from
progressing because (3) isn't decided.

Ian C.