Nicolas Pitre <nico@xxxxxxx> wrote:
> Frankly, I think effort should be spent on the refs update display at
> this point. Something that looks like:
>
> * refs/heads/origin: fast forward to branch 'master' of git://gi
> t.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
> old..new: 66ffb04..4fa4d23
>
> [ note that I arbitrarily cut the long line before the 80th column to
> show the effect within an email ]
>
> You usually get long lines that gets wrapped, so that means 3 lines of
> screen space for one updated branches. Is the "66ffb04..4fa4d23"
> information really useful? Might someone ever care?
The reason its formatted the way it is today is someone can grab
that line into a copy-paste buffer and throw it onto a "git-log"
or "gitk" command line with ease to see what new stuff has come in.
Me, I just use the reflog if I care (`origin@{1}..origin`) to see
what a fetch changed in the tracking branch.
However I *don't* need the remote branch name or the remote URL,
especially if we are storing it into a tracking branch. That's most
likely coming from a configured remote that the user fetches from
frequently. I don't think about Linus' URL, I think about the fact
that in my linux-2.6 repository his directory is my origin remote.
Maybe something like this would be more useful:
* origin: fast-forwarded: 66ffb04..4fa4d23
Or if you are using refs/remotes style tracking branches:
* origin/master: fast-forwarded: 66ffb04..4fa4d23
* origin/pu: forcing update: 66ffb04..4fa4d23
Too terse? Yea, probably. But it is a whole lot shorter.
My other pet peeve here is the display from send-pack and
receive-pack when you push a ref. Hello?
updating 'refs/heads/master'
from de61e42b539ffbd28d2a2ba827bb0eb79767057b
to d7e56dbc4f60f6bd238e8612783541d89f006fb7
...
refs/heads/master: de61e42b539ffbd28d2a2ba827bb0eb79767057b -> d7e56dbc4f60f6bd238e8612783541d89f006fb7
That's like 4 too many SHA-1 strings for the average user.
--
Shawn.
-
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
