Re: [RFC/PATCH] git-fetch: mega-terse fetch output

["Shawn O. Pearce" <spearce@spearce.org>]

Jeff King <peff@peff.net> wrote:
> On Fri, Oct 19, 2007 at 10:14:59AM -0400, Nicolas Pitre wrote:
> 
> > > ==> git://repo.or.cz/git/spearce.git
> > >  * (new)              gitk -> spearce/gitk
> > >  * 1aa3d01..e7187e4   maint -> spearce/maint
> > >  * de61e42..7840ce6   master -> spearce/master
> > >  * 895be02..2fe5433   next -> spearce/next
> > >  + 89fa332...1e4c517  pu -> spearce/pu
> > >  * (new)              todo -> spearce/todo
> > 
> > Actually I think this is the best format so far: one line per branch, no 
> > terminal width issue (long branch names are simply wrapped), the 
> > old..new info is there also with the single character marker to quickly 
> > notice the type of update.

Yea, I think this is almost the right format.

Nicolas Pitre <nico@cam.org> wrote:
> Agreed.  ' ' = fast forward, '+' = forced update, and '!' = refused.
 
We're probably looking at something like this:

>From git://repo.or.cz/git/spearce.git
   1aa3d01..e7187e4   maint -> spearce/maint
   de61e42..7840ce6   master -> spearce/master
   895be02..2fe5433   next -> spearce/next
   (new)              todo -> spearce/todo
   (new)              tag v1.6.0
 + 89fa332...1e4c517  pu -> spearce/pu  (forced update)
 ! 2b5afb...289840    gitk -> spearce/gitk (non-fast forward)

Notice the sorting order by *type* of update.  I think it makes
the code slightly more complicated in builtin-fetch as we need to
classify each ref into a type of update, then sort them by that
type, but it allows the end-user to see the most "important" (not
simple fast-forward updates) at the end of their terminal window,
especially if there were many fast-forward branches.  Within a
class of update we still sort by ref name.

> Technically speaking, the hash IDs can be up to 80 characters long,
> since they are meant to be unique abbreviations. But in practice, I
> think leaving enough space for 10 + '...' + 10 should accomodate just
> about any project (IIRC, the kernel's longest non-unique is around 9).

Which nicely solves the issue with the window size as we aren't
really worring about it here in this display.

-- 
Shawn.