threads / patch / 42413

patch, 2 partsBetter ref summary alignment in "git fetch"

Subject: [PATCH 0/2] Better ref summary alignment in "git fetch"

## tl;dr

71 messages between May 22, 2016 and Jul 4, 2016. Diffs are folded; open one to read it.

replies: 70people: 6as markdown or json

Nguyễn Thái Ngọc Duy· May 22, 2016, 11:20 UTC · lore

I recently got a taste of a busy github repository where many branches are created (for Pull Requests) every day. Because branch names should be descriptive, branch names could range from 10 to 60 chars long. This makes "git fetch" output really messy.

So I resurrect a patch (1/2) I sent two years ago to keep alignment somewhat better. 2/2 is some more fancy adjustment to make sure one really long branch name will not make the rest of ref list suffer. But I think 1/2 is good enough most of the time.

Nguyễn Thái Ngọc Duy (2):
  fetch: better alignment in ref summary
  fetch: reduce ref column size when there are enough short ref names
 builtin/fetch.c | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)
-- 
2.8.2.524.g6ff3d78
Nguyễn Thái Ngọc Duy· May 22, 2016, 11:20 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH 1/2] fetch: better alignment in ref summary

Currently fetch hard-codes the "remote" column to be 10. For repos with long branch names, the output could look ugly like this

From github.com:pclouds/git
 * [new branch]      2nd-index  -> pclouds/2nd-index
 * [new branch]      3nd-index  -> pclouds/3nd-index
 * [new branch]      file-watcher -> pclouds/file-watcher
 * [new branch]      inst       -> pclouds/inst
 * [new branch]      large-file-fixes -> pclouds/large-file-fixes
 * [new branch]      ls         -> pclouds/ls
 * [new branch]      master     -> pclouds/master
 * [new branch]      multiple-work-trees -> pclouds/multiple-work-trees
 * [new branch]      mv         -> pclouds/mv
 * [new branch]      read-cache-daemon -> pclouds/read-cache-daemon
 * [new branch]      split-blob -> pclouds/split-blob
 * [new branch]      split-index -> pclouds/split-index
 * [new branch]      status-fast-fast -> pclouds/status-fast-fast
 * [new branch]      untracked-cache -> pclouds/untracked-cache
This patch makes the output a bit better with minimum code change
From github.com:pclouds/git
 * [new branch]      2nd-index  -> pclouds/2nd-index
 * [new branch]      3nd-index  -> pclouds/3nd-index
 * [new branch]      file-watcher -> pclouds/file-watcher
 * [new branch]      inst         -> pclouds/inst
 * [new branch]      large-file-fixes -> pclouds/large-file-fixes
 * [new branch]      ls               -> pclouds/ls
 * [new branch]      master           -> pclouds/master
 * [new branch]      multiple-work-trees -> pclouds/multiple-work-trees
 * [new branch]      mv                  -> pclouds/mv
 * [new branch]      read-cache-daemon   -> pclouds/read-cache-daemon
 * [new branch]      split-blob          -> pclouds/split-blob
 * [new branch]      split-index         -> pclouds/split-index
 * [new branch]      status-fast-fast    -> pclouds/status-fast-fast
 * [new branch]      untracked-cache     -> pclouds/untracked-cache

To make all "->" aligned, we may need to go through the ref list twice, or buffer the output and let column.c align it. Either way needs a lot more work than this.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 builtin/fetch.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)
Show changes to builtin/fetch.c +10 −1
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 1cf15d0..223e09b 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -465,7 +465,14 @@ fail:
 			   : STORE_REF_ERROR_OTHER;
 }
 
-#define REFCOL_WIDTH  10
+static int REFCOL_WIDTH = 10;
+
+static void adjust_refcol_width(int len)
+{
+	if (REFCOL_WIDTH < len) {
+		REFCOL_WIDTH = len;
+	}
+}
 
 static int update_local_ref(struct ref *ref,
 			    const char *remote,
@@ -477,6 +484,8 @@ static int update_local_ref(struct ref *ref,
 	struct branch *current_branch = branch_get(NULL);
 	const char *pretty_ref = prettify_refname(ref->name);
 
+	adjust_refcol_width(gettext_width(remote));
+
 	type = sha1_object_info(ref->new_oid.hash, NULL);
 	if (type < 0)
 		die(_("object %s not found"), oid_to_hex(&ref->new_oid));
-- 
2.8.2.524.g6ff3d78
Junio C Hamano· May 23, 2016, 00:58 UTC · re: Nguyễn Thái Ngọc Duy · lore

Re: [PATCH 1/2] fetch: better alignment in ref summary

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:
Show 8 quoted lines
> Currently fetch hard-codes the "remote" column to be 10. For repos
> with long branch names, the output could look ugly like this
>
> From github.com:pclouds/git
>  * [new branch]      2nd-index  -> pclouds/2nd-index
>  * [new branch]      3nd-index  -> pclouds/3nd-index
>  * [new branch]      file-watcher -> pclouds/file-watcher
>  ...

So, we have to show "an object taken from their name is copied to our name", and somebody designed the format to report it to use "their-name -> our-name", and decided that a certain number of columns is sufficient for "their-name" part and that attempting to align "->" sign is a good idea..

That was long before a few best practices were established. We encourage people to use longer and more descriptive branch names, so "their-name" is a lot longer than 10 columns, which contradicts the first one of two old assumptions. And we want to keep the second old assumption alive.

Progressively pushing "->" to the right like you did might be a cheap way to do so, but shouldn't we be also taking advantage of another best practice that has been established since we started reporting this "their-name came to our-name", namely, very often, our-name is a short and fixed prefix plus their-name?

That is, I wonder if the above can become something like:
Show 5 quoted lines
> From github.com:pclouds/git
>  * [new branch]      { -> pclouds/}2nd-index
>  * [new branch]      { -> pclouds/}3nd-index
>  * [new branch]      { -> pclouds/}file-watcher
>  ...

The above example borrows the idea used in diffstat label for renaming patch and I think you can design a better notataion, but a big point is that you can shorten the whole thing by not repeating the common part twice. The arrow aligns merely as a side effect of the shortening, taking advantage of the fact that most people fetch with "$their_prefix/*:$our_prefix/*" renaming refspec.

Duy Nguyen· May 23, 2016, 01:59 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/2] fetch: better alignment in ref summary

On Mon, May 23, 2016 at 7:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 14 quoted lines
> That is, I wonder if the above can become something like:
>
>> From github.com:pclouds/git
>>  * [new branch]      { -> pclouds/}2nd-index
>>  * [new branch]      { -> pclouds/}3nd-index
>>  * [new branch]      { -> pclouds/}file-watcher
>>  ...
>
> The above example borrows the idea used in diffstat label for
> renaming patch and I think you can design a better notataion, but a
> big point is that you can shorten the whole thing by not repeating
> the common part twice.  The arrow aligns merely as a side effect of
> the shortening, taking advantage of the fact that most people fetch
> with "$their_prefix/*:$our_prefix/*" renaming refspec.

I did think of that. My only concern is, with the new output I can't simply copy the ref name (e.g. pclouds/2nd-index) and use it to, say, examine with git-log. But I'm more of a "tab tab tab" person than "copy and paste", so I don't know how often people need to do that.

-- 
Duy
Marc Branchaud· May 26, 2016, 14:22 UTC · re: Duy Nguyen · lore

Re: [PATCH 1/2] fetch: better alignment in ref summary

On 2016-05-22 09:59 PM, Duy Nguyen wrote:
Show 20 quoted lines
> On Mon, May 23, 2016 at 7:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> That is, I wonder if the above can become something like:
>>
>>>  From github.com:pclouds/git
>>>   * [new branch]      { -> pclouds/}2nd-index
>>>   * [new branch]      { -> pclouds/}3nd-index
>>>   * [new branch]      { -> pclouds/}file-watcher
>>>   ...
>>
>> The above example borrows the idea used in diffstat label for
>> renaming patch and I think you can design a better notataion, but a
>> big point is that you can shorten the whole thing by not repeating
>> the common part twice.  The arrow aligns merely as a side effect of
>> the shortening, taking advantage of the fact that most people fetch
>> with "$their_prefix/*:$our_prefix/*" renaming refspec.
>
> I did think of that. My only concern is, with the new output I can't
> simply copy the ref name (e.g. pclouds/2nd-index) and use it to, say,
> examine with git-log. But I'm more of a "tab tab tab" person than
> "copy and paste", so I don't know how often people need to do that.

Why do we need any kind of "->" at all? How about simply (with an update to "old-branch" for comparison to probably-more-common output):

 From github.com:pclouds/git
    cafed0c..badfeed  pclouds/old-branch
  * [new branch]      pclouds/2nd-index
  * [new branch]      pclouds/3nd-index
  * [new branch]      pclouds/file-watcher
		M.
Jeff King· May 26, 2016, 16:29 UTC · re: Marc Branchaud · lore

Re: [PATCH 1/2] fetch: better alignment in ref summary

On Thu, May 26, 2016 at 10:22:25AM -0400, Marc Branchaud wrote:
Show 8 quoted lines
> Why do we need any kind of "->" at all?  How about simply (with an update to
> "old-branch" for comparison to probably-more-common output):
> 
> From github.com:pclouds/git
>    cafed0c..badfeed  pclouds/old-branch
>  * [new branch]      pclouds/2nd-index
>  * [new branch]      pclouds/3nd-index
>  * [new branch]      pclouds/file-watcher
That covers the common case of:
  refs/heads/*:refs/remotes/pclouds/*

but sometimes the remote and local names are not the same, and the mapping is interesting. Like:

  $ git fetch origin refs/pull/*/head:refs/remotes/pr/*
  ...
   * [new ref]         refs/pull/77/head -> pr/77
Or even:
  $ git fetch origin refs/pull/77/head refs/pull/78/head
  From ...
   * branch            refs/pull/77/head -> FETCH_HEAD
   * branch            refs/pull/78/head -> FETCH_HEAD

So I think we need a scheme that can show the interesting mappings, but collapses to something simple for the common case.

-Peff
Junio C Hamano· May 26, 2016, 17:42 UTC · re: Jeff King · lore

Re: [PATCH 1/2] fetch: better alignment in ref summary

Jeff King <peff@peff.net> writes:
Show 31 quoted lines
> On Thu, May 26, 2016 at 10:22:25AM -0400, Marc Branchaud wrote:
>
>> Why do we need any kind of "->" at all?  How about simply (with an update to
>> "old-branch" for comparison to probably-more-common output):
>> 
>> From github.com:pclouds/git
>>    cafed0c..badfeed  pclouds/old-branch
>>  * [new branch]      pclouds/2nd-index
>>  * [new branch]      pclouds/3nd-index
>>  * [new branch]      pclouds/file-watcher
>
> That covers the common case of:
>
>   refs/heads/*:refs/remotes/pclouds/*
>
> but sometimes the remote and local names are not the same, and the
> mapping is interesting. Like:
>
>   $ git fetch origin refs/pull/*/head:refs/remotes/pr/*
>   ...
>    * [new ref]         refs/pull/77/head -> pr/77
>
> Or even:
>
>   $ git fetch origin refs/pull/77/head refs/pull/78/head
>   From ...
>    * branch            refs/pull/77/head -> FETCH_HEAD
>    * branch            refs/pull/78/head -> FETCH_HEAD
>
> So I think we need a scheme that can show the interesting mappings, but
> collapses to something simple for the common case.

True. One of the entries in Marc's example is easily misread as "pclouds/2nd-index branch at its refs/heads/pclouds/2nd-index was fetched to its usual place", when Marc wanted to say "they had 2nd-index branch at refs/heads/2nd-index, and it was copied to our refs/remotes/pclouds/2nd-index".

So even though we might be able to make sure it is unambiguous without "this -> that" ("->" is pronounced as 'became'), it is easily misread.

Marc Branchaud· May 26, 2016, 18:13 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/2] fetch: better alignment in ref summary

On 2016-05-26 01:42 PM, Junio C Hamano wrote:
Show 10 quoted lines
>
> True.  One of the entries in Marc's example is easily misread as
> "pclouds/2nd-index branch at its refs/heads/pclouds/2nd-index was
> fetched to its usual place", when Marc wanted to say "they had
> 2nd-index branch at refs/heads/2nd-index, and it was copied to our
> refs/remotes/pclouds/2nd-index".
>
> So even though we might be able to make sure it is unambiguous
> without "this -> that" ("->" is pronounced as 'became'), it is
> easily misread.

Actually, I tend to just think of it as "this is a local name you can use to refer to the new thing that was just fetched." The left-hand side describes the thing being fetched (new or updated branch/tag/ref), and the right hand side shows how to locally refer to that thing.

The fact that something is buried in some odd part of the ref tree is less relevant, IMO. If I'm using custom fetch refspecs or other oddities, I'll have that in the back of my head. But what I really care about is what ref I can use with commands like log and checkout.

So, regarding Peff's examples:
 > $ git fetch origin refs/pull/*/head:refs/remotes/pr/*

Just show me the "pr/foo" refs. I know where things are coming from. Even if I configured that fetch refspec a long time ago, I don't need to see the exact mapping every time I fetch.

 > $ git fetch origin refs/pull/77/head refs/pull/78/head

Ah, now this is an odd case. Maybe there should be a different output format altogether for this one. The problem is that the remote refs being fetched are stored without any kind of local ref. (Commands like "git log FETCH_HEAD" only work with the last ref fetched, even though all the SHAs get added to the .git/FETCH_HEAD file. Maybe if git supported a "FETCH_HEAD@{x}" syntax...)

I think the output should show the plain SHA values, since those are the only things the user can use to work with those refs. Maybe something like:

	From ...
	 * origin:refs/pull/77/head  abcd0123
	 * origin:refs/pull/78/head  453def00
(Not 100% sure about the "origin:" prefix...)
		M.
Junio C Hamano· May 26, 2016, 19:31 UTC · re: Marc Branchaud · lore

Re: [PATCH 1/2] fetch: better alignment in ref summary

Marc Branchaud <marcnarc@xiplink.com> writes:
Show 12 quoted lines
> The fact that something is buried in some odd part of the ref tree is
> less relevant, IMO.  If I'm using custom fetch refspecs or other
> oddities, I'll have that in the back of my head.  But what I really
> care about is what ref I can use with commands like log and checkout.
>
> So, regarding Peff's examples:
>
>> $ git fetch origin refs/pull/*/head:refs/remotes/pr/*
>
> Just show me the "pr/foo" refs.  I know where things are coming
> from. Even if I configured that fetch refspec a long time ago, I don't
> need to see the exact mapping every time I fetch.

That is only because you are used to seeing them. You cannot claim "I'll remember forever without seeing them" without actually experiencing not seeing them for a long time.

> I think the output should show the plain SHA values, since those are
> the only things the user can use to work with those refs.

When they tell others how to reproduce what they did (or record what they did so that they can reproduce it later), they need what it is called at the remote end.

I would hesitate to go in the approach based on discarding information, as if it is the only way to shorten and clarify the output. Let's not do so before thinking things through to achieve the same while keeping the information we give to the users.

Marc Branchaud· May 26, 2016, 22:13 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/2] fetch: better alignment in ref summary

On 2016-05-26 03:31 PM, Junio C Hamano wrote:
Show 18 quoted lines
> Marc Branchaud <marcnarc@xiplink.com> writes:
>
>> The fact that something is buried in some odd part of the ref tree is
>> less relevant, IMO.  If I'm using custom fetch refspecs or other
>> oddities, I'll have that in the back of my head.  But what I really
>> care about is what ref I can use with commands like log and checkout.
>>
>> So, regarding Peff's examples:
>>
>>> $ git fetch origin refs/pull/*/head:refs/remotes/pr/*
>>
>> Just show me the "pr/foo" refs.  I know where things are coming
>> from. Even if I configured that fetch refspec a long time ago, I don't
>> need to see the exact mapping every time I fetch.
>
> That is only because you are used to seeing them.  You cannot claim
> "I'll remember forever without seeing them" without actually
> experiencing not seeing them for a long time.

I don't expect (or even want) to forever remember the mapping. It's a matter of context.

When fetching, I'm interested in shiny new refs and I want to work with them.

When configuring a remote repository, I'm interested in how to bring that repo's refs into my own repository.

These are two distinct modes of thought, and I don't think fetch's output always needs to display the latter. Perhaps the --verbose switch could turn on showing how the remote refs get mapped. I can see how that would occasionally be useful for debugging fetch refspecs.

Show 6 quoted lines
>> I think the output should show the plain SHA values, since those are
>> the only things the user can use to work with those refs.
>
> When they tell others how to reproduce what they did (or record what
> they did so that they can reproduce it later), they need what it is
> called at the remote end.

Which is why I included the refnames in my proposal to Peff's second example. Really, the SHA and the remote's name for the SHA are the only meaningful things in this case.

> I would hesitate to go in the approach based on discarding
> information, as if it is the only way to shorten and clarify the
> output.  Let's not do so before thinking things through to achieve
> the same while keeping the information we give to the users.

I agree, this is not something to undertake lightly. But I've yet to be convinced of the utility of always showing the ref mapping during a fetch.

I actually found fetch's output quite confusing when I first started using git. It's really not obvious that the thing on the left of the "->" is the remote's local name, especially since to see what was fetched one has to use the thing on the right-hand side -- which is obviously in a remote-specific namespace. (Admittedly, this was before checkout learned to search refs/remotes/ for things to check out.)

		M.
Jeff King· May 26, 2016, 05:18 UTC · re: Nguyễn Thái Ngọc Duy · lore

Re: [PATCH 1/2] fetch: better alignment in ref summary

On Sun, May 22, 2016 at 06:20:18PM +0700, Nguyễn Thái Ngọc Duy wrote:
> To make all "->" aligned, we may need to go through the ref list
> twice, or buffer the output and let column.c align it. Either way
> needs a lot more work than this.

I don't think a two-pass approach is _too_ bad. The trickiest thing is that we handle the "prune" refs separately, even though they go in the same status table.

However, I tried it, and the results looked much worse for my example repo than yours. The problem is that I had one gigantic refname, and that shoved the "->" and everything after far to the right, where they wrapped to the next line.

Though the stair-stepping in your patch is funny, the output is easier to read.

I do agree with Junio that we could probably improve the output quite a bit by not showing each refname twice in the common case. I don't quite find the "{ -> origin/}whatever" particularly pretty, but something like that which keeps the variable bits at the end would make this problem just go away.

> -#define REFCOL_WIDTH  10
> +static int REFCOL_WIDTH = 10;

This should probably go lower-case if it's not a preprocessor macro anymore. I know it makes the diff a lot noisier, but I think it's worth it.

-Peff
Duy Nguyen· Jun 2, 2016, 13:58 UTC · re: Jeff King · lore

Re: [PATCH 1/2] fetch: better alignment in ref summary

On Mon, May 23, 2016 at 7:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 7 quoted lines
> That is, I wonder if the above can become something like:
>
>> From github.com:pclouds/git
>>  * [new branch]      { -> pclouds/}2nd-index
>>  * [new branch]      { -> pclouds/}3nd-index
>>  * [new branch]      { -> pclouds/}file-watcher
>>  ...
for context of the following quote...
On Thu, May 26, 2016 at 12:18 PM, Jeff King <peff@peff.net> wrote:
Show 5 quoted lines
> I do agree with Junio that we could probably improve the output quite a
> bit by not showing each refname twice in the common case. I don't quite
> find the "{ -> origin/}whatever" particularly pretty, but something like
> that which keeps the variable bits at the end would make this problem
> just go away.

I tried it out. It's a bit hard to read at the "/}" boundary. Color highlight might help. But it occurs to me, could we extend refspec a bit to allow "foo/bar:base/..." be be equivalent of "foo/bar:base/foo/bar". Then fetch output could become

>>  * [new branch]      2nd-index:pclouds/...
>>  * [new branch]      3nd-index:pclouds/...
>>  * [new branch]      file-watcher:pclouds/...

It might be a tiny bit better, and a forced update could be displayed with a prefix '+'. Hmm?

-- 
Duy
Junio C Hamano· Jun 2, 2016, 16:16 UTC · re: Duy Nguyen · lore

Re: [PATCH 1/2] fetch: better alignment in ref summary

Duy Nguyen <pclouds@gmail.com> writes:
Show 29 quoted lines
> On Mon, May 23, 2016 at 7:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> That is, I wonder if the above can become something like:
>>
>>> From github.com:pclouds/git
>>>  * [new branch]      { -> pclouds/}2nd-index
>>>  * [new branch]      { -> pclouds/}3nd-index
>>>  * [new branch]      { -> pclouds/}file-watcher
>>>  ...
>
> for context of the following quote...
>
> On Thu, May 26, 2016 at 12:18 PM, Jeff King <peff@peff.net> wrote:
>> I do agree with Junio that we could probably improve the output quite a
>> bit by not showing each refname twice in the common case. I don't quite
>> find the "{ -> origin/}whatever" particularly pretty, but something like
>> that which keeps the variable bits at the end would make this problem
>> just go away.
>
> I tried it out. It's a bit hard to read at the "/}" boundary. Color
> highlight might help. But it occurs to me, could we extend refspec a
> bit to allow "foo/bar:base/..." be be equivalent of
> "foo/bar:base/foo/bar". Then fetch output could become
>
>>>  * [new branch]      2nd-index:pclouds/...
>>>  * [new branch]      3nd-index:pclouds/...
>>>  * [new branch]      file-watcher:pclouds/...
>
> It might be a tiny bit better, and a forced update could be displayed
> with a prefix '+'. Hmm?

I do not find that "..." particularly more readable, but that probably is very subjective. It is much less copy&pastable, when compared to pasting "pclouds/}2nd-index" and then removing "}".

Nguyễn Thái Ngọc Duy· May 22, 2016, 11:20 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH 2/2] fetch: reduce ref column size when there are enough short ref names

A flaw with the previous patch is, if there is a single long ref name, the rest of the ref list will be aligned with the big column, wasting lots of space (and potentially be wrapped around by the terminal, making it even harder to read).

This patch tries to mitigate that. If there are five consecutive refs whose name is at least ten chars shorter than column width, the width is reduced by ten. Five and ten are picked out of thin air. But the short width reduction (instead of "REFCOL_WIDTH = len") is to avoid the column width being reduced then grown back too much and too fast (imagine the next ref is really short then the ref after that is super long).

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 builtin/fetch.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)
Show changes to builtin/fetch.c +12 −0
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 223e09b..ae2ff0c 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -469,8 +469,20 @@ static int REFCOL_WIDTH = 10;
 
 static void adjust_refcol_width(int len)
 {
+	static int reduce_width_count;
+
+	if (REFCOL_WIDTH > 10 && len < REFCOL_WIDTH - 10) {
+		reduce_width_count++;
+		if (reduce_width_count == 5) {
+			REFCOL_WIDTH -= 10;
+			reduce_width_count = 0;
+		}
+	} else
+		reduce_width_count = 0;
+
 	if (REFCOL_WIDTH < len) {
 		REFCOL_WIDTH = len;
+		reduce_width_count = 0;
 	}
 }
 
-- 
2.8.2.524.g6ff3d78
Nguyễn Thái Ngọc Duy· Jun 3, 2016, 11:08 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v2 0/3] Better ref summary alignment in "git fetch"

v2 reformats "abc/common -> def/common" to "{abc -> def}/common" instead and fall back to "a -> b" when they have nothing in commmon (e.g. "HEAD -> FETCH_HEAD"). We could add an option if a user wants to stick with "a -> b" (and we could do some alignment there as well) but it's not part of this series.

It's a shame that the flag '-' in these ref update lines is not the same in fetch and push (see 1/3). Because git-fetch does not support --porcelain option, maybe it's not too late to change its meaning...

Nguyễn Thái Ngọc Duy (3):
  git-fetch.txt: document fetch output
  fetch: refactor ref update status formatting code
  fetch: reduce duplicate in ref update status lines
 Documentation/git-fetch.txt |  53 +++++++++++++++++++++
 builtin/fetch.c             | 112 +++++++++++++++++++++++++++++---------------
 t/t5510-fetch.sh            |   4 +-
 t/t5526-fetch-submodules.sh |  26 +++++-----
 4 files changed, 141 insertions(+), 54 deletions(-)
-- 
2.8.2.524.g6ff3d78
Nguyễn Thái Ngọc Duy· Jun 3, 2016, 11:08 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v2 1/3] git-fetch.txt: document fetch output

This documents the ref update status of fetch. The structure of this output is defined in [1]. The ouput content is refined a bit in [2] [3] [4].

This patch is a copy from git-push.txt, modified a bit because the flag '-' means different things in push (delete) and fetch (tag update). We probably should unify the documents at some point in future.

PS. For code archaeologists, the discussion mentioned in [1] is probably [5].

[1] 165f390 (git-fetch: more terse fetch output - 2007-11-03)
[2] 6315472 (fetch: report local storage errors ... - 2008-06-26)
[3] f360d84 (builtin-fetch: add --prune option - 2009-11-10)
[4] 0997ada (fetch: describe new refs based on where... - 2012-04-16)
[5] http://thread.gmane.org/gmane.comp.version-control.git/61657
---
 Documentation/git-fetch.txt | 46 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)
Show changes to Documentation/git-fetch.txt +46 −0
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index efe56e0..18e733c 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -99,6 +99,52 @@ The latter use of the `remote.<repository>.fetch` values can be
 overridden by giving the `--refmap=<refspec>` parameter(s) on the
 command line.
 
+OUTPUT
+------
+
+The output of "git fetch" depends on the transport method used; this
+section describes the output when pushing over the Git protocol
+(either locally or via ssh).
+
+The status of the push is output in tabular form, with each line
+representing the status of a single ref. Each line is of the form:
+
+-------------------------------
+ <flag> <summary> <from> -> <to> (<reason>)
+-------------------------------
+
+The status of up-to-date refs is shown only if --verbose option is
+used.
+
+flag::
+	A single character indicating the status of the ref:
+(space);; for a successfully fetched fast-forward;
+`+`;; for a successful forced update;
+`x`;; for a successfully deleted ref;
+`-`;; for a successful tag update;
+`*`;; for a successfully fetched new ref;
+`!`;; for a ref that was rejected or failed to update; and
+`=`;; for a ref that was up to date and did not need fetching.
+
+summary::
+	For a successfully fetched ref, the summary shows the old and new
+	values of the ref in a form suitable for using as an argument to
+	`git log` (this is `<old>..<new>` in most cases, and
+	`<old>...<new>` for forced non-fast-forward updates).
+
+from::
+	The name of the remote ref being fetched from, minus its
+	`refs/<type>/` prefix. In the case of deletion, the name of
+	the remote ref is "(none)".
+
+to::
+	The name of the local ref being updated, minus its
+	`refs/<type>/` prefix.
+
+reason::
+	A human-readable explanation. In the case of successfully fetched
+	refs, no explanation is needed. For a failed ref, the reason for
+	failure is described.
 
 EXAMPLES
 --------
-- 
2.8.2.524.g6ff3d78
Marc Branchaud· Jun 3, 2016, 14:33 UTC · re: Nguyễn Thái Ngọc Duy · lore

Re: [PATCH v2 1/3] git-fetch.txt: document fetch output

On 2016-06-03 07:08 AM, Nguyễn Thái Ngọc Duy wrote:
> This documents the ref update status of fetch. The structure of this
> output is defined in [1]. The ouput content is refined a bit in [2]
s/The ouput/The output/
Show 31 quoted lines
> [3] [4].
>
> This patch is a copy from git-push.txt, modified a bit because the
> flag '-' means different things in push (delete) and fetch (tag
> update). We probably should unify the documents at some point in
> future.
>
> PS. For code archaeologists, the discussion mentioned in [1] is
> probably [5].
>
> [1] 165f390 (git-fetch: more terse fetch output - 2007-11-03)
> [2] 6315472 (fetch: report local storage errors ... - 2008-06-26)
> [3] f360d84 (builtin-fetch: add --prune option - 2009-11-10)
> [4] 0997ada (fetch: describe new refs based on where... - 2012-04-16)
> [5] http://thread.gmane.org/gmane.comp.version-control.git/61657
> ---
>   Documentation/git-fetch.txt | 46 +++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 46 insertions(+)
>
> diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> index efe56e0..18e733c 100644
> --- a/Documentation/git-fetch.txt
> +++ b/Documentation/git-fetch.txt
> @@ -99,6 +99,52 @@ The latter use of the `remote.<repository>.fetch` values can be
>   overridden by giving the `--refmap=<refspec>` parameter(s) on the
>   command line.
>
> +OUTPUT
> +------
> +
> +The output of "git fetch" depends on the transport method used; this

What a mysterious statement! Does this tabular format actually change when fetching over HTTP? Maybe it's worth documenting the differences?

> +section describes the output when pushing over the Git protocol
s/pushing/fetching/
> +(either locally or via ssh).
> +
> +The status of the push is output in tabular form, with each line
s/push/fetch/
Show 14 quoted lines
> +representing the status of a single ref. Each line is of the form:
> +
> +-------------------------------
> + <flag> <summary> <from> -> <to> (<reason>)
> +-------------------------------
> +
> +The status of up-to-date refs is shown only if --verbose option is
> +used.
> +
> +flag::
> +	A single character indicating the status of the ref:
> +(space);; for a successfully fetched fast-forward;
> +`+`;; for a successful forced update;
> +`x`;; for a successfully deleted ref;

I did a double-take here, until I remembered --prune. Maybe add "(when using the --prune option)"?

		M.
Jeff King· Jun 3, 2016, 16:55 UTC · re: Nguyễn Thái Ngọc Duy · lore

Re: [PATCH v2 1/3] git-fetch.txt: document fetch output

On Fri, Jun 03, 2016 at 06:08:41PM +0700, Nguyễn Thái Ngọc Duy wrote:
> This patch is a copy from git-push.txt, modified a bit because the
> flag '-' means different things in push (delete) and fetch (tag
> update). We probably should unify the documents at some point in
> future.

This is stderr output from a porcelain. I don't think we make any promises about the format, and since we're changing other bits, perhaps now is a good time to unify the "-" handling.

> +The status of the push is output in tabular form, with each line
> +representing the status of a single ref. Each line is of the form:

Like Marc, I wondered what this means. :) I know that there have been different status outputs from transport.c and fetch.c in the past, but I thought we had unified a lot of that. If we haven't, it seems like a good time to do so (and I'd prefer fixing to documenting quirks, when it's something that isn't plumbing).

-Peff
Nguyễn Thái Ngọc Duy· Jun 3, 2016, 11:08 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v2 2/3] fetch: refactor ref update status formatting code

This makes it easier to change the formatting later. And it makes sure translators cannot mess up format specifiers and break Git.

There are a couple call sites where the length of the second column is TRANSPORT_SUMMARY_WIDTH instead of calculated by TRANSPORT_SUMMARY(), which is enforced now. The result should be the same because these call sites do not contain characters outside ASCII range.

The two strbuf_addf() calls instead of one is mostly to reduce
diff-noise in a future patch where "ref -> ref" is reformatted
differently.
---
 builtin/fetch.c | 77 ++++++++++++++++++++++++++++-----------------------------
 1 file changed, 38 insertions(+), 39 deletions(-)
Show changes to builtin/fetch.c +38 −39
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 1582ca7..a7f152a 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -451,6 +451,16 @@ fail:
 
 #define REFCOL_WIDTH  10
 
+static void format_display(struct strbuf *display, char code,
+			   const char *summary, const char *error,
+			   const char *remote, const char *local)
+{
+	strbuf_addf(display, "%c %-*s ", code, TRANSPORT_SUMMARY(summary));
+	strbuf_addf(display, "%-*s -> %s", REFCOL_WIDTH, remote, local);
+	if (error)
+		strbuf_addf(display, "  (%s)", error);
+}
+
 static int update_local_ref(struct ref *ref,
 			    const char *remote,
 			    const struct ref *remote_ref,
@@ -467,9 +477,8 @@ static int update_local_ref(struct ref *ref,
 
 	if (!oidcmp(&ref->old_oid, &ref->new_oid)) {
 		if (verbosity > 0)
-			strbuf_addf(display, "= %-*s %-*s -> %s",
-				    TRANSPORT_SUMMARY(_("[up to date]")),
-				    REFCOL_WIDTH, remote, pretty_ref);
+			format_display(display, '=', _("[up to date]"), NULL,
+				       remote, pretty_ref);
 		return 0;
 	}
 
@@ -481,10 +490,9 @@ static int update_local_ref(struct ref *ref,
 		 * If this is the head, and it's not okay to update
 		 * the head, and the old value of the head isn't empty...
 		 */
-		strbuf_addf(display,
-			    _("! %-*s %-*s -> %s  (can't fetch in current branch)"),
-			    TRANSPORT_SUMMARY(_("[rejected]")),
-			    REFCOL_WIDTH, remote, pretty_ref);
+		format_display(display, '!', _("[rejected]"),
+			       _("can't fetch in current branch"),
+			       remote, pretty_ref);
 		return 1;
 	}
 
@@ -492,11 +500,9 @@ static int update_local_ref(struct ref *ref,
 	    starts_with(ref->name, "refs/tags/")) {
 		int r;
 		r = s_update_ref("updating tag", ref, 0);
-		strbuf_addf(display, "%c %-*s %-*s -> %s%s",
-			    r ? '!' : '-',
-			    TRANSPORT_SUMMARY(_("[tag update]")),
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    r ? _("  (unable to update local ref)") : "");
+		format_display(display, r ? '!' : '-', _("[tag update]"),
+			       r ? _("unable to update local ref") : NULL,
+			       remote, pretty_ref);
 		return r;
 	}
 
@@ -527,11 +533,9 @@ static int update_local_ref(struct ref *ref,
 		    (recurse_submodules != RECURSE_SUBMODULES_ON))
 			check_for_new_submodule_commits(ref->new_oid.hash);
 		r = s_update_ref(msg, ref, 0);
-		strbuf_addf(display, "%c %-*s %-*s -> %s%s",
-			    r ? '!' : '*',
-			    TRANSPORT_SUMMARY(what),
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    r ? _("  (unable to update local ref)") : "");
+		format_display(display, r ? '!' : '*', what,
+			       r ? _("unable to update local ref") : NULL,
+			       remote, pretty_ref);
 		return r;
 	}
 
@@ -545,11 +549,9 @@ static int update_local_ref(struct ref *ref,
 		    (recurse_submodules != RECURSE_SUBMODULES_ON))
 			check_for_new_submodule_commits(ref->new_oid.hash);
 		r = s_update_ref("fast-forward", ref, 1);
-		strbuf_addf(display, "%c %-*s %-*s -> %s%s",
-			    r ? '!' : ' ',
-			    TRANSPORT_SUMMARY_WIDTH, quickref.buf,
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    r ? _("  (unable to update local ref)") : "");
+		format_display(display, r ? '!' : ' ', quickref.buf,
+			       r ? _("unable to update local ref") : NULL,
+			       remote, pretty_ref);
 		strbuf_release(&quickref);
 		return r;
 	} else if (force || ref->force) {
@@ -562,18 +564,14 @@ static int update_local_ref(struct ref *ref,
 		    (recurse_submodules != RECURSE_SUBMODULES_ON))
 			check_for_new_submodule_commits(ref->new_oid.hash);
 		r = s_update_ref("forced-update", ref, 1);
-		strbuf_addf(display, "%c %-*s %-*s -> %s  (%s)",
-			    r ? '!' : '+',
-			    TRANSPORT_SUMMARY_WIDTH, quickref.buf,
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    r ? _("unable to update local ref") : _("forced update"));
+		format_display(display, r ? '!' : '+', quickref.buf,
+			       r ? _("unable to update local ref") : _("forced update"),
+			       remote, pretty_ref);
 		strbuf_release(&quickref);
 		return r;
 	} else {
-		strbuf_addf(display, "! %-*s %-*s -> %s  %s",
-			    TRANSPORT_SUMMARY(_("[rejected]")),
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    _("(non-fast-forward)"));
+		format_display(display, '!', _("[rejected]"), _("non-fast-forward"),
+			       remote, pretty_ref);
 		return 1;
 	}
 }
@@ -714,11 +712,10 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
 				rc |= update_local_ref(ref, what, rm, &note);
 				free(ref);
 			} else
-				strbuf_addf(&note, "* %-*s %-*s -> FETCH_HEAD",
-					    TRANSPORT_SUMMARY_WIDTH,
-					    *kind ? kind : "branch",
-					    REFCOL_WIDTH,
-					    *what ? what : "HEAD");
+				format_display(&note, '*',
+					       *kind ? kind : "branch", NULL,
+					       *what ? what : "HEAD",
+					       "FETCH_HEAD");
 			if (note.len) {
 				if (verbosity >= 0 && !shown_url) {
 					fprintf(stderr, _("From %.*s\n"),
@@ -812,13 +809,15 @@ static int prune_refs(struct refspec *refs, int ref_count, struct ref *ref_map,
 
 	if (verbosity >= 0) {
 		for (ref = stale_refs; ref; ref = ref->next) {
+			struct strbuf sb = STRBUF_INIT;
 			if (!shown_url) {
 				fprintf(stderr, _("From %.*s\n"), url_len, url);
 				shown_url = 1;
 			}
-			fprintf(stderr, " x %-*s %-*s -> %s\n",
-				TRANSPORT_SUMMARY(_("[deleted]")),
-				REFCOL_WIDTH, _("(none)"), prettify_refname(ref->name));
+			format_display(&sb, 'x', _("[deleted]"), NULL,
+				       _("(none)"), prettify_refname(ref->name));
+			fprintf(stderr, " %s\n",sb.buf);
+			strbuf_release(&sb);
 			warn_dangling_symref(stderr, dangling_msg, ref->name);
 		}
 	}
-- 
2.8.2.524.g6ff3d78
Junio C Hamano· Jun 3, 2016, 16:48 UTC · re: Nguyễn Thái Ngọc Duy · lore

Re: [PATCH v2 2/3] fetch: refactor ref update status formatting code

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:
Show 13 quoted lines
> This makes it easier to change the formatting later. And it makes sure
> translators cannot mess up format specifiers and break Git.
> ...
> +static void format_display(struct strbuf *display, char code,
> +			   const char *summary, const char *error,
> +			   const char *remote, const char *local)
> +{
> +	strbuf_addf(display, "%c %-*s ", code, TRANSPORT_SUMMARY(summary));
> +	strbuf_addf(display, "%-*s -> %s", REFCOL_WIDTH, remote, local);
> +	if (error)
> +		strbuf_addf(display, "  (%s)", error);
> +}
> +
Nice reduction of the code repetition below.  Looks very sensible.
Nguyễn Thái Ngọc Duy· Jun 3, 2016, 11:08 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v2 3/3] fetch: reduce duplicate in ref update status lines

When there are lots of ref updates, each has different name length, this
will make it easier to look because the variable part is at the end.
---
 Documentation/git-fetch.txt |  7 +++++++
 builtin/fetch.c             | 37 ++++++++++++++++++++++++++++++++++++-
 t/t5510-fetch.sh            |  4 ++--
 t/t5526-fetch-submodules.sh | 26 +++++++++++++-------------
 4 files changed, 58 insertions(+), 16 deletions(-)
Show changes to 4 files +58 −16

Documentation/git-fetch.txt, builtin/fetch.c, t/t5510-fetch.sh, t/t5526-fetch-submodules.sh

diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 18e733c..61c3bd1 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -113,6 +113,13 @@ representing the status of a single ref. Each line is of the form:
  <flag> <summary> <from> -> <to> (<reason>)
 -------------------------------
 
+When `from` and `to` share a common suffix, the line could be
+displayed in the form:
+
+-------------------------------
+ <flag> <summary> {<from> -> <to>}<suffix> (<reason>)
+-------------------------------
+
 The status of up-to-date refs is shown only if --verbose option is
 used.
 
diff --git a/builtin/fetch.c b/builtin/fetch.c
index a7f152a..15782d6 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -451,12 +451,47 @@ fail:
 
 #define REFCOL_WIDTH  10
 
+static int common_suffix_length(const char *a, const char *b)
+{
+	const char *pa = a + strlen(a);
+	const char *pb = b + strlen(b);
+	int count = 0;
+
+	while (pa > a && pb > b && pa[-1] == pb[-1]) {
+		pa--;
+		pb--;
+		count++;
+	}
+
+	/* stick to '/' boundary, do not break in the middle of a word */
+	while (count) {
+		if (*pa == '/' ||
+		    (pa == a && pb > b && pb[-1] == '/') ||
+		    (pb == b && pa > a && pa[-1] == '/'))
+			break;
+		pa++;
+		pb++;
+		count--;
+	}
+
+	return count;
+}
+
 static void format_display(struct strbuf *display, char code,
 			   const char *summary, const char *error,
 			   const char *remote, const char *local)
 {
+	int len;
+
 	strbuf_addf(display, "%c %-*s ", code, TRANSPORT_SUMMARY(summary));
-	strbuf_addf(display, "%-*s -> %s", REFCOL_WIDTH, remote, local);
+	len = common_suffix_length(remote, local);
+	if (len)
+		strbuf_addf(display, "{%.*s -> %.*s}%s",
+			    (int)strlen(remote) - len, remote,
+			    (int)strlen(local) - len, local,
+			    remote + strlen(remote) - len);
+	else
+		strbuf_addf(display, "%-*s -> %s", REFCOL_WIDTH, remote, local);
 	if (error)
 		strbuf_addf(display, "  (%s)", error);
 }
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 454d896..9a7649c 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -222,11 +222,11 @@ test_expect_success 'fetch uses remote ref names to describe new refs' '
 	(
 		cd descriptive &&
 		git fetch o 2>actual &&
-		grep " -> refs/crazyheads/descriptive-branch$" actual |
+		grep " -> refs/crazyheads/.descriptive-branch$" actual |
 		test_i18ngrep "new branch" &&
 		grep " -> descriptive-tag$" actual |
 		test_i18ngrep "new tag" &&
-		grep " -> crazy$" actual |
+		grep " -> .crazy$" actual |
 		test_i18ngrep "new ref"
 	) &&
 	git checkout master
diff --git a/t/t5526-fetch-submodules.sh b/t/t5526-fetch-submodules.sh
index 954d0e4..2285c47 100755
--- a/t/t5526-fetch-submodules.sh
+++ b/t/t5526-fetch-submodules.sh
@@ -18,7 +18,7 @@ add_upstream_commit() {
 		head2=$(git rev-parse --short HEAD) &&
 		echo "Fetching submodule submodule" > ../expect.err &&
 		echo "From $pwd/submodule" >> ../expect.err &&
-		echo "   $head1..$head2  master     -> origin/master" >> ../expect.err
+		echo "   $head1..$head2  { -> origin/}master" >> ../expect.err
 	) &&
 	(
 		cd deepsubmodule &&
@@ -30,7 +30,7 @@ add_upstream_commit() {
 		head2=$(git rev-parse --short HEAD) &&
 		echo "Fetching submodule submodule/subdir/deepsubmodule" >> ../expect.err
 		echo "From $pwd/deepsubmodule" >> ../expect.err &&
-		echo "   $head1..$head2  master     -> origin/master" >> ../expect.err
+		echo "   $head1..$head2  { -> origin/}master" >> ../expect.err
 	)
 }
 
@@ -235,7 +235,7 @@ test_expect_success "Recursion stops when no new submodule commits are fetched"
 	git commit -m "new submodule" &&
 	head2=$(git rev-parse --short HEAD) &&
 	echo "From $pwd/." > expect.err.sub &&
-	echo "   $head1..$head2  master     -> origin/master" >>expect.err.sub &&
+	echo "   $head1..$head2  { -> origin/}master" >>expect.err.sub &&
 	head -3 expect.err >> expect.err.sub &&
 	(
 		cd downstream &&
@@ -253,7 +253,7 @@ test_expect_success "Recursion doesn't happen when new superproject commits don'
 	git commit -m "new file" &&
 	head2=$(git rev-parse --short HEAD) &&
 	echo "From $pwd/." > expect.err.file &&
-	echo "   $head1..$head2  master     -> origin/master" >> expect.err.file &&
+	echo "   $head1..$head2  { -> origin/}master" >> expect.err.file &&
 	(
 		cd downstream &&
 		git fetch >../actual.out 2>../actual.err
@@ -277,7 +277,7 @@ test_expect_success "Recursion picks up config in submodule" '
 	git commit -m "new submodule" &&
 	head2=$(git rev-parse --short HEAD) &&
 	echo "From $pwd/." > expect.err.sub &&
-	echo "   $head1..$head2  master     -> origin/master" >> expect.err.sub &&
+	echo "   $head1..$head2  { -> origin/}master" >> expect.err.sub &&
 	cat expect.err >> expect.err.sub &&
 	(
 		cd downstream &&
@@ -306,14 +306,14 @@ test_expect_success "Recursion picks up all submodules when necessary" '
 		head2=$(git rev-parse --short HEAD) &&
 		echo "Fetching submodule submodule" > ../expect.err.sub &&
 		echo "From $pwd/submodule" >> ../expect.err.sub &&
-		echo "   $head1..$head2  master     -> origin/master" >> ../expect.err.sub
+		echo "   $head1..$head2  { -> origin/}master" >> ../expect.err.sub
 	) &&
 	head1=$(git rev-parse --short HEAD) &&
 	git add submodule &&
 	git commit -m "new submodule" &&
 	head2=$(git rev-parse --short HEAD) &&
 	echo "From $pwd/." > expect.err.2 &&
-	echo "   $head1..$head2  master     -> origin/master" >> expect.err.2 &&
+	echo "   $head1..$head2  { -> origin/}master" >> expect.err.2 &&
 	cat expect.err.sub >> expect.err.2 &&
 	tail -3 expect.err >> expect.err.2 &&
 	(
@@ -339,7 +339,7 @@ test_expect_success "'--recurse-submodules=on-demand' doesn't recurse when no ne
 		head2=$(git rev-parse --short HEAD) &&
 		echo Fetching submodule submodule > ../expect.err.sub &&
 		echo "From $pwd/submodule" >> ../expect.err.sub &&
-		echo "   $head1..$head2  master     -> origin/master" >> ../expect.err.sub
+		echo "   $head1..$head2  { -> origin/}master" >> ../expect.err.sub
 	) &&
 	(
 		cd downstream &&
@@ -358,7 +358,7 @@ test_expect_success "'--recurse-submodules=on-demand' recurses as deep as necess
 	head2=$(git rev-parse --short HEAD) &&
 	tail -3 expect.err > expect.err.deepsub &&
 	echo "From $pwd/." > expect.err &&
-	echo "   $head1..$head2  master     -> origin/master" >>expect.err &&
+	echo "   $head1..$head2  { -> origin/}master" >>expect.err &&
 	cat expect.err.sub >> expect.err &&
 	cat expect.err.deepsub >> expect.err &&
 	(
@@ -387,7 +387,7 @@ test_expect_success "'--recurse-submodules=on-demand' stops when no new submodul
 	git commit -m "new file" &&
 	head2=$(git rev-parse --short HEAD) &&
 	echo "From $pwd/." > expect.err.file &&
-	echo "   $head1..$head2  master     -> origin/master" >> expect.err.file &&
+	echo "   $head1..$head2  { -> origin/}master" >> expect.err.file &&
 	(
 		cd downstream &&
 		git fetch --recurse-submodules=on-demand >../actual.out 2>../actual.err
@@ -408,7 +408,7 @@ test_expect_success "'fetch.recurseSubmodules=on-demand' overrides global config
 	git commit -m "new submodule" &&
 	head2=$(git rev-parse --short HEAD) &&
 	echo "From $pwd/." > expect.err.2 &&
-	echo "   $head1..$head2  master     -> origin/master" >>expect.err.2 &&
+	echo "   $head1..$head2  { -> origin/}master" >>expect.err.2 &&
 	head -3 expect.err >> expect.err.2 &&
 	(
 		cd downstream &&
@@ -436,7 +436,7 @@ test_expect_success "'submodule.<sub>.fetchRecurseSubmodules=on-demand' override
 	git commit -m "new submodule" &&
 	head2=$(git rev-parse --short HEAD) &&
 	echo "From $pwd/." > expect.err.2 &&
-	echo "   $head1..$head2  master     -> origin/master" >>expect.err.2 &&
+	echo "   $head1..$head2  { -> origin/}master" >>expect.err.2 &&
 	head -3 expect.err >> expect.err.2 &&
 	(
 		cd downstream &&
@@ -462,7 +462,7 @@ test_expect_success "don't fetch submodule when newly recorded commits are alrea
 	git commit -m "submodule rewound" &&
 	head2=$(git rev-parse --short HEAD) &&
 	echo "From $pwd/." > expect.err &&
-	echo "   $head1..$head2  master     -> origin/master" >> expect.err &&
+	echo "   $head1..$head2  { -> origin/}master" >> expect.err &&
 	(
 		cd downstream &&
 		git fetch >../actual.out 2>../actual.err
-- 
2.8.2.524.g6ff3d78
Marc Branchaud· Jun 3, 2016, 14:53 UTC · re: Nguyễn Thái Ngọc Duy · lore

Re: [PATCH v2 3/3] fetch: reduce duplicate in ref update status lines

On 2016-06-03 07:08 AM, Nguyễn Thái Ngọc Duy wrote:
> When there are lots of ref updates, each has different name length, this
> will make it easier to look because the variable part is at the end.
s/look/read/
For the record, I prefer the earlier stair-step format to this
	{xxx -> yyy}/foo
stuff.

Peff suggested that a two-pass approach might not be too bad, but had problems when he tried it with extra-long refs. Maybe those problems could be dealt with, and we could get a simple, aligned output?

What if we detect when the full line exceeds the terminal width, and insert a newline after the remote ref and indent the -> to the same offset as its surrounding lines, like this:

  * [new branch]      2nd-index -> pclouds/2nd-index
  * [new branch]      some-kind-of-long-ref-name
                                -> pclouds/some-kind-of-long-ref-name
  * [new branch]      3nd-index -> pclouds/3nd-index
Show 20 quoted lines
> ---
>   Documentation/git-fetch.txt |  7 +++++++
>   builtin/fetch.c             | 37 ++++++++++++++++++++++++++++++++++++-
>   t/t5510-fetch.sh            |  4 ++--
>   t/t5526-fetch-submodules.sh | 26 +++++++++++++-------------
>   4 files changed, 58 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> index 18e733c..61c3bd1 100644
> --- a/Documentation/git-fetch.txt
> +++ b/Documentation/git-fetch.txt
> @@ -113,6 +113,13 @@ representing the status of a single ref. Each line is of the form:
>    <flag> <summary> <from> -> <to> (<reason>)
>   -------------------------------
>
> +When `from` and `to` share a common suffix, the line could be
> +displayed in the form:
> +
> +-------------------------------
> + <flag> <summary> {<from> -> <to>}<suffix> (<reason>)

If we go with this format, we'll need to document <suffix>. I'm not sure how to describe it succinctly, especially since it's not always used. Really there are two possible output formats:

	<flag> <summary> {<from> -> <to>}<suffix> (<reason>)
	<flag> <summary> <from> -> <to> (<reason>)
This is starting to feel too complex.
		M.
Junio C Hamano· Jun 3, 2016, 17:04 UTC · re: Marc Branchaud · lore

Re: [PATCH v2 3/3] fetch: reduce duplicate in ref update status lines

Marc Branchaud <marcnarc@xiplink.com> writes:
Show 8 quoted lines
> What if we detect when the full line exceeds the terminal width, and
> insert a newline after the remote ref and indent the ->  to the same
> offset as its surrounding lines, like this:
>
>  * [new branch]      2nd-index -> pclouds/2nd-index
>  * [new branch]      some-kind-of-long-ref-name
>                                -> pclouds/some-kind-of-long-ref-name
>  * [new branch]      3nd-index -> pclouds/3nd-index

I am OK with this format (not in the sense that I like it better than what the patch produces, but in the sense that I do not have strong preference either way). It may be hard to come up with a good heuristics to decide where on the display width "->" should come, though.

Show 7 quoted lines
>> +When `from` and `to` share a common suffix, the line could be
>> +displayed in the form:
>> +
>> +-------------------------------
>> + <flag> <summary> {<from> -> <to>}<suffix> (<reason>)
>
> If we go with this format, we'll need to document <suffix>.

The sentence above calls it "a common suffix", so instead of saying <suffix> we can say <common-suffix> perhaps? Or did you mean something more than that?

Marc Branchaud· Jun 3, 2016, 20:00 UTC · re: Junio C Hamano · lore

Re: [PATCH v2 3/3] fetch: reduce duplicate in ref update status lines

On 2016-06-03 01:04 PM, Junio C Hamano wrote:
Show 16 quoted lines
> Marc Branchaud <marcnarc@xiplink.com> writes:
>
>> What if we detect when the full line exceeds the terminal width, and
>> insert a newline after the remote ref and indent the ->  to the same
>> offset as its surrounding lines, like this:
>>
>>   * [new branch]      2nd-index -> pclouds/2nd-index
>>   * [new branch]      some-kind-of-long-ref-name
>>                                 -> pclouds/some-kind-of-long-ref-name
>>   * [new branch]      3nd-index -> pclouds/3nd-index
>
> I am OK with this format (not in the sense that I like it better
> than what the patch produces, but in the sense that I do not have
> strong preference either way).  It may be hard to come up with a
> good heuristics to decide where on the display width "->" should
> come, though.

I think aligning it with the -> on the other lines makes the most aesthetic sense.

Are you worried that the right-hand-side ref might still wrap? I'm not too concerned about that -- there'll always be the possibility of a ref name that's longer than the terminal.

Show 11 quoted lines
>>> +When `from` and `to` share a common suffix, the line could be
>>> +displayed in the form:
>>> +
>>> +-------------------------------
>>> + <flag> <summary> {<from> -> <to>}<suffix> (<reason>)
>>
>> If we go with this format, we'll need to document <suffix>.
>
> The sentence above calls it "a common suffix", so instead of saying
> <suffix> we can say <common-suffix> perhaps?  Or did you mean
> something more than that?

I missed that, and although I think it's an adequate description I think most readers will miss it too. They eye tends to notice the syntax-description bits then skip down to the list of element descriptions to understand which bits mean what. My brain wants to find "suffix" in that list.

Anyway, not a major issue, really.
		M.
Junio C Hamano· Jun 3, 2016, 20:53 UTC · re: Marc Branchaud · lore

Re: [PATCH v2 3/3] fetch: reduce duplicate in ref update status lines

Marc Branchaud <marcnarc@xiplink.com> writes:
Show 9 quoted lines
>>>   * [new branch]      2nd-index -> pclouds/2nd-index
>>>   * [new branch]      some-kind-of-long-ref-name
>>>                                 -> pclouds/some-kind-of-long-ref-name
>>>   * [new branch]      3nd-index -> pclouds/3nd-index
> ...
> I think aligning it with the -> on the other lines makes the most
> aesthetic sense.
>
> Are you worried that the right-hand-side ref might still wrap?
Not really.

Given that we reserve some fixed screen real estate on the left hand side for the sign and explanation (like [new branch]) and 4 columns in the middle for " -> ", we have around 80-25=55 columns to work with to fit "2nd-index" and such twice plus "pclouds/" once. Assuming that remote names are not overly long (say, around 10 columns), that leaves about 20-25 columns for the branch name proper.

By punting on the effort to find a readable format that does not repeat the same info twice, we are sending a signal to the users that they cannot use a meaningful sentence as the name of a branch name; they need to stay within a relatively short (i.e. 1/4 of a line width) branch name, to avoid triggering this multi-line behaviour.

The same 55 columns minus remote name, e.g. around 40 columns, could have been used to express the branch name once, if we managed to find a non-redundant format.

That is what bothers me somewhat.
Duy Nguyen· Jun 4, 2016, 03:11 UTC · re: Junio C Hamano · lore

Re: [PATCH v2 3/3] fetch: reduce duplicate in ref update status lines

On Sat, Jun 4, 2016 at 3:53 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 6 quoted lines
> By punting on the effort to find a readable format that does not
> repeat the same info twice, we are sending a signal to the users
> that they cannot use a meaningful sentence as the name of a branch
> name; they need to stay within a relatively short (i.e. 1/4 of a
> line width) branch name, to avoid triggering this multi-line
> behaviour.

This is subjective because line length (or terminal width) varies. And in the time where GUI and web interfaces are also used and preferred by some, CLI users may not be able to do much with such a signal (can't force everybody to suit you).

-- 
Duy
Duy Nguyen· Jun 4, 2016, 00:31 UTC · re: Marc Branchaud · lore

Re: [PATCH v2 3/3] fetch: reduce duplicate in ref update status lines

On Fri, Jun 03, 2016 at 10:53:27AM -0400, Marc Branchaud wrote:
Show 13 quoted lines
> On 2016-06-03 07:08 AM, Nguyễn Thái Ngọc Duy wrote:
> > When there are lots of ref updates, each has different name length, this
> > will make it easier to look because the variable part is at the end.
> 
> s/look/read/
> 
> For the record, I prefer the earlier stair-step format to this
> 	{xxx -> yyy}/foo
> stuff.
> 
> Peff suggested that a two-pass approach might not be too bad, but had 
> problems when he tried it with extra-long refs.  Maybe those problems 
> could be dealt with, and we could get a simple, aligned output?

The good thing about 2/3 is we can customize the output easily and even switch format with config variables. But let's play without config vars for now. A 3/3 replacement that adds another pass to calculate column width is at the end.

Show 8 quoted lines
> What if we detect when the full line exceeds the terminal width, and 
> insert a newline after the remote ref and indent the ->  to the same 
> offset as its surrounding lines, like this:
> 
>   * [new branch]      2nd-index -> pclouds/2nd-index
>   * [new branch]      some-kind-of-long-ref-name
>                                 -> pclouds/some-kind-of-long-ref-name
>   * [new branch]      3nd-index -> pclouds/3nd-index

The patch does not do fancy stuff like this yet, but it can because lines exceeding terminal width is already excluded from column width calculation. So far the output looks good on my terminal (192 chars, can't overflow or refnames are insanely long)

-- 8< --
Show changes to builtin/fetch.c +29 −3
diff --git a/builtin/fetch.c b/builtin/fetch.c
index a7f152a..5e1e5c9 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -15,6 +15,7 @@
 #include "submodule.h"
 #include "connected.h"
 #include "argv-array.h"
+#include "utf8.h"
 
 static const char * const builtin_fetch_usage[] = {
 	N_("git fetch [<options>] [<repository> [<refspec>...]]"),
@@ -449,14 +450,26 @@ fail:
 			   : STORE_REF_ERROR_OTHER;
 }
 
-#define REFCOL_WIDTH  10
+static int refcol_width = 10;
+
+static void adjust_refcol_width(const char *remote, const char *local)
+{
+	int max = term_columns();
+	int rlen = utf8_strwidth(remote);
+	int llen = utf8_strwidth(local);
+
+	if (21 /* flag summary */ + rlen + 4 /* => */ + llen >= max)
+		return;
+	if (refcol_width < rlen)
+		refcol_width = rlen;
+}
 
 static void format_display(struct strbuf *display, char code,
 			   const char *summary, const char *error,
 			   const char *remote, const char *local)
 {
 	strbuf_addf(display, "%c %-*s ", code, TRANSPORT_SUMMARY(summary));
-	strbuf_addf(display, "%-*s -> %s", REFCOL_WIDTH, remote, local);
+	strbuf_addf(display, "%-*s -> %s", refcol_width, remote, local);
 	if (error)
 		strbuf_addf(display, "  (%s)", error);
 }
@@ -618,6 +631,20 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
 		goto abort;
 	}
 
+	/*
+	 * go through all refs to determine column size for
+	 * "remote -> local" output
+	 */
+	for (rm = ref_map; rm; rm = rm->next) {
+		if (rm->status == REF_STATUS_REJECT_SHALLOW ||
+		    !rm->peer_ref ||
+		    !strcmp(rm->name, "HEAD"))
+			continue;
+
+		adjust_refcol_width(prettify_refname(rm->name),
+				    prettify_refname(rm->peer_ref->name));
+	}
+
 	/*
 	 * We do a pass for each fetch_head_status type in their enum order, so
 	 * merged entries are written before not-for-merge. That lets readers
-- 8< --
Junio C Hamano· Jun 4, 2016, 16:30 UTC · re: Duy Nguyen · lore

Re: [PATCH v2 3/3] fetch: reduce duplicate in ref update status lines

Duy Nguyen <pclouds@gmail.com> writes:
Show 8 quoted lines
>> Peff suggested that a two-pass approach might not be too bad, but had 
>> problems when he tried it with extra-long refs.  Maybe those problems 
>> could be dealt with, and we could get a simple, aligned output?
>
> The good thing about 2/3 is we can customize the output easily and
> even switch format with config variables. But let's play without
> config vars for now. A 3/3 replacement that adds another pass to
> calculate column width is at the end.

Yes, I agree with you that 2/3 lays a very good groundwork, regardless of the final output format.

> The patch does not do fancy stuff like this yet, but it can because
> lines exceeding terminal width is already excluded from column width
> calculation. So far the output looks good on my terminal (192 chars,
> can't overflow or refnames are insanely long)
Sounds like a sensible approach....
Show 39 quoted lines
> -- 8< --
> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index a7f152a..5e1e5c9 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -15,6 +15,7 @@
>  #include "submodule.h"
>  #include "connected.h"
>  #include "argv-array.h"
> +#include "utf8.h"
>  
>  static const char * const builtin_fetch_usage[] = {
>  	N_("git fetch [<options>] [<repository> [<refspec>...]]"),
> @@ -449,14 +450,26 @@ fail:
>  			   : STORE_REF_ERROR_OTHER;
>  }
>  
> -#define REFCOL_WIDTH  10
> +static int refcol_width = 10;
> +
> +static void adjust_refcol_width(const char *remote, const char *local)
> +{
> +	int max = term_columns();
> +	int rlen = utf8_strwidth(remote);
> +	int llen = utf8_strwidth(local);
> +
> +	if (21 /* flag summary */ + rlen + 4 /* => */ + llen >= max)
> +		return;
> +	if (refcol_width < rlen)
> +		refcol_width = rlen;
> +}
>  
>  static void format_display(struct strbuf *display, char code,
>  			   const char *summary, const char *error,
>  			   const char *remote, const char *local)
>  {
>  	strbuf_addf(display, "%c %-*s ", code, TRANSPORT_SUMMARY(summary));
> -	strbuf_addf(display, "%-*s -> %s", REFCOL_WIDTH, remote, local);
> +	strbuf_addf(display, "%-*s -> %s", refcol_width, remote, local);

... and if I understand correctly, this is the only place where you need to decide if you need to switch to two lines, right? You would measure width of the remote and compare it with refcol_width or something like that.

Show 25 quoted lines
>  	if (error)
>  		strbuf_addf(display, "  (%s)", error);
>  }
> @@ -618,6 +631,20 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
>  		goto abort;
>  	}
>  
> +	/*
> +	 * go through all refs to determine column size for
> +	 * "remote -> local" output
> +	 */
> +	for (rm = ref_map; rm; rm = rm->next) {
> +		if (rm->status == REF_STATUS_REJECT_SHALLOW ||
> +		    !rm->peer_ref ||
> +		    !strcmp(rm->name, "HEAD"))
> +			continue;
> +
> +		adjust_refcol_width(prettify_refname(rm->name),
> +				    prettify_refname(rm->peer_ref->name));
> +	}
> +
>  	/*
>  	 * We do a pass for each fetch_head_status type in their enum order, so
>  	 * merged entries are written before not-for-merge. That lets readers
> -- 8< --
Duy Nguyen· Jun 5, 2016, 03:15 UTC · re: Junio C Hamano · lore

Re: [PATCH v2 3/3] fetch: reduce duplicate in ref update status lines

On Sat, Jun 4, 2016 at 11:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 51 quoted lines
>> The patch does not do fancy stuff like this yet, but it can because
>> lines exceeding terminal width is already excluded from column width
>> calculation. So far the output looks good on my terminal (192 chars,
>> can't overflow or refnames are insanely long)
>
> Sounds like a sensible approach....
>
>> -- 8< --
>> diff --git a/builtin/fetch.c b/builtin/fetch.c
>> index a7f152a..5e1e5c9 100644
>> --- a/builtin/fetch.c
>> +++ b/builtin/fetch.c
>> @@ -15,6 +15,7 @@
>>  #include "submodule.h"
>>  #include "connected.h"
>>  #include "argv-array.h"
>> +#include "utf8.h"
>>
>>  static const char * const builtin_fetch_usage[] = {
>>       N_("git fetch [<options>] [<repository> [<refspec>...]]"),
>> @@ -449,14 +450,26 @@ fail:
>>                          : STORE_REF_ERROR_OTHER;
>>  }
>>
>> -#define REFCOL_WIDTH  10
>> +static int refcol_width = 10;
>> +
>> +static void adjust_refcol_width(const char *remote, const char *local)
>> +{
>> +     int max = term_columns();
>> +     int rlen = utf8_strwidth(remote);
>> +     int llen = utf8_strwidth(local);
>> +
>> +     if (21 /* flag summary */ + rlen + 4 /* => */ + llen >= max)
>> +             return;
>> +     if (refcol_width < rlen)
>> +             refcol_width = rlen;
>> +}
>>
>>  static void format_display(struct strbuf *display, char code,
>>                          const char *summary, const char *error,
>>                          const char *remote, const char *local)
>>  {
>>       strbuf_addf(display, "%c %-*s ", code, TRANSPORT_SUMMARY(summary));
>> -     strbuf_addf(display, "%-*s -> %s", REFCOL_WIDTH, remote, local);
>> +     strbuf_addf(display, "%-*s -> %s", refcol_width, remote, local);
>
> ... and if I understand correctly, this is the only place where you
> need to decide if you need to switch to two lines, right?  You would
> measure width of the remote and compare it with refcol_width or
> something like that.
Exactly.
-- 
Duy
Junio C Hamano· Jun 3, 2016, 17:00 UTC · re: Nguyễn Thái Ngọc Duy · lore

Re: [PATCH v2 3/3] fetch: reduce duplicate in ref update status lines

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:
Show 26 quoted lines
> +static int common_suffix_length(const char *a, const char *b)
> +{
> +	const char *pa = a + strlen(a);
> +	const char *pb = b + strlen(b);
> +	int count = 0;
> +
> +	while (pa > a && pb > b && pa[-1] == pb[-1]) {
> +		pa--;
> +		pb--;
> +		count++;
> +	}
> +
> +	/* stick to '/' boundary, do not break in the middle of a word */
> +	while (count) {
> +		if (*pa == '/' ||
> +		    (pa == a && pb > b && pb[-1] == '/') ||
> +		    (pb == b && pa > a && pa[-1] == '/'))
> +			break;
> +		pa++;
> +		pb++;
> +		count--;
> +	}
> +
> +	return count;
> +}
> +

Why do you need two loops, one going backward from the tail and then going forward toward '/'? Wouldn't it be sufficient to keep track of the last slash you saw in a while scanning backwards? I.e something along the lines of:

	tail_a = a + strlen(a);
	for (pa = tail_a, pb = b + strlen(b), slash_in_a = NULL;
             a < pa && b < pb && pa[-1] == pb[-1];
	     pa--, pb--) {
		if (*pa == '/')
			slash_in_a = pa;
	}
	count = a + strlen(a) - slash_in_a;
		
perhaps?
Show 17 quoted lines
> diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
> index 454d896..9a7649c 100755
> --- a/t/t5510-fetch.sh
> +++ b/t/t5510-fetch.sh
> @@ -222,11 +222,11 @@ test_expect_success 'fetch uses remote ref names to describe new refs' '
>  	(
>  		cd descriptive &&
>  		git fetch o 2>actual &&
> -		grep " -> refs/crazyheads/descriptive-branch$" actual |
> +		grep " -> refs/crazyheads/.descriptive-branch$" actual |
>  		test_i18ngrep "new branch" &&
>  		grep " -> descriptive-tag$" actual |
>  		test_i18ngrep "new tag" &&
> -		grep " -> crazy$" actual |
> +		grep " -> .crazy$" actual |
>  		test_i18ngrep "new ref"
>  	) &&
These are somewhat cryptic ;-)
Other than that, the patch looks OK.
Thanks.
Duy Nguyen· Jun 3, 2016, 23:49 UTC · re: Junio C Hamano · lore

Re: [PATCH v2 3/3] fetch: reduce duplicate in ref update status lines

On Sat, Jun 4, 2016 at 12:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 32 quoted lines
>
> Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:
>
> > +static int common_suffix_length(const char *a, const char *b)
> > +{
> > +     const char *pa = a + strlen(a);
> > +     const char *pb = b + strlen(b);
> > +     int count = 0;
> > +
> > +     while (pa > a && pb > b && pa[-1] == pb[-1]) {
> > +             pa--;
> > +             pb--;
> > +             count++;
> > +     }
> > +
> > +     /* stick to '/' boundary, do not break in the middle of a word */
> > +     while (count) {
> > +             if (*pa == '/' ||
> > +                 (pa == a && pb > b && pb[-1] == '/') ||
> > +                 (pb == b && pa > a && pa[-1] == '/'))
> > +                     break;
> > +             pa++;
> > +             pb++;
> > +             count--;
> > +     }
> > +
> > +     return count;
> > +}
> > +
>
> Why do you need two loops, one going backward from the tail and then
> going forward toward '/'?

I wanted to check something else, then settled for slashes, but the two loops remained.

Show 14 quoted lines
> Wouldn't it be sufficient to keep track
> of the last slash you saw in a while scanning backwards?  I.e
> something along the lines of:
>
>         tail_a = a + strlen(a);
>         for (pa = tail_a, pb = b + strlen(b), slash_in_a = NULL;
>              a < pa && b < pb && pa[-1] == pb[-1];
>              pa--, pb--) {
>                 if (*pa == '/')
>                         slash_in_a = pa;
>         }
>         count = a + strlen(a) - slash_in_a;
>
> perhaps?

Actually, Jeff's suggestion about common prefix makes me realize, why not reuse diff.c:pprint_rename()? Your {a -> b} idea came from that. We may need some tweaking there because right now it will not show { -> origin/}master.

Show 19 quoted lines
> > diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
> > index 454d896..9a7649c 100755
> > --- a/t/t5510-fetch.sh
> > +++ b/t/t5510-fetch.sh
> > @@ -222,11 +222,11 @@ test_expect_success 'fetch uses remote ref names to describe new refs' '
> >       (
> >               cd descriptive &&
> >               git fetch o 2>actual &&
> > -             grep " -> refs/crazyheads/descriptive-branch$" actual |
> > +             grep " -> refs/crazyheads/.descriptive-branch$" actual |
> >               test_i18ngrep "new branch" &&
> >               grep " -> descriptive-tag$" actual |
> >               test_i18ngrep "new tag" &&
> > -             grep " -> crazy$" actual |
> > +             grep " -> .crazy$" actual |
> >               test_i18ngrep "new ref"
> >       ) &&
>
> These are somewhat cryptic ;-)
Yeah... too lazy to check if } needs to be quoted or not :D
-- 
Duy
Jeff King· Jun 3, 2016, 17:06 UTC · re: Nguyễn Thái Ngọc Duy · lore

Re: [PATCH v2 3/3] fetch: reduce duplicate in ref update status lines

On Fri, Jun 03, 2016 at 06:08:43PM +0700, Nguyễn Thái Ngọc Duy wrote:
> When there are lots of ref updates, each has different name length, this
> will make it easier to look because the variable part is at the end.

Is it worth handling more complicated cases, where there is a similar "middle", but different beginning?

One of my common refspecs is:
  +refs/pull/*/head:refs/remotes/pull/*
That still shows as:
  refs/pull/123/head -> pull/123
but could be:
  {refs -> }/pull/123{head -> }

I actually think that _isn't_ an improvement, but I wonder if there is a format that would be.

-Peff
Duy Nguyen· Jun 3, 2016, 23:52 UTC · re: Jeff King · lore

Re: [PATCH v2 3/3] fetch: reduce duplicate in ref update status lines

On Sat, Jun 4, 2016 at 12:06 AM, Jeff King <peff@peff.net> wrote:
Show 22 quoted lines
> On Fri, Jun 03, 2016 at 06:08:43PM +0700, Nguyễn Thái Ngọc Duy wrote:
>
>> When there are lots of ref updates, each has different name length, this
>> will make it easier to look because the variable part is at the end.
>
> Is it worth handling more complicated cases, where there is a similar
> "middle", but different beginning?
>
> One of my common refspecs is:
>
>   +refs/pull/*/head:refs/remotes/pull/*
>
> That still shows as:
>
>   refs/pull/123/head -> pull/123
>
> but could be:
>
>   {refs -> }/pull/123{head -> }
>
> I actually think that _isn't_ an improvement, but I wonder if there is a
> format that would be.

A placeholder can still keep the variable part at the end, e.g. "refs/$/head -> pull/123"

-- 
Duy
Junio C Hamano· Jun 4, 2016, 04:53 UTC · re: Duy Nguyen · lore

Re: [PATCH v2 3/3] fetch: reduce duplicate in ref update status lines

On Fri, Jun 3, 2016 at 4:52 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> A placeholder can still keep the variable part at the end, e.g.
> "refs/$/head -> pull/123"
I somehow like this very much.
A more typical "their topic went to remote-tracking namespace under 'origin'",
aka
     topic -> origin/topic
aka
     { -> origin/}topic
would look like a more concise
     topic -> origin/$
without the funny {} notation.
Jeff King· Jun 3, 2016, 17:00 UTC · re: Nguyễn Thái Ngọc Duy · lore

Re: [PATCH v2 0/3] Better ref summary alignment in "git fetch"

On Fri, Jun 03, 2016 at 06:08:40PM +0700, Nguyễn Thái Ngọc Duy wrote:
Show 5 quoted lines
> v2 reformats "abc/common -> def/common" to "{abc -> def}/common"
> instead and fall back to "a -> b" when they have nothing in commmon
> (e.g. "HEAD -> FETCH_HEAD"). We could add an option if a user wants to
> stick with "a -> b" (and we could do some alignment there as well) but
> it's not part of this series.

I tried this on one of my nastiest long-branch-heavy repos. It really does look better than the status quo. I think it's nicer than the stair-stepping proposal in that it does get everything aligned perfectly, and reduces wasted data that spills off the side of my terminal.

I do somehow find the:
  { -> origin}/whatever

a little off-putting, I think because the "from" side is empty, and therefore you get this weird mix of punctuation: "{ ->". I wonder if there's another syntactic shorthand we could apply in that case (especially since it will easily be the most common), but I couldn't think of one.

> It's a shame that the flag '-' in these ref update lines is not the
> same in fetch and push (see 1/3). Because git-fetch does not support
> --porcelain option, maybe it's not too late to change its meaning...  
I'd agree with that final "maybe". :)
-Peff
Junio C Hamano· Jun 3, 2016, 17:37 UTC · re: Jeff King · lore

Re: [PATCH v2 0/3] Better ref summary alignment in "git fetch"

Jeff King <peff@peff.net> writes:
Show 5 quoted lines
>> It's a shame that the flag '-' in these ref update lines is not the
>> same in fetch and push (see 1/3). Because git-fetch does not support
>> --porcelain option, maybe it's not too late to change its meaning...  
>
> I'd agree with that final "maybe". :)

Yeah, this is purely for human consumption (which is why we see other changes in this series in the first place), no? So I'd agree with that final "maybe" too ;-).

Nguyễn Thái Ngọc Duy· Jun 5, 2016, 03:11 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v3 0/6] Better ref summary alignment in "git fetch"

This is so people can play with new output format... v3 adds one extra pass to calculate width (4/6) and swap flag code 'x' and '-' with '-' and 't' to align with push flag code (3/6). These are definitely good improvements.

5/6 and 6/6 add two new formats "{ -> origin}/abc" and "abc -> origin/$". Format output is selected by config key fetch.output. I'm tempted to replace '$' with '&' as it usually means "what was matched" in s///

I don't think we'll want both new formats in the end. One of them (or a new format) will win as the optional format. The aligned "remote -> local" should stay default format. And later on we could break lines at "->" for very long lines as Marc suggested.

Nguyễn Thái Ngọc Duy (6):
  git-fetch.txt: document fetch output
  fetch: refactor ref update status formatting code
  fetch: change flag code for displaying tag update and deleted ref
  fetch: align all "remote -> local" output
  fetch: reduce duplicate in ref update status lines with { -> }
  fetch: reduce duplicate in ref update status lines with placeholder
 Documentation/config.txt    |   4 +
 Documentation/git-fetch.txt |  54 ++++++++++
 builtin/fetch.c             | 233 ++++++++++++++++++++++++++++++++++++--------
 3 files changed, 251 insertions(+), 40 deletions(-)
-- 
2.8.2.524.g6ff3d78
Nguyễn Thái Ngọc Duy· Jun 5, 2016, 03:11 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v3 1/6] git-fetch.txt: document fetch output

This documents the ref update status of fetch. The structure of this output is defined in [1]. The ouput content is refined a bit in [2] [3] [4].

This patch is a copy from git-push.txt, modified a bit because the flag '-' means different things in push (delete) and fetch (tag update).

PS. For code archaeologists, the discussion mentioned in [1] is probably [5].

[1] 165f390 (git-fetch: more terse fetch output - 2007-11-03) [2] 6315472 (fetch: report local storage errors ... - 2008-06-26) [3] f360d84 (builtin-fetch: add --prune option - 2009-11-10) [4] 0997ada (fetch: describe new refs based on where... - 2012-04-16) [5] http://thread.gmane.org/gmane.comp.version-control.git/61657

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Documentation/git-fetch.txt | 46 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)
Show changes to Documentation/git-fetch.txt +46 −0
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index efe56e0..a0d0539 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -99,6 +99,52 @@ The latter use of the `remote.<repository>.fetch` values can be
 overridden by giving the `--refmap=<refspec>` parameter(s) on the
 command line.
 
+OUTPUT
+------
+
+The output of "git fetch" depends on the transport method used; this
+section describes the output when fetch over the Git protocol (either
+locally or via ssh).
+
+The status of the fetch is output in tabular form, with each line
+representing the status of a single ref. Each line is of the form:
+
+-------------------------------
+ <flag> <summary> <from> -> <to> (<reason>)
+-------------------------------
+
+The status of up-to-date refs is shown only if --verbose option is
+used.
+
+flag::
+	A single character indicating the status of the ref:
+(space);; for a successfully fetched fast-forward;
+`+`;; for a successful forced update;
+`x`;; for a successfully deleted ref;
+`-`;; for a successful tag update;
+`*`;; for a successfully fetched new ref;
+`!`;; for a ref that was rejected or failed to update; and
+`=`;; for a ref that was up to date and did not need fetching.
+
+summary::
+	For a successfully fetched ref, the summary shows the old and new
+	values of the ref in a form suitable for using as an argument to
+	`git log` (this is `<old>..<new>` in most cases, and
+	`<old>...<new>` for forced non-fast-forward updates).
+
+from::
+	The name of the remote ref being fetched from, minus its
+	`refs/<type>/` prefix. In the case of deletion, the name of
+	the remote ref is "(none)".
+
+to::
+	The name of the local ref being updated, minus its
+	`refs/<type>/` prefix.
+
+reason::
+	A human-readable explanation. In the case of successfully fetched
+	refs, no explanation is needed. For a failed ref, the reason for
+	failure is described.
 
 EXAMPLES
 --------
-- 
2.8.2.524.g6ff3d78
Marc Branchaud· Jun 6, 2016, 14:24 UTC · re: Nguyễn Thái Ngọc Duy · lore

Re: [PATCH v3 1/6] git-fetch.txt: document fetch output

On 2016-06-04 11:11 PM, Nguyễn Thái Ngọc Duy wrote:
Show 35 quoted lines
> This documents the ref update status of fetch. The structure of this
> output is defined in [1]. The ouput content is refined a bit in [2]
> [3] [4].
>
> This patch is a copy from git-push.txt, modified a bit because the
> flag '-' means different things in push (delete) and fetch (tag
> update).
>
> PS. For code archaeologists, the discussion mentioned in [1] is
> probably [5].
>
> [1] 165f390 (git-fetch: more terse fetch output - 2007-11-03)
> [2] 6315472 (fetch: report local storage errors ... - 2008-06-26)
> [3] f360d84 (builtin-fetch: add --prune option - 2009-11-10)
> [4] 0997ada (fetch: describe new refs based on where... - 2012-04-16)
> [5] http://thread.gmane.org/gmane.comp.version-control.git/61657
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
>   Documentation/git-fetch.txt | 46 +++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 46 insertions(+)
>
> diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> index efe56e0..a0d0539 100644
> --- a/Documentation/git-fetch.txt
> +++ b/Documentation/git-fetch.txt
> @@ -99,6 +99,52 @@ The latter use of the `remote.<repository>.fetch` values can be
>   overridden by giving the `--refmap=<refspec>` parameter(s) on the
>   command line.
>
> +OUTPUT
> +------
> +
> +The output of "git fetch" depends on the transport method used; this
> +section describes the output when fetch over the Git protocol (either
s/fetch/fetching/
Show 8 quoted lines
> +locally or via ssh).
> +
> +The status of the fetch is output in tabular form, with each line
> +representing the status of a single ref. Each line is of the form:
> +
> +-------------------------------
> + <flag> <summary> <from> -> <to> (<reason>)
> +-------------------------------

(<reason>) should really just be <reason>, as the () are part of the reason string.

> +
> +The status of up-to-date refs is shown only if --verbose option is
s/if/if the/
Also, thanks for putting so much effort into this!

I think having a fetch.output configuration setting is perfectly fine. This sort of thing is really a matter of personal taste, so having choices is good.

		M.
Nguyễn Thái Ngọc Duy· Jun 5, 2016, 03:11 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v3 2/6] fetch: refactor ref update status formatting code

This makes it easier to change the formatting later. And it makes sure translators cannot mess up format specifiers and break Git.

There are a couple call sites where the length of the second column is TRANSPORT_SUMMARY_WIDTH instead of calculated by TRANSPORT_SUMMARY(), which is enforced now. The result should be the same because these call sites do not contain characters outside ASCII range.

The two strbuf_addf() calls instead of one is mostly to reduce diff-noise in a future patch where "ref -> ref" is reformatted differently.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 builtin/fetch.c | 77 ++++++++++++++++++++++++++++-----------------------------
 1 file changed, 38 insertions(+), 39 deletions(-)
Show changes to builtin/fetch.c +38 −39
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 1582ca7..a7f152a 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -451,6 +451,16 @@ fail:
 
 #define REFCOL_WIDTH  10
 
+static void format_display(struct strbuf *display, char code,
+			   const char *summary, const char *error,
+			   const char *remote, const char *local)
+{
+	strbuf_addf(display, "%c %-*s ", code, TRANSPORT_SUMMARY(summary));
+	strbuf_addf(display, "%-*s -> %s", REFCOL_WIDTH, remote, local);
+	if (error)
+		strbuf_addf(display, "  (%s)", error);
+}
+
 static int update_local_ref(struct ref *ref,
 			    const char *remote,
 			    const struct ref *remote_ref,
@@ -467,9 +477,8 @@ static int update_local_ref(struct ref *ref,
 
 	if (!oidcmp(&ref->old_oid, &ref->new_oid)) {
 		if (verbosity > 0)
-			strbuf_addf(display, "= %-*s %-*s -> %s",
-				    TRANSPORT_SUMMARY(_("[up to date]")),
-				    REFCOL_WIDTH, remote, pretty_ref);
+			format_display(display, '=', _("[up to date]"), NULL,
+				       remote, pretty_ref);
 		return 0;
 	}
 
@@ -481,10 +490,9 @@ static int update_local_ref(struct ref *ref,
 		 * If this is the head, and it's not okay to update
 		 * the head, and the old value of the head isn't empty...
 		 */
-		strbuf_addf(display,
-			    _("! %-*s %-*s -> %s  (can't fetch in current branch)"),
-			    TRANSPORT_SUMMARY(_("[rejected]")),
-			    REFCOL_WIDTH, remote, pretty_ref);
+		format_display(display, '!', _("[rejected]"),
+			       _("can't fetch in current branch"),
+			       remote, pretty_ref);
 		return 1;
 	}
 
@@ -492,11 +500,9 @@ static int update_local_ref(struct ref *ref,
 	    starts_with(ref->name, "refs/tags/")) {
 		int r;
 		r = s_update_ref("updating tag", ref, 0);
-		strbuf_addf(display, "%c %-*s %-*s -> %s%s",
-			    r ? '!' : '-',
-			    TRANSPORT_SUMMARY(_("[tag update]")),
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    r ? _("  (unable to update local ref)") : "");
+		format_display(display, r ? '!' : '-', _("[tag update]"),
+			       r ? _("unable to update local ref") : NULL,
+			       remote, pretty_ref);
 		return r;
 	}
 
@@ -527,11 +533,9 @@ static int update_local_ref(struct ref *ref,
 		    (recurse_submodules != RECURSE_SUBMODULES_ON))
 			check_for_new_submodule_commits(ref->new_oid.hash);
 		r = s_update_ref(msg, ref, 0);
-		strbuf_addf(display, "%c %-*s %-*s -> %s%s",
-			    r ? '!' : '*',
-			    TRANSPORT_SUMMARY(what),
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    r ? _("  (unable to update local ref)") : "");
+		format_display(display, r ? '!' : '*', what,
+			       r ? _("unable to update local ref") : NULL,
+			       remote, pretty_ref);
 		return r;
 	}
 
@@ -545,11 +549,9 @@ static int update_local_ref(struct ref *ref,
 		    (recurse_submodules != RECURSE_SUBMODULES_ON))
 			check_for_new_submodule_commits(ref->new_oid.hash);
 		r = s_update_ref("fast-forward", ref, 1);
-		strbuf_addf(display, "%c %-*s %-*s -> %s%s",
-			    r ? '!' : ' ',
-			    TRANSPORT_SUMMARY_WIDTH, quickref.buf,
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    r ? _("  (unable to update local ref)") : "");
+		format_display(display, r ? '!' : ' ', quickref.buf,
+			       r ? _("unable to update local ref") : NULL,
+			       remote, pretty_ref);
 		strbuf_release(&quickref);
 		return r;
 	} else if (force || ref->force) {
@@ -562,18 +564,14 @@ static int update_local_ref(struct ref *ref,
 		    (recurse_submodules != RECURSE_SUBMODULES_ON))
 			check_for_new_submodule_commits(ref->new_oid.hash);
 		r = s_update_ref("forced-update", ref, 1);
-		strbuf_addf(display, "%c %-*s %-*s -> %s  (%s)",
-			    r ? '!' : '+',
-			    TRANSPORT_SUMMARY_WIDTH, quickref.buf,
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    r ? _("unable to update local ref") : _("forced update"));
+		format_display(display, r ? '!' : '+', quickref.buf,
+			       r ? _("unable to update local ref") : _("forced update"),
+			       remote, pretty_ref);
 		strbuf_release(&quickref);
 		return r;
 	} else {
-		strbuf_addf(display, "! %-*s %-*s -> %s  %s",
-			    TRANSPORT_SUMMARY(_("[rejected]")),
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    _("(non-fast-forward)"));
+		format_display(display, '!', _("[rejected]"), _("non-fast-forward"),
+			       remote, pretty_ref);
 		return 1;
 	}
 }
@@ -714,11 +712,10 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
 				rc |= update_local_ref(ref, what, rm, &note);
 				free(ref);
 			} else
-				strbuf_addf(&note, "* %-*s %-*s -> FETCH_HEAD",
-					    TRANSPORT_SUMMARY_WIDTH,
-					    *kind ? kind : "branch",
-					    REFCOL_WIDTH,
-					    *what ? what : "HEAD");
+				format_display(&note, '*',
+					       *kind ? kind : "branch", NULL,
+					       *what ? what : "HEAD",
+					       "FETCH_HEAD");
 			if (note.len) {
 				if (verbosity >= 0 && !shown_url) {
 					fprintf(stderr, _("From %.*s\n"),
@@ -812,13 +809,15 @@ static int prune_refs(struct refspec *refs, int ref_count, struct ref *ref_map,
 
 	if (verbosity >= 0) {
 		for (ref = stale_refs; ref; ref = ref->next) {
+			struct strbuf sb = STRBUF_INIT;
 			if (!shown_url) {
 				fprintf(stderr, _("From %.*s\n"), url_len, url);
 				shown_url = 1;
 			}
-			fprintf(stderr, " x %-*s %-*s -> %s\n",
-				TRANSPORT_SUMMARY(_("[deleted]")),
-				REFCOL_WIDTH, _("(none)"), prettify_refname(ref->name));
+			format_display(&sb, 'x', _("[deleted]"), NULL,
+				       _("(none)"), prettify_refname(ref->name));
+			fprintf(stderr, " %s\n",sb.buf);
+			strbuf_release(&sb);
 			warn_dangling_symref(stderr, dangling_msg, ref->name);
 		}
 	}
-- 
2.8.2.524.g6ff3d78
Nguyễn Thái Ngọc Duy· Jun 5, 2016, 03:11 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v3 3/6] fetch: change flag code for displaying tag update and deleted ref

This makes the fetch flag code consistent with push, where '-' means deleted ref.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Documentation/git-fetch.txt | 4 ++--
 builtin/fetch.c             | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)
Show changes to 2 files +4 −4

Documentation/git-fetch.txt, builtin/fetch.c

diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index a0d0539..6c6b2c1 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -120,8 +120,8 @@ flag::
 	A single character indicating the status of the ref:
 (space);; for a successfully fetched fast-forward;
 `+`;; for a successful forced update;
-`x`;; for a successfully deleted ref;
-`-`;; for a successful tag update;
+`-`;; for a successfully deleted ref;
+`t`;; for a successful tag update;
 `*`;; for a successfully fetched new ref;
 `!`;; for a ref that was rejected or failed to update; and
 `=`;; for a ref that was up to date and did not need fetching.
diff --git a/builtin/fetch.c b/builtin/fetch.c
index a7f152a..8177f90 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -500,7 +500,7 @@ static int update_local_ref(struct ref *ref,
 	    starts_with(ref->name, "refs/tags/")) {
 		int r;
 		r = s_update_ref("updating tag", ref, 0);
-		format_display(display, r ? '!' : '-', _("[tag update]"),
+		format_display(display, r ? '!' : 't', _("[tag update]"),
 			       r ? _("unable to update local ref") : NULL,
 			       remote, pretty_ref);
 		return r;
@@ -814,7 +814,7 @@ static int prune_refs(struct refspec *refs, int ref_count, struct ref *ref_map,
 				fprintf(stderr, _("From %.*s\n"), url_len, url);
 				shown_url = 1;
 			}
-			format_display(&sb, 'x', _("[deleted]"), NULL,
+			format_display(&sb, '-', _("[deleted]"), NULL,
 				       _("(none)"), prettify_refname(ref->name));
 			fprintf(stderr, " %s\n",sb.buf);
 			strbuf_release(&sb);
-- 
2.8.2.524.g6ff3d78
Nguyễn Thái Ngọc Duy· Jun 5, 2016, 03:11 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v3 4/6] fetch: align all "remote -> local" output

We do align "remote -> local" output by allocating 10 columns to "remote". That produces aligned output only for short refs. An extra pass is performed to find the longest remote ref name (that does not produce a line longer than terminal width) to produce better aligned output.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 builtin/fetch.c | 46 ++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 44 insertions(+), 2 deletions(-)
Show changes to builtin/fetch.c +44 −2
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 8177f90..c42795b 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -15,6 +15,7 @@
 #include "submodule.h"
 #include "connected.h"
 #include "argv-array.h"
+#include "utf8.h"
 
 static const char * const builtin_fetch_usage[] = {
 	N_("git fetch [<options>] [<repository> [<refspec>...]]"),
@@ -449,14 +450,53 @@ fail:
 			   : STORE_REF_ERROR_OTHER;
 }
 
-#define REFCOL_WIDTH  10
+static int refcol_width = 10;
+
+static void adjust_refcol_width(const struct ref *ref)
+{
+	int max, rlen, llen;
+
+	/* uptodate lines are only shown on high verbosity level */
+	if (!verbosity && !oidcmp(&ref->peer_ref->old_oid, &ref->old_oid))
+		return;
+
+	max    = term_columns();
+	rlen   = utf8_strwidth(prettify_refname(ref->name));
+	llen   = utf8_strwidth(prettify_refname(ref->peer_ref->name));
+
+	/*
+	 * rough estimation to see if the output line is too long and
+	 * should not be counted (we can't do precise calculation
+	 * anyway because we don't know if the error explanation part
+	 * will be printed in update_local_ref)
+	 */
+	if (21 /* flag and summary */ + rlen + 4 /* -> */ + llen >= max)
+		return;
+
+	if (refcol_width < rlen)
+		refcol_width = rlen;
+}
+
+static void prepare_format_display(struct ref *ref_map)
+{
+	struct ref *rm;
+
+	for (rm = ref_map; rm; rm = rm->next) {
+		if (rm->status == REF_STATUS_REJECT_SHALLOW ||
+		    !rm->peer_ref ||
+		    !strcmp(rm->name, "HEAD"))
+			continue;
+
+		adjust_refcol_width(rm);
+	}
+}
 
 static void format_display(struct strbuf *display, char code,
 			   const char *summary, const char *error,
 			   const char *remote, const char *local)
 {
 	strbuf_addf(display, "%c %-*s ", code, TRANSPORT_SUMMARY(summary));
-	strbuf_addf(display, "%-*s -> %s", REFCOL_WIDTH, remote, local);
+	strbuf_addf(display, "%-*s -> %s", refcol_width, remote, local);
 	if (error)
 		strbuf_addf(display, "  (%s)", error);
 }
@@ -618,6 +658,8 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
 		goto abort;
 	}
 
+	prepare_format_display(ref_map);
+
 	/*
 	 * We do a pass for each fetch_head_status type in their enum order, so
 	 * merged entries are written before not-for-merge. That lets readers
-- 
2.8.2.524.g6ff3d78
Nguyễn Thái Ngọc Duy· Jun 5, 2016, 03:11 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v3 5/6] fetch: reduce duplicate in ref update status lines with { -> }

Most of the time, ref update lines are
    variable-long-name -> fixed-remote/variable-long-name
With fetch.output set to "compact" such a line will be shown as
    { -> fixed-remote}/variable-long-name

This keeps the output aligned (because the variable part is always at the end) and reduce duplication.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Documentation/config.txt    |  4 +++
 Documentation/git-fetch.txt |  8 ++++++
 builtin/fetch.c             | 67 ++++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 78 insertions(+), 1 deletion(-)
Show changes to 3 files +78 −1

Documentation/config.txt, Documentation/git-fetch.txt, builtin/fetch.c

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2e1b2e4..a59aa32 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1220,6 +1220,10 @@ fetch.prune::
 	If true, fetch will automatically behave as if the `--prune`
 	option was given on the command line.  See also `remote.<name>.prune`.
 
+fetch.output::
+	Valid values are "compact" or "full". See OUTPUT section in
+	linkgit:git-fetch[1] for detail.
+
 format.attach::
 	Enable multipart/mixed attachments as the default for
 	'format-patch'.  The value can also be a double quoted string
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 6c6b2c1..856796b 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -113,6 +113,14 @@ representing the status of a single ref. Each line is of the form:
  <flag> <summary> <from> -> <to> (<reason>)
 -------------------------------
 
+When configuration variable `fetch.output` contains `compact` and
+`from` and `to` share a common suffix, the line could be displayed in
+the form:
+
+-------------------------------
+ <flag> <summary> {<from> -> <to>}<common-suffix> (<reason>)
+-------------------------------
+
 The status of up-to-date refs is shown only if --verbose option is
 used.
 
diff --git a/builtin/fetch.c b/builtin/fetch.c
index c42795b..e2ca6bc 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -451,6 +451,7 @@ fail:
 }
 
 static int refcol_width = 10;
+static int compact_format;
 
 static void adjust_refcol_width(const struct ref *ref)
 {
@@ -480,6 +481,19 @@ static void adjust_refcol_width(const struct ref *ref)
 static void prepare_format_display(struct ref *ref_map)
 {
 	struct ref *rm;
+	const char *format = "full";
+
+	git_config_get_string_const("fetch.output", &format);
+	if (!strcasecmp(format, "full"))
+		compact_format = 0;
+	else if (!strcasecmp(format, "compact"))
+		compact_format = 1;
+	else
+		die(_("configuration fetch.output contains invalid value %s"),
+		    format);
+
+	if (compact_format)
+		return;
 
 	for (rm = ref_map; rm; rm = rm->next) {
 		if (rm->status == REF_STATUS_REJECT_SHALLOW ||
@@ -491,12 +505,63 @@ static void prepare_format_display(struct ref *ref_map)
 	}
 }
 
+static int common_suffix_length(const char *a, const char *b)
+{
+	const char *pa = a + strlen(a);
+	const char *pb = b + strlen(b);
+	int count = 0, final_count = 0;
+
+	while (pa > a && pb > b && pa[-1] == pb[-1]) {
+		pa--;
+		pb--;
+		count++;
+		if (*pa == '/' ||
+		    /*
+		     * if a and b are "abc" and "origin/abc" respectively,
+		     * accept "a" as the suffix boundary too.
+		     */
+		    (pa == a && pb > b && pb[-1] == '/') ||
+		    (pb == b && pa > a && pa[-1] == '/'))
+			final_count = count;
+	}
+
+	return final_count;
+}
+
+static void print_remote_to_local(struct strbuf *display,
+				  const char *remote, const char *local)
+{
+	strbuf_addf(display, "%-*s -> %s", refcol_width, remote, local);
+}
+
+static void print_compact(struct strbuf *display,
+			  const char *remote, const char *local)
+{
+	int len = common_suffix_length(remote, local);
+
+	if (len) {
+		strbuf_addf(display, "{%.*s -> %.*s}%s",
+			    (int)strlen(remote) - len, remote,
+			    (int)strlen(local) - len, local,
+			    remote + strlen(remote) - len);
+		return;
+	}
+	print_remote_to_local(display, remote, local);
+}
+
 static void format_display(struct strbuf *display, char code,
 			   const char *summary, const char *error,
 			   const char *remote, const char *local)
 {
 	strbuf_addf(display, "%c %-*s ", code, TRANSPORT_SUMMARY(summary));
-	strbuf_addf(display, "%-*s -> %s", refcol_width, remote, local);
+	switch (compact_format) {
+	case 0:
+		print_remote_to_local(display, remote, local);
+		break;
+	case 1:
+		print_compact(display, remote, local);
+		break;
+	}
 	if (error)
 		strbuf_addf(display, "  (%s)", error);
 }
-- 
2.8.2.524.g6ff3d78
Nguyễn Thái Ngọc Duy· Jun 5, 2016, 03:11 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v3 6/6] fetch: reduce duplicate in ref update status lines with placeholder

In the "remote -> local" line, if either ref is a substring of the other, the common part in the other string is replaced with "$". For example

    abc                -> origin/abc
    refs/pull/123/head -> pull/123
become
    abc         -> origin/$
    refs/$/head -> pull/123
Activated with fetch.format=dollar.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 builtin/fetch.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 48 insertions(+), 1 deletion(-)
Show changes to builtin/fetch.c +48 −1
diff --git a/builtin/fetch.c b/builtin/fetch.c
index e2ca6bc..c63f913 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -488,11 +488,13 @@ static void prepare_format_display(struct ref *ref_map)
 		compact_format = 0;
 	else if (!strcasecmp(format, "compact"))
 		compact_format = 1;
+	else if (!strcasecmp(format, "dollar"))
+		compact_format = 2;
 	else
 		die(_("configuration fetch.output contains invalid value %s"),
 		    format);
 
-	if (compact_format)
+	if (compact_format == 1)
 		return;
 
 	for (rm = ref_map; rm; rm = rm->next) {
@@ -549,6 +551,48 @@ static void print_compact(struct strbuf *display,
 	print_remote_to_local(display, remote, local);
 }
 
+static int dollarize(struct strbuf *haystack, const char *needle)
+{
+	const char *p = strstr(haystack->buf, needle);
+	int plen, nlen;
+
+	if (!p)
+		return 0;
+
+	if (p > haystack->buf && p[-1] != '/')
+		return 0;
+
+	plen = strlen(p);
+	nlen = strlen(needle);
+	if (plen > nlen && p[nlen] != '/')
+		return 0;
+
+	strbuf_splice(haystack, p - haystack->buf, nlen, "$", 1);
+	return 1;
+}
+
+static void print_dollar(struct strbuf *display,
+			 const char *remote, const char *local)
+{
+	struct strbuf r = STRBUF_INIT;
+	struct strbuf l = STRBUF_INIT;
+
+	if (!strcmp(remote, local)) {
+		strbuf_addf(display, "%s -> $", remote);
+		return;
+	}
+
+	strbuf_addstr(&r, remote);
+	strbuf_addstr(&l, local);
+
+	if (!dollarize(&r, local))
+		dollarize(&l, remote);
+	print_remote_to_local(display, r.buf, l.buf);
+
+	strbuf_release(&r);
+	strbuf_release(&l);
+}
+
 static void format_display(struct strbuf *display, char code,
 			   const char *summary, const char *error,
 			   const char *remote, const char *local)
@@ -561,6 +605,9 @@ static void format_display(struct strbuf *display, char code,
 	case 1:
 		print_compact(display, remote, local);
 		break;
+	case 2:
+		print_dollar(display, remote, local);
+		break;
 	}
 	if (error)
 		strbuf_addf(display, "  (%s)", error);
-- 
2.8.2.524.g6ff3d78
Nguyễn Thái Ngọc Duy· Jun 26, 2016, 05:58 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v4 0/5] Better ref summary alignment in "git fetch"

v4 is a cleaned up version of v3. Tests are added. Typos in git-fetch.txt are corrected. The "{ -> origin/}master" format is dropped.

Nguyễn Thái Ngọc Duy (5):
  git-fetch.txt: document fetch output
  fetch: refactor ref update status formatting code
  fetch: change flag code for displaying tag update and deleted ref
  fetch: align all "remote -> local" output
  fetch: reduce duplicate in ref update status lines with placeholder
 Documentation/config.txt    |   5 ++
 Documentation/git-fetch.txt |  51 ++++++++++++
 builtin/fetch.c             | 194 +++++++++++++++++++++++++++++++++++---------
 t/t5510-fetch.sh            |  30 +++++++
 4 files changed, 240 insertions(+), 40 deletions(-)
-- 
2.8.2.526.g02eed6d
Nguyễn Thái Ngọc Duy· Jun 26, 2016, 05:58 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v4 1/5] git-fetch.txt: document fetch output

This documents the ref update status of fetch. The structure of this output is defined in [1]. The ouput content is refined a bit in [2] [3] [4].

This patch is a copy from git-push.txt, modified a bit because the flag '-' means different things in push (delete) and fetch (tag update).

PS. For code archaeologists, the discussion mentioned in [1] is probably [5].

[1] 165f390 (git-fetch: more terse fetch output - 2007-11-03) [2] 6315472 (fetch: report local storage errors ... - 2008-06-26) [3] f360d84 (builtin-fetch: add --prune option - 2009-11-10) [4] 0997ada (fetch: describe new refs based on where... - 2012-04-16) [5] http://thread.gmane.org/gmane.comp.version-control.git/61657

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Documentation/git-fetch.txt | 46 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)
Show changes to Documentation/git-fetch.txt +46 −0
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index efe56e0..cbf441f 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -99,6 +99,52 @@ The latter use of the `remote.<repository>.fetch` values can be
 overridden by giving the `--refmap=<refspec>` parameter(s) on the
 command line.
 
+OUTPUT
+------
+
+The output of "git fetch" depends on the transport method used; this
+section describes the output when fetching over the Git protocol
+(either locally or via ssh) and Smart HTTP protocol.
+
+The status of the fetch is output in tabular form, with each line
+representing the status of a single ref. Each line is of the form:
+
+-------------------------------
+ <flag> <summary> <from> -> <to> [<reason>]
+-------------------------------
+
+The status of up-to-date refs is shown only if the --verbose option is
+used.
+
+flag::
+	A single character indicating the status of the ref:
+(space);; for a successfully fetched fast-forward;
+`+`;; for a successful forced update;
+`x`;; for a successfully pruned ref;
+`-`;; for a successful tag update;
+`*`;; for a successfully fetched new ref;
+`!`;; for a ref that was rejected or failed to update; and
+`=`;; for a ref that was up to date and did not need fetching.
+
+summary::
+	For a successfully fetched ref, the summary shows the old and new
+	values of the ref in a form suitable for using as an argument to
+	`git log` (this is `<old>..<new>` in most cases, and
+	`<old>...<new>` for forced non-fast-forward updates).
+
+from::
+	The name of the remote ref being fetched from, minus its
+	`refs/<type>/` prefix. In the case of deletion, the name of
+	the remote ref is "(none)".
+
+to::
+	The name of the local ref being updated, minus its
+	`refs/<type>/` prefix.
+
+reason::
+	A human-readable explanation. In the case of successfully fetched
+	refs, no explanation is needed. For a failed ref, the reason for
+	failure is described.
 
 EXAMPLES
 --------
-- 
2.8.2.526.g02eed6d
Jakub Narębski· Jul 4, 2016, 14:07 UTC · re: Nguyễn Thái Ngọc Duy · lore

Re: [PATCH v4 1/5] git-fetch.txt: document fetch output

W dniu 2016-06-26 o 07:58, Nguyễn Thái Ngọc Duy pisze:
Show 5 quoted lines
> +summary::
> +	For a successfully fetched ref, the summary shows the old and new
> +	values of the ref in a form suitable for using as an argument to
> +	`git log` (this is `<old>..<new>` in most cases, and
> +	`<old>...<new>` for forced non-fast-forward updates).

It would be nice to have documented here also other <summary> formats, like "[new branch]", and/or mention that if the <summary> is not usable for `git log` it is put in brackets [].

-- 
Jakub Narębski 
Duy Nguyen· Jul 4, 2016, 15:17 UTC · re: Jakub Narębski · lore

Re: [PATCH v4 1/5] git-fetch.txt: document fetch output

On Mon, Jul 4, 2016 at 4:07 PM, Jakub Narębski <jnareb@gmail.com> wrote:
Show 10 quoted lines
> W dniu 2016-06-26 o 07:58, Nguyễn Thái Ngọc Duy pisze:
>> +summary::
>> +     For a successfully fetched ref, the summary shows the old and new
>> +     values of the ref in a form suitable for using as an argument to
>> +     `git log` (this is `<old>..<new>` in most cases, and
>> +     `<old>...<new>` for forced non-fast-forward updates).
>
> It would be nice to have documented here also other <summary> formats,
> like "[new branch]", and/or mention that if the <summary> is not usable
> for `git log` it is put in brackets [].

Can I do it in a separate topic in future? We may want to unify this and the output format in git-pull as well, then include fetch format in git-pull.

-- 
Duy
Jakub Narębski· Jul 4, 2016, 15:25 UTC · re: Duy Nguyen · lore

Re: [PATCH v4 1/5] git-fetch.txt: document fetch output

W dniu 2016-07-04 o 17:17, Duy Nguyen pisze:
Show 15 quoted lines
> On Mon, Jul 4, 2016 at 4:07 PM, Jakub Narębski <jnareb@gmail.com> wrote:
>> W dniu 2016-06-26 o 07:58, Nguyễn Thái Ngọc Duy pisze:
>>> +summary::
>>> +     For a successfully fetched ref, the summary shows the old and new
>>> +     values of the ref in a form suitable for using as an argument to
>>> +     `git log` (this is `<old>..<new>` in most cases, and
>>> +     `<old>...<new>` for forced non-fast-forward updates).
>>
>> It would be nice to have documented here also other <summary> formats,
>> like "[new branch]", and/or mention that if the <summary> is not usable
>> for `git log` it is put in brackets [].
> 
> Can I do it in a separate topic in future? We may want to unify this
> and the output format in git-pull as well, then include fetch format
> in git-pull.

Yes, of course it can be added later. Though it feels strange for docs to talk about <old>..<new> and <old>...<new> format only (note that it is also suitable for copy'n'paste to `git diff`, not only for `git log`) while having "[new branch]" in examples / later patches.

-- 
Jakub Narębski
Duy Nguyen· Jul 4, 2016, 15:52 UTC · re: Jakub Narębski · lore

Re: [PATCH v4 1/5] git-fetch.txt: document fetch output

On Mon, Jul 4, 2016 at 5:25 PM, Jakub Narębski <jnareb@gmail.com> wrote:
Show 21 quoted lines
> W dniu 2016-07-04 o 17:17, Duy Nguyen pisze:
>> On Mon, Jul 4, 2016 at 4:07 PM, Jakub Narębski <jnareb@gmail.com> wrote:
>>> W dniu 2016-06-26 o 07:58, Nguyễn Thái Ngọc Duy pisze:
>>>> +summary::
>>>> +     For a successfully fetched ref, the summary shows the old and new
>>>> +     values of the ref in a form suitable for using as an argument to
>>>> +     `git log` (this is `<old>..<new>` in most cases, and
>>>> +     `<old>...<new>` for forced non-fast-forward updates).
>>>
>>> It would be nice to have documented here also other <summary> formats,
>>> like "[new branch]", and/or mention that if the <summary> is not usable
>>> for `git log` it is put in brackets [].
>>
>> Can I do it in a separate topic in future? We may want to unify this
>> and the output format in git-pull as well, then include fetch format
>> in git-pull.
>
> Yes, of course it can be added later.  Though it feels strange for docs
> to talk about <old>..<new> and <old>...<new> format only (note that it
> is also suitable for copy'n'paste to `git diff`, not only for `git log`)
> while having "[new branch]" in examples / later patches.

It's because it's copied from git-push.txt and not all [<explaination>] are listed there either :) But I think you have convinced me I should do it now.

-- 
Duy
Nguyễn Thái Ngọc Duy· Jun 26, 2016, 05:58 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v4 2/5] fetch: refactor ref update status formatting code

This makes it easier to change the formatting later. And it makes sure translators cannot mess up format specifiers and break Git.

There are a couple call sites where the length of the second column is TRANSPORT_SUMMARY_WIDTH instead of calculated by TRANSPORT_SUMMARY(), which is enforced now. The result should be the same because these call sites do not contain characters outside ASCII range.

The two strbuf_addf() calls instead of one is mostly to reduce diff-noise in a future patch where "ref -> ref" is reformatted differently.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 builtin/fetch.c | 77 ++++++++++++++++++++++++++++-----------------------------
 1 file changed, 38 insertions(+), 39 deletions(-)
Show changes to builtin/fetch.c +38 −39
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 1582ca7..a7f152a 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -451,6 +451,16 @@ fail:
 
 #define REFCOL_WIDTH  10
 
+static void format_display(struct strbuf *display, char code,
+			   const char *summary, const char *error,
+			   const char *remote, const char *local)
+{
+	strbuf_addf(display, "%c %-*s ", code, TRANSPORT_SUMMARY(summary));
+	strbuf_addf(display, "%-*s -> %s", REFCOL_WIDTH, remote, local);
+	if (error)
+		strbuf_addf(display, "  (%s)", error);
+}
+
 static int update_local_ref(struct ref *ref,
 			    const char *remote,
 			    const struct ref *remote_ref,
@@ -467,9 +477,8 @@ static int update_local_ref(struct ref *ref,
 
 	if (!oidcmp(&ref->old_oid, &ref->new_oid)) {
 		if (verbosity > 0)
-			strbuf_addf(display, "= %-*s %-*s -> %s",
-				    TRANSPORT_SUMMARY(_("[up to date]")),
-				    REFCOL_WIDTH, remote, pretty_ref);
+			format_display(display, '=', _("[up to date]"), NULL,
+				       remote, pretty_ref);
 		return 0;
 	}
 
@@ -481,10 +490,9 @@ static int update_local_ref(struct ref *ref,
 		 * If this is the head, and it's not okay to update
 		 * the head, and the old value of the head isn't empty...
 		 */
-		strbuf_addf(display,
-			    _("! %-*s %-*s -> %s  (can't fetch in current branch)"),
-			    TRANSPORT_SUMMARY(_("[rejected]")),
-			    REFCOL_WIDTH, remote, pretty_ref);
+		format_display(display, '!', _("[rejected]"),
+			       _("can't fetch in current branch"),
+			       remote, pretty_ref);
 		return 1;
 	}
 
@@ -492,11 +500,9 @@ static int update_local_ref(struct ref *ref,
 	    starts_with(ref->name, "refs/tags/")) {
 		int r;
 		r = s_update_ref("updating tag", ref, 0);
-		strbuf_addf(display, "%c %-*s %-*s -> %s%s",
-			    r ? '!' : '-',
-			    TRANSPORT_SUMMARY(_("[tag update]")),
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    r ? _("  (unable to update local ref)") : "");
+		format_display(display, r ? '!' : '-', _("[tag update]"),
+			       r ? _("unable to update local ref") : NULL,
+			       remote, pretty_ref);
 		return r;
 	}
 
@@ -527,11 +533,9 @@ static int update_local_ref(struct ref *ref,
 		    (recurse_submodules != RECURSE_SUBMODULES_ON))
 			check_for_new_submodule_commits(ref->new_oid.hash);
 		r = s_update_ref(msg, ref, 0);
-		strbuf_addf(display, "%c %-*s %-*s -> %s%s",
-			    r ? '!' : '*',
-			    TRANSPORT_SUMMARY(what),
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    r ? _("  (unable to update local ref)") : "");
+		format_display(display, r ? '!' : '*', what,
+			       r ? _("unable to update local ref") : NULL,
+			       remote, pretty_ref);
 		return r;
 	}
 
@@ -545,11 +549,9 @@ static int update_local_ref(struct ref *ref,
 		    (recurse_submodules != RECURSE_SUBMODULES_ON))
 			check_for_new_submodule_commits(ref->new_oid.hash);
 		r = s_update_ref("fast-forward", ref, 1);
-		strbuf_addf(display, "%c %-*s %-*s -> %s%s",
-			    r ? '!' : ' ',
-			    TRANSPORT_SUMMARY_WIDTH, quickref.buf,
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    r ? _("  (unable to update local ref)") : "");
+		format_display(display, r ? '!' : ' ', quickref.buf,
+			       r ? _("unable to update local ref") : NULL,
+			       remote, pretty_ref);
 		strbuf_release(&quickref);
 		return r;
 	} else if (force || ref->force) {
@@ -562,18 +564,14 @@ static int update_local_ref(struct ref *ref,
 		    (recurse_submodules != RECURSE_SUBMODULES_ON))
 			check_for_new_submodule_commits(ref->new_oid.hash);
 		r = s_update_ref("forced-update", ref, 1);
-		strbuf_addf(display, "%c %-*s %-*s -> %s  (%s)",
-			    r ? '!' : '+',
-			    TRANSPORT_SUMMARY_WIDTH, quickref.buf,
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    r ? _("unable to update local ref") : _("forced update"));
+		format_display(display, r ? '!' : '+', quickref.buf,
+			       r ? _("unable to update local ref") : _("forced update"),
+			       remote, pretty_ref);
 		strbuf_release(&quickref);
 		return r;
 	} else {
-		strbuf_addf(display, "! %-*s %-*s -> %s  %s",
-			    TRANSPORT_SUMMARY(_("[rejected]")),
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    _("(non-fast-forward)"));
+		format_display(display, '!', _("[rejected]"), _("non-fast-forward"),
+			       remote, pretty_ref);
 		return 1;
 	}
 }
@@ -714,11 +712,10 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
 				rc |= update_local_ref(ref, what, rm, &note);
 				free(ref);
 			} else
-				strbuf_addf(&note, "* %-*s %-*s -> FETCH_HEAD",
-					    TRANSPORT_SUMMARY_WIDTH,
-					    *kind ? kind : "branch",
-					    REFCOL_WIDTH,
-					    *what ? what : "HEAD");
+				format_display(&note, '*',
+					       *kind ? kind : "branch", NULL,
+					       *what ? what : "HEAD",
+					       "FETCH_HEAD");
 			if (note.len) {
 				if (verbosity >= 0 && !shown_url) {
 					fprintf(stderr, _("From %.*s\n"),
@@ -812,13 +809,15 @@ static int prune_refs(struct refspec *refs, int ref_count, struct ref *ref_map,
 
 	if (verbosity >= 0) {
 		for (ref = stale_refs; ref; ref = ref->next) {
+			struct strbuf sb = STRBUF_INIT;
 			if (!shown_url) {
 				fprintf(stderr, _("From %.*s\n"), url_len, url);
 				shown_url = 1;
 			}
-			fprintf(stderr, " x %-*s %-*s -> %s\n",
-				TRANSPORT_SUMMARY(_("[deleted]")),
-				REFCOL_WIDTH, _("(none)"), prettify_refname(ref->name));
+			format_display(&sb, 'x', _("[deleted]"), NULL,
+				       _("(none)"), prettify_refname(ref->name));
+			fprintf(stderr, " %s\n",sb.buf);
+			strbuf_release(&sb);
 			warn_dangling_symref(stderr, dangling_msg, ref->name);
 		}
 	}
-- 
2.8.2.526.g02eed6d
Nguyễn Thái Ngọc Duy· Jun 26, 2016, 05:58 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v4 3/5] fetch: change flag code for displaying tag update and deleted ref

This makes the fetch flag code consistent with push, where '-' means deleted ref.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Documentation/git-fetch.txt | 4 ++--
 builtin/fetch.c             | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)
Show changes to 2 files +4 −4

Documentation/git-fetch.txt, builtin/fetch.c

diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index cbf441f..771dde5 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -120,8 +120,8 @@ flag::
 	A single character indicating the status of the ref:
 (space);; for a successfully fetched fast-forward;
 `+`;; for a successful forced update;
-`x`;; for a successfully pruned ref;
-`-`;; for a successful tag update;
+`-`;; for a successfully pruned ref;
+`t`;; for a successful tag update;
 `*`;; for a successfully fetched new ref;
 `!`;; for a ref that was rejected or failed to update; and
 `=`;; for a ref that was up to date and did not need fetching.
diff --git a/builtin/fetch.c b/builtin/fetch.c
index a7f152a..8177f90 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -500,7 +500,7 @@ static int update_local_ref(struct ref *ref,
 	    starts_with(ref->name, "refs/tags/")) {
 		int r;
 		r = s_update_ref("updating tag", ref, 0);
-		format_display(display, r ? '!' : '-', _("[tag update]"),
+		format_display(display, r ? '!' : 't', _("[tag update]"),
 			       r ? _("unable to update local ref") : NULL,
 			       remote, pretty_ref);
 		return r;
@@ -814,7 +814,7 @@ static int prune_refs(struct refspec *refs, int ref_count, struct ref *ref_map,
 				fprintf(stderr, _("From %.*s\n"), url_len, url);
 				shown_url = 1;
 			}
-			format_display(&sb, 'x', _("[deleted]"), NULL,
+			format_display(&sb, '-', _("[deleted]"), NULL,
 				       _("(none)"), prettify_refname(ref->name));
 			fprintf(stderr, " %s\n",sb.buf);
 			strbuf_release(&sb);
-- 
2.8.2.526.g02eed6d
Nguyễn Thái Ngọc Duy· Jun 26, 2016, 05:58 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v4 4/5] fetch: align all "remote -> local" output

We do align "remote -> local" output by allocating 10 columns to "remote". That produces aligned output only for short refs. An extra pass is performed to find the longest remote ref name (that does not produce a line longer than terminal width) to produce better aligned output.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 builtin/fetch.c  | 46 ++++++++++++++++++++++++++++++++++++++++++++--
 t/t5510-fetch.sh | 15 +++++++++++++++
 2 files changed, 59 insertions(+), 2 deletions(-)
Show changes to 2 files +59 −2

builtin/fetch.c, t/t5510-fetch.sh

diff --git a/builtin/fetch.c b/builtin/fetch.c
index 8177f90..c42795b 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -15,6 +15,7 @@
 #include "submodule.h"
 #include "connected.h"
 #include "argv-array.h"
+#include "utf8.h"
 
 static const char * const builtin_fetch_usage[] = {
 	N_("git fetch [<options>] [<repository> [<refspec>...]]"),
@@ -449,14 +450,53 @@ fail:
 			   : STORE_REF_ERROR_OTHER;
 }
 
-#define REFCOL_WIDTH  10
+static int refcol_width = 10;
+
+static void adjust_refcol_width(const struct ref *ref)
+{
+	int max, rlen, llen;
+
+	/* uptodate lines are only shown on high verbosity level */
+	if (!verbosity && !oidcmp(&ref->peer_ref->old_oid, &ref->old_oid))
+		return;
+
+	max    = term_columns();
+	rlen   = utf8_strwidth(prettify_refname(ref->name));
+	llen   = utf8_strwidth(prettify_refname(ref->peer_ref->name));
+
+	/*
+	 * rough estimation to see if the output line is too long and
+	 * should not be counted (we can't do precise calculation
+	 * anyway because we don't know if the error explanation part
+	 * will be printed in update_local_ref)
+	 */
+	if (21 /* flag and summary */ + rlen + 4 /* -> */ + llen >= max)
+		return;
+
+	if (refcol_width < rlen)
+		refcol_width = rlen;
+}
+
+static void prepare_format_display(struct ref *ref_map)
+{
+	struct ref *rm;
+
+	for (rm = ref_map; rm; rm = rm->next) {
+		if (rm->status == REF_STATUS_REJECT_SHALLOW ||
+		    !rm->peer_ref ||
+		    !strcmp(rm->name, "HEAD"))
+			continue;
+
+		adjust_refcol_width(rm);
+	}
+}
 
 static void format_display(struct strbuf *display, char code,
 			   const char *summary, const char *error,
 			   const char *remote, const char *local)
 {
 	strbuf_addf(display, "%c %-*s ", code, TRANSPORT_SUMMARY(summary));
-	strbuf_addf(display, "%-*s -> %s", REFCOL_WIDTH, remote, local);
+	strbuf_addf(display, "%-*s -> %s", refcol_width, remote, local);
 	if (error)
 		strbuf_addf(display, "  (%s)", error);
 }
@@ -618,6 +658,8 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
 		goto abort;
 	}
 
+	prepare_format_display(ref_map);
+
 	/*
 	 * We do a pass for each fetch_head_status type in their enum order, so
 	 * merged entries are written before not-for-merge. That lets readers
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 454d896..f50497e 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -688,4 +688,19 @@ test_expect_success 'fetching with auto-gc does not lock up' '
 	)
 '
 
+test_expect_success 'fetch aligned output' '
+	git clone . full-output &&
+	test_commit looooooooooooong-tag &&
+	(
+		cd full-output &&
+		git fetch origin 2>&1 | \
+			grep -e "->" | cut -c 22- >../actual
+	) &&
+	cat >expect <<-\EOF &&
+	master               -> origin/master
+	looooooooooooong-tag -> looooooooooooong-tag
+	EOF
+	test_cmp expect actual
+'
+
 test_done
-- 
2.8.2.526.g02eed6d
Nguyễn Thái Ngọc Duy· Jun 26, 2016, 05:58 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v4 5/5] fetch: reduce duplicate in ref update status lines with placeholder

In the "remote -> local" line, if either ref is a substring of the other, the common part in the other string is replaced with "$". For example

    abc                -> origin/abc
    refs/pull/123/head -> pull/123
become
    abc         -> origin/$
    refs/$/head -> pull/123
Activated with fetch.output=compact.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Documentation/config.txt    |  5 +++
 Documentation/git-fetch.txt |  5 +++
 builtin/fetch.c             | 75 ++++++++++++++++++++++++++++++++++++++++++++-
 t/t5510-fetch.sh            | 17 +++++++++-
 4 files changed, 100 insertions(+), 2 deletions(-)
Show changes to 4 files +100 −2

Documentation/config.txt, Documentation/git-fetch.txt, builtin/fetch.c, t/t5510-fetch.sh

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2e1b2e4..7f6e58d 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1220,6 +1220,11 @@ fetch.prune::
 	If true, fetch will automatically behave as if the `--prune`
 	option was given on the command line.  See also `remote.<name>.prune`.
 
+fetch.output::
+	Control how ref update status is printed. Valid values are
+	`full` and `compact`. Default value is `full`. See section
+	OUTPUT in linkgit:git-fetch[1] for detail.
+
 format.attach::
 	Enable multipart/mixed attachments as the default for
 	'format-patch'.  The value can also be a double quoted string
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 771dde5..61e8885 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -116,6 +116,11 @@ representing the status of a single ref. Each line is of the form:
 The status of up-to-date refs is shown only if the --verbose option is
 used.
 
+In compact output mode, if either entire `<from>` or `<to>` is found
+in the other string, it will be substituted with `$` in the other
+string. or example, `master -> origin/master` becomes
+`master -> origin/$`.
+
 flag::
 	A single character indicating the status of the ref:
 (space);; for a successfully fetched fast-forward;
diff --git a/builtin/fetch.c b/builtin/fetch.c
index c42795b..9d9f4e8 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -451,6 +451,7 @@ fail:
 }
 
 static int refcol_width = 10;
+static int compact_format;
 
 static void adjust_refcol_width(const struct ref *ref)
 {
@@ -462,6 +463,17 @@ static void adjust_refcol_width(const struct ref *ref)
 
 	max    = term_columns();
 	rlen   = utf8_strwidth(prettify_refname(ref->name));
+
+	if (compact_format) {
+		/*
+		 * Not precise calculation because '$' can appear in
+		 * ref->name and reduce actual length.
+		 */
+		if (refcol_width < rlen)
+			refcol_width = rlen;
+		return;
+	}
+
 	llen   = utf8_strwidth(prettify_refname(ref->peer_ref->name));
 
 	/*
@@ -480,6 +492,16 @@ static void adjust_refcol_width(const struct ref *ref)
 static void prepare_format_display(struct ref *ref_map)
 {
 	struct ref *rm;
+	const char *format = "full";
+
+	git_config_get_string_const("fetch.output", &format);
+	if (!strcasecmp(format, "full"))
+		compact_format = 0;
+	else if (!strcasecmp(format, "compact"))
+		compact_format = 1;
+	else
+		die(_("configuration fetch.output contains invalid value %s"),
+		    format);
 
 	for (rm = ref_map; rm; rm = rm->next) {
 		if (rm->status == REF_STATUS_REJECT_SHALLOW ||
@@ -491,12 +513,63 @@ static void prepare_format_display(struct ref *ref_map)
 	}
 }
 
+static void print_remote_to_local(struct strbuf *display,
+				  const char *remote, const char *local)
+{
+	strbuf_addf(display, "%-*s -> %s", refcol_width, remote, local);
+}
+
+static int dollarize(struct strbuf *haystack, const char *needle)
+{
+	const char *p = strstr(haystack->buf, needle);
+	int plen, nlen;
+
+	if (!p)
+		return 0;
+
+	if (p > haystack->buf && p[-1] != '/')
+		return 0;
+
+	plen = strlen(p);
+	nlen = strlen(needle);
+	if (plen > nlen && p[nlen] != '/')
+		return 0;
+
+	strbuf_splice(haystack, p - haystack->buf, nlen, "$", 1);
+	return 1;
+}
+
+static void print_compact(struct strbuf *display,
+			  const char *remote, const char *local)
+{
+	struct strbuf r = STRBUF_INIT;
+	struct strbuf l = STRBUF_INIT;
+
+	if (!strcmp(remote, local)) {
+		strbuf_addf(display, "%-*s -> $", refcol_width, remote);
+		return;
+	}
+
+	strbuf_addstr(&r, remote);
+	strbuf_addstr(&l, local);
+
+	if (!dollarize(&r, local))
+		dollarize(&l, remote);
+	print_remote_to_local(display, r.buf, l.buf);
+
+	strbuf_release(&r);
+	strbuf_release(&l);
+}
+
 static void format_display(struct strbuf *display, char code,
 			   const char *summary, const char *error,
 			   const char *remote, const char *local)
 {
 	strbuf_addf(display, "%c %-*s ", code, TRANSPORT_SUMMARY(summary));
-	strbuf_addf(display, "%-*s -> %s", refcol_width, remote, local);
+	if (!compact_format)
+		print_remote_to_local(display, remote, local);
+	else
+		print_compact(display, remote, local);
 	if (error)
 		strbuf_addf(display, "  (%s)", error);
 }
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index f50497e..3a92718 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -693,7 +693,7 @@ test_expect_success 'fetch aligned output' '
 	test_commit looooooooooooong-tag &&
 	(
 		cd full-output &&
-		git fetch origin 2>&1 | \
+		git -c fetch.output=full fetch origin 2>&1 | \
 			grep -e "->" | cut -c 22- >../actual
 	) &&
 	cat >expect <<-\EOF &&
@@ -703,4 +703,19 @@ test_expect_success 'fetch aligned output' '
 	test_cmp expect actual
 '
 
+test_expect_success 'fetch compact output' '
+	git clone . compact &&
+	test_commit extraaa &&
+	(
+		cd compact &&
+		git -c fetch.output=compact fetch origin 2>&1 | \
+			grep -e "->" | cut -c 22- >../actual
+	) &&
+	cat >expect <<-\EOF &&
+	master     -> origin/$
+	extraaa    -> $
+	EOF
+	test_cmp expect actual
+'
+
 test_done
-- 
2.8.2.526.g02eed6d
Eric Sunshine· Jun 27, 2016, 04:33 UTC · re: Nguyễn Thái Ngọc Duy · lore

Re: [PATCH v4 5/5] fetch: reduce duplicate in ref update status lines with placeholder

On Sun, Jun 26, 2016 at 1:58 AM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
Show 11 quoted lines
> In the "remote -> local" line, if either ref is a substring of the
> other, the common part in the other string is replaced with "$". For
> example
>
>     abc                -> origin/abc
>     refs/pull/123/head -> pull/123
>
> become
>
>     abc         -> origin/$
>     refs/$/head -> pull/123
Bikeshedding...

I think I recall in an earlier iteration that you asked for opinions about '$', but don't recall if there were responses. Have you considered '*' rather than '$'?

In my brain, at least, '$' is associated so strongly with regex that "origin/$" is interpreted automatically as anchoring "origin/" at the end of string, and "refs/$/head" just feels weird.

On the other hand, given the familiarity of shell globbing, "origin/*" and "refs/*/head" feel quite natural and intuitive.

Show 7 quoted lines
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
> @@ -116,6 +116,11 @@ representing the status of a single ref. Each line is of the form:
> +In compact output mode, if either entire `<from>` or `<to>` is found
> +in the other string, it will be substituted with `$` in the other
> +string. or example, `master -> origin/master` becomes
s/or/For/
> +`master -> origin/$`.
Duy Nguyen· Jun 27, 2016, 05:42 UTC · re: Eric Sunshine · lore

Re: [PATCH v4 5/5] fetch: reduce duplicate in ref update status lines with placeholder

On Mon, Jun 27, 2016 at 6:33 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 18 quoted lines
> On Sun, Jun 26, 2016 at 1:58 AM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
>> In the "remote -> local" line, if either ref is a substring of the
>> other, the common part in the other string is replaced with "$". For
>> example
>>
>>     abc                -> origin/abc
>>     refs/pull/123/head -> pull/123
>>
>> become
>>
>>     abc         -> origin/$
>>     refs/$/head -> pull/123
>
> Bikeshedding...
>
> I think I recall in an earlier iteration that you asked for opinions
> about '$', but don't recall if there were responses. Have you
> considered '*' rather than '$'?

I did. But I remembered that * is used as wildcard in refspec, which is specified on both sides, e.g. refs/heads/*:refs/remotes/foo/* and wondered if it could cause a little confusion when the user sees '*' only on one side here. But I have no strong opinion on '$' or '*' or any other character. So if nobody says anything else, the next re-roll will go with '*'.

> In my brain, at least, '$' is associated so strongly with regex that
> "origin/$" is interpreted automatically as anchoring "origin/" at the
> end of string, and "refs/$/head" just feels weird.

On the other hand, '$' has been used as the variable expansion symbol in shell, tcl, perl and php (which are probably the same thing since I have a feeling all of them borrow '$' from one source, probably shell). But yeah, '$' at the end could remind people of regexp too.

> On the other hand, given the familiarity of shell globbing, "origin/*"
> and "refs/*/head" feel quite natural and intuitive.
-- 
Duy
Junio C Hamano· Jun 27, 2016, 15:31 UTC · re: Eric Sunshine · lore

Re: [PATCH v4 5/5] fetch: reduce duplicate in ref update status lines with placeholder

Eric Sunshine <sunshine@sunshineco.com> writes:
Show 6 quoted lines
> In my brain, at least, '$' is associated so strongly with regex that
> "origin/$" is interpreted automatically as anchoring "origin/" at the
> end of string, and "refs/$/head" just feels weird.
>
> On the other hand, given the familiarity of shell globbing, "origin/*"
> and "refs/*/head" feel quite natural and intuitive.
I had the same thought ;-)
Jeff King· Jun 27, 2016, 18:43 UTC · re: Nguyễn Thái Ngọc Duy · lore

Re: [PATCH v4 0/5] Better ref summary alignment in "git fetch"

On Sun, Jun 26, 2016 at 07:58:05AM +0200, Nguyễn Thái Ngọc Duy wrote:
> v4 is a cleaned up version of v3. Tests are added. Typos in
> git-fetch.txt are corrected. The "{ -> origin/}master" format is
> dropped.
Thanks for continuing to look into this.

I tried it on my most-horrible example case, and the results were...just OK. Because the variable-length part of each line comes first, the alignment code means that the "origin/$" bit of every line gets bumped out. And if you have a single large branch name, then everybody gets bumped out very far, even to the point of wrapping. E.g., I get something like (with fetch.output=compact, obviously):

  From ...
   * [new branch]      branch1                      -> origin/$
   * [new branch]      branch2                      -> origin/$
   * [new branch]      some-really-long-branch-name -> origin/$
   + 1234abc..5678def  branch3                      -> origin/$ (forced
    update)
   * [new branch]      branch4                      -> origin/$

I've shrunk it a bit to fit in the email; my actual "long" name was much larger. And the average length for the shorter ones is, too, but the overall effect is the same; almost every line has a huge run of whitespace. And some lines wrap that would not have even under the normal, duplicated scheme.

One of the nice things about Junio's "{ -> origin/}" suggestion is that it puts the variable-length part at the end, so there's no extra alignment required. And you'd get something like:

  From ...
   * [new branch]      { -> origin/}branch1
   * [new branch]      { -> origin/}branch2
   * [new branch]      { -> origin/}some-really-long-branch-name
   + 1234abc..5678def  { -> origin/}branch3 (forced update)
   * [new branch]      { -> origin/}branch4
-Peff
Duy Nguyen· Jun 27, 2016, 19:27 UTC · re: Jeff King · lore

Re: [PATCH v4 0/5] Better ref summary alignment in "git fetch"

On Mon, Jun 27, 2016 at 02:43:54PM -0400, Jeff King wrote:
Show 23 quoted lines
> On Sun, Jun 26, 2016 at 07:58:05AM +0200, Nguyễn Thái Ngọc Duy wrote:
> 
> > v4 is a cleaned up version of v3. Tests are added. Typos in
> > git-fetch.txt are corrected. The "{ -> origin/}master" format is
> > dropped.
> 
> Thanks for continuing to look into this.
> 
> I tried it on my most-horrible example case, and the results were...just
> OK. Because the variable-length part of each line comes first, the
> alignment code means that the "origin/$" bit of every line gets bumped
> out. And if you have a single large branch name, then everybody gets
> bumped out very far, even to the point of wrapping. E.g., I get
> something like (with fetch.output=compact, obviously):
> 
>   From ...
>    * [new branch]      branch1                      -> origin/$
>    * [new branch]      branch2                      -> origin/$
>    * [new branch]      some-really-long-branch-name -> origin/$
>    + 1234abc..5678def  branch3                      -> origin/$ (forced
>     update)
>    * [new branch]      branch4                      -> origin/$
>

Yeah, '$' lowers the chances of wrapping but in corner cases, it'll be just as bad.

Junio's suggestion is one way to go. Another is Marc's idea of breaking lines, so we could in theory have something like this

   From ...
    * [new branch]      branch1    -> origin/$
    * [new branch]      branch2    -> origin/$
    * [new branch]      some-really-long-branch-name
                           -> origin/$
    + 1234abc..5678def  branch3    -> origin/$ (forced update)
    * [new branch]      branch4    -> origin/$

Or, for a very long branch name, we could put replace a big chunk of it with an ellipsis. If it's long enough, I guess you can still figure the branch name with a big gap in the middle (or left or right).

   From ...
    * [new branch]      branch1             -> origin/$
    * [new branch]      branch2             -> origin/$
    * [new branch]      some-re...anch-name -> origin/$
    + 1234abc..5678def  branch3             -> origin/$ (forced update)
    * [new branch]      branch4             -> origin/$

And with that we get dangerously close to full customization using pretty placeholders :)

Show 12 quoted lines
> One of the nice things about Junio's "{ -> origin/}" suggestion is that
> it puts the variable-length part at the end, so there's no extra
> alignment required. And you'd get something like:
> 
>   From ...
>    * [new branch]      { -> origin/}branch1
>    * [new branch]      { -> origin/}branch2
>    * [new branch]      { -> origin/}some-really-long-branch-name
>    + 1234abc..5678def  { -> origin/}branch3 (forced update)
>    * [new branch]      { -> origin/}branch4
> 
> -Peff
Duy Nguyen· Jun 30, 2016, 16:16 UTC · re: Jeff King · lore

Re: [PATCH v4 0/5] Better ref summary alignment in "git fetch"

On Mon, Jun 27, 2016 at 8:43 PM, Jeff King <peff@peff.net> wrote:
Show 20 quoted lines
> I tried it on my most-horrible example case, and the results were...just
> OK. Because the variable-length part of each line comes first, the
> alignment code means that the "origin/$" bit of every line gets bumped
> out. And if you have a single large branch name, then everybody gets
> bumped out very far, even to the point of wrapping. E.g., I get
> something like (with fetch.output=compact, obviously):
>
>   From ...
>    * [new branch]      branch1                      -> origin/$
>    * [new branch]      branch2                      -> origin/$
>    * [new branch]      some-really-long-branch-name -> origin/$
>    + 1234abc..5678def  branch3                      -> origin/$ (forced
>     update)
>    * [new branch]      branch4                      -> origin/$
>
> I've shrunk it a bit to fit in the email; my actual "long" name was much
> larger. And the average length for the shorter ones is, too, but the
> overall effect is the same; almost every line has a huge run of
> whitespace. And some lines wrap that would not have even under the
> normal, duplicated scheme.

I was about to resend with s/\$/*/g and ignored this issue (with a note) then it occurred to me we can simply ignore these long lines from column width calculation. Yeah such a line may still be wrapped around, but it will not push every other line to the far right. We already have code for that in adjust_refcol_width()

        max    = term_columns();
        ...
        /*
        * rough estimation to see if the output line is too long and
        * should not be counted (we can't do precise calculation
        * anyway because we don't know if the error explanation part
        * will be printed in update_local_ref)
        */
        if (21 /* flag and summary */ + rlen + 4 /* -> */ + llen >= max)
                return;
        ...

we can limit max to, like, term_columns() / 2 (or 2/3 of term_columns). There's no perfect number, some people will still find the output ugly _often_. But hopefully the majority won't. What do you think?

-- 
Duy
Jeff King· Jul 1, 2016, 06:09 UTC · re: Duy Nguyen · lore

Re: [PATCH v4 0/5] Better ref summary alignment in "git fetch"

On Thu, Jun 30, 2016 at 06:16:09PM +0200, Duy Nguyen wrote:
Show 28 quoted lines
> > I've shrunk it a bit to fit in the email; my actual "long" name was much
> > larger. And the average length for the shorter ones is, too, but the
> > overall effect is the same; almost every line has a huge run of
> > whitespace. And some lines wrap that would not have even under the
> > normal, duplicated scheme.
> 
> I was about to resend with s/\$/*/g and ignored this issue (with a
> note) then it occurred to me we can simply ignore these long lines
> from column width calculation. Yeah such a line may still be wrapped
> around, but it will not push every other line to the far right. We
> already have code for that in adjust_refcol_width()
> 
>         max    = term_columns();
>         ...
>         /*
>         * rough estimation to see if the output line is too long and
>         * should not be counted (we can't do precise calculation
>         * anyway because we don't know if the error explanation part
>         * will be printed in update_local_ref)
>         */
>         if (21 /* flag and summary */ + rlen + 4 /* -> */ + llen >= max)
>                 return;
>         ...
> 
> we can limit max to, like, term_columns() / 2 (or 2/3 of
> term_columns). There's no perfect number, some people will still find
> the output ugly _often_. But hopefully the majority won't. What do you
> think?

Without having seen the output, my gut feeling is "meh". It will hopefully avoid the wrapping, and it will reduce the size of the huge whitespace gap, but not eliminate it. So I think it will still be somewhat ugly.

-Peff
Nguyễn Thái Ngọc Duy· Jul 1, 2016, 16:03 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v5 0/5] Better ref summary alignment in "git fetch"

v5 changes the substitute symbol from '$' to '*' in compact mode and makes sure long lines in compact mode will not make the remote ref column too big (it's far from perfect but I think it's still good to do).

I'm not sure if we should bring back "{ -> origin/}foo" format. I can do it if someone still wants it.

Interdiff
Show changes to 3 files +26 −23

Documentation/git-fetch.txt, builtin/fetch.c, t/t5510-fetch.sh

diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 61e8885..9e42169 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -116,10 +116,10 @@ representing the status of a single ref. Each line is of the form:
 The status of up-to-date refs is shown only if the --verbose option is
 used.
 
-In compact output mode, if either entire `<from>` or `<to>` is found
-in the other string, it will be substituted with `$` in the other
-string. or example, `master -> origin/master` becomes
-`master -> origin/$`.
+In compact output mode, specified with configuration variable
+fetch.output, if either entire `<from>` or `<to>` is found in the
+other string, it will be substituted with `*` in the other string. For
+example, `master -> origin/master` becomes `master -> origin/*`.
 
 flag::
 	A single character indicating the status of the ref:
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 9d9f4e8..0a2eed1 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -455,7 +455,7 @@ static int compact_format;
 
 static void adjust_refcol_width(const struct ref *ref)
 {
-	int max, rlen, llen;
+	int max, rlen, llen, len;
 
 	/* uptodate lines are only shown on high verbosity level */
 	if (!verbosity && !oidcmp(&ref->peer_ref->old_oid, &ref->old_oid))
@@ -464,16 +464,6 @@ static void adjust_refcol_width(const struct ref *ref)
 	max    = term_columns();
 	rlen   = utf8_strwidth(prettify_refname(ref->name));
 
-	if (compact_format) {
-		/*
-		 * Not precise calculation because '$' can appear in
-		 * ref->name and reduce actual length.
-		 */
-		if (refcol_width < rlen)
-			refcol_width = rlen;
-		return;
-	}
-
 	llen   = utf8_strwidth(prettify_refname(ref->peer_ref->name));
 
 	/*
@@ -482,9 +472,19 @@ static void adjust_refcol_width(const struct ref *ref)
 	 * anyway because we don't know if the error explanation part
 	 * will be printed in update_local_ref)
 	 */
-	if (21 /* flag and summary */ + rlen + 4 /* -> */ + llen >= max)
+	if (compact_format) {
+		llen = 0;
+		max = max * 2 / 3;
+	}
+	len = 21 /* flag and summary */ + rlen + 4 /* -> */ + llen;
+	if (len >= max)
 		return;
 
+	/*
+	 * Not precise calculation for compact mode because '*' can
+	 * appear on the left hand side of '->' and shrink the column
+	 * back.
+	 */
 	if (refcol_width < rlen)
 		refcol_width = rlen;
 }
@@ -519,7 +519,9 @@ static void print_remote_to_local(struct strbuf *display,
 	strbuf_addf(display, "%-*s -> %s", refcol_width, remote, local);
 }
 
-static int dollarize(struct strbuf *haystack, const char *needle)
+static int find_and_replace(struct strbuf *haystack,
+			    const char *needle,
+			    const char *placeholder)
 {
 	const char *p = strstr(haystack->buf, needle);
 	int plen, nlen;
@@ -535,7 +537,8 @@ static int dollarize(struct strbuf *haystack, const char *needle)
 	if (plen > nlen && p[nlen] != '/')
 		return 0;
 
-	strbuf_splice(haystack, p - haystack->buf, nlen, "$", 1);
+	strbuf_splice(haystack, p - haystack->buf, nlen,
+		      placeholder, strlen(placeholder));
 	return 1;
 }
 
@@ -546,15 +549,15 @@ static void print_compact(struct strbuf *display,
 	struct strbuf l = STRBUF_INIT;
 
 	if (!strcmp(remote, local)) {
-		strbuf_addf(display, "%-*s -> $", refcol_width, remote);
+		strbuf_addf(display, "%-*s -> *", refcol_width, remote);
 		return;
 	}
 
 	strbuf_addstr(&r, remote);
 	strbuf_addstr(&l, local);
 
-	if (!dollarize(&r, local))
-		dollarize(&l, remote);
+	if (!find_and_replace(&r, local, "*"))
+		find_and_replace(&l, remote, "*");
 	print_remote_to_local(display, r.buf, l.buf);
 
 	strbuf_release(&r);
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 3a92718..6032776 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -712,8 +712,8 @@ test_expect_success 'fetch compact output' '
 			grep -e "->" | cut -c 22- >../actual
 	) &&
 	cat >expect <<-\EOF &&
-	master     -> origin/$
-	extraaa    -> $
+	master     -> origin/*
+	extraaa    -> *
 	EOF
 	test_cmp expect actual
 '

Nguyễn Thái Ngọc Duy (5):
  git-fetch.txt: document fetch output
  fetch: refactor ref update status formatting code
  fetch: change flag code for displaying tag update and deleted ref
  fetch: align all "remote -> local" output
  fetch: reduce duplicate in ref update status lines with placeholder

 Documentation/config.txt    |   5 ++
 Documentation/git-fetch.txt |  51 ++++++++++++
 builtin/fetch.c             | 197 +++++++++++++++++++++++++++++++++++---------
 t/t5510-fetch.sh            |  30 +++++++
 4 files changed, 243 insertions(+), 40 deletions(-)
-- 
2.8.2.531.gd073806
Nguyễn Thái Ngọc Duy· Jul 1, 2016, 16:03 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v5 1/5] git-fetch.txt: document fetch output

This documents the ref update status of fetch. The structure of this output is defined in [1]. The ouput content is refined a bit in [2] [3] [4].

This patch is a copy from git-push.txt, modified a bit because the flag '-' means different things in push (delete) and fetch (tag update).

PS. For code archaeologists, the discussion mentioned in [1] is probably [5].

[1] 165f390 (git-fetch: more terse fetch output - 2007-11-03) [2] 6315472 (fetch: report local storage errors ... - 2008-06-26) [3] f360d84 (builtin-fetch: add --prune option - 2009-11-10) [4] 0997ada (fetch: describe new refs based on where... - 2012-04-16) [5] http://thread.gmane.org/gmane.comp.version-control.git/61657

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Documentation/git-fetch.txt | 46 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)
Show changes to Documentation/git-fetch.txt +46 −0
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index efe56e0..cbf441f 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -99,6 +99,52 @@ The latter use of the `remote.<repository>.fetch` values can be
 overridden by giving the `--refmap=<refspec>` parameter(s) on the
 command line.
 
+OUTPUT
+------
+
+The output of "git fetch" depends on the transport method used; this
+section describes the output when fetching over the Git protocol
+(either locally or via ssh) and Smart HTTP protocol.
+
+The status of the fetch is output in tabular form, with each line
+representing the status of a single ref. Each line is of the form:
+
+-------------------------------
+ <flag> <summary> <from> -> <to> [<reason>]
+-------------------------------
+
+The status of up-to-date refs is shown only if the --verbose option is
+used.
+
+flag::
+	A single character indicating the status of the ref:
+(space);; for a successfully fetched fast-forward;
+`+`;; for a successful forced update;
+`x`;; for a successfully pruned ref;
+`-`;; for a successful tag update;
+`*`;; for a successfully fetched new ref;
+`!`;; for a ref that was rejected or failed to update; and
+`=`;; for a ref that was up to date and did not need fetching.
+
+summary::
+	For a successfully fetched ref, the summary shows the old and new
+	values of the ref in a form suitable for using as an argument to
+	`git log` (this is `<old>..<new>` in most cases, and
+	`<old>...<new>` for forced non-fast-forward updates).
+
+from::
+	The name of the remote ref being fetched from, minus its
+	`refs/<type>/` prefix. In the case of deletion, the name of
+	the remote ref is "(none)".
+
+to::
+	The name of the local ref being updated, minus its
+	`refs/<type>/` prefix.
+
+reason::
+	A human-readable explanation. In the case of successfully fetched
+	refs, no explanation is needed. For a failed ref, the reason for
+	failure is described.
 
 EXAMPLES
 --------
-- 
2.8.2.531.gd073806
Nguyễn Thái Ngọc Duy· Jul 1, 2016, 16:03 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v5 2/5] fetch: refactor ref update status formatting code

This makes it easier to change the formatting later. And it makes sure translators cannot mess up format specifiers and break Git.

There are a couple call sites where the length of the second column is TRANSPORT_SUMMARY_WIDTH instead of calculated by TRANSPORT_SUMMARY(), which is enforced now. The result should be the same because these call sites do not contain characters outside ASCII range.

The two strbuf_addf() calls instead of one is mostly to reduce diff-noise in a future patch where "ref -> ref" is reformatted differently.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 builtin/fetch.c | 77 ++++++++++++++++++++++++++++-----------------------------
 1 file changed, 38 insertions(+), 39 deletions(-)
Show changes to builtin/fetch.c +38 −39
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 1582ca7..a7f152a 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -451,6 +451,16 @@ fail:
 
 #define REFCOL_WIDTH  10
 
+static void format_display(struct strbuf *display, char code,
+			   const char *summary, const char *error,
+			   const char *remote, const char *local)
+{
+	strbuf_addf(display, "%c %-*s ", code, TRANSPORT_SUMMARY(summary));
+	strbuf_addf(display, "%-*s -> %s", REFCOL_WIDTH, remote, local);
+	if (error)
+		strbuf_addf(display, "  (%s)", error);
+}
+
 static int update_local_ref(struct ref *ref,
 			    const char *remote,
 			    const struct ref *remote_ref,
@@ -467,9 +477,8 @@ static int update_local_ref(struct ref *ref,
 
 	if (!oidcmp(&ref->old_oid, &ref->new_oid)) {
 		if (verbosity > 0)
-			strbuf_addf(display, "= %-*s %-*s -> %s",
-				    TRANSPORT_SUMMARY(_("[up to date]")),
-				    REFCOL_WIDTH, remote, pretty_ref);
+			format_display(display, '=', _("[up to date]"), NULL,
+				       remote, pretty_ref);
 		return 0;
 	}
 
@@ -481,10 +490,9 @@ static int update_local_ref(struct ref *ref,
 		 * If this is the head, and it's not okay to update
 		 * the head, and the old value of the head isn't empty...
 		 */
-		strbuf_addf(display,
-			    _("! %-*s %-*s -> %s  (can't fetch in current branch)"),
-			    TRANSPORT_SUMMARY(_("[rejected]")),
-			    REFCOL_WIDTH, remote, pretty_ref);
+		format_display(display, '!', _("[rejected]"),
+			       _("can't fetch in current branch"),
+			       remote, pretty_ref);
 		return 1;
 	}
 
@@ -492,11 +500,9 @@ static int update_local_ref(struct ref *ref,
 	    starts_with(ref->name, "refs/tags/")) {
 		int r;
 		r = s_update_ref("updating tag", ref, 0);
-		strbuf_addf(display, "%c %-*s %-*s -> %s%s",
-			    r ? '!' : '-',
-			    TRANSPORT_SUMMARY(_("[tag update]")),
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    r ? _("  (unable to update local ref)") : "");
+		format_display(display, r ? '!' : '-', _("[tag update]"),
+			       r ? _("unable to update local ref") : NULL,
+			       remote, pretty_ref);
 		return r;
 	}
 
@@ -527,11 +533,9 @@ static int update_local_ref(struct ref *ref,
 		    (recurse_submodules != RECURSE_SUBMODULES_ON))
 			check_for_new_submodule_commits(ref->new_oid.hash);
 		r = s_update_ref(msg, ref, 0);
-		strbuf_addf(display, "%c %-*s %-*s -> %s%s",
-			    r ? '!' : '*',
-			    TRANSPORT_SUMMARY(what),
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    r ? _("  (unable to update local ref)") : "");
+		format_display(display, r ? '!' : '*', what,
+			       r ? _("unable to update local ref") : NULL,
+			       remote, pretty_ref);
 		return r;
 	}
 
@@ -545,11 +549,9 @@ static int update_local_ref(struct ref *ref,
 		    (recurse_submodules != RECURSE_SUBMODULES_ON))
 			check_for_new_submodule_commits(ref->new_oid.hash);
 		r = s_update_ref("fast-forward", ref, 1);
-		strbuf_addf(display, "%c %-*s %-*s -> %s%s",
-			    r ? '!' : ' ',
-			    TRANSPORT_SUMMARY_WIDTH, quickref.buf,
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    r ? _("  (unable to update local ref)") : "");
+		format_display(display, r ? '!' : ' ', quickref.buf,
+			       r ? _("unable to update local ref") : NULL,
+			       remote, pretty_ref);
 		strbuf_release(&quickref);
 		return r;
 	} else if (force || ref->force) {
@@ -562,18 +564,14 @@ static int update_local_ref(struct ref *ref,
 		    (recurse_submodules != RECURSE_SUBMODULES_ON))
 			check_for_new_submodule_commits(ref->new_oid.hash);
 		r = s_update_ref("forced-update", ref, 1);
-		strbuf_addf(display, "%c %-*s %-*s -> %s  (%s)",
-			    r ? '!' : '+',
-			    TRANSPORT_SUMMARY_WIDTH, quickref.buf,
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    r ? _("unable to update local ref") : _("forced update"));
+		format_display(display, r ? '!' : '+', quickref.buf,
+			       r ? _("unable to update local ref") : _("forced update"),
+			       remote, pretty_ref);
 		strbuf_release(&quickref);
 		return r;
 	} else {
-		strbuf_addf(display, "! %-*s %-*s -> %s  %s",
-			    TRANSPORT_SUMMARY(_("[rejected]")),
-			    REFCOL_WIDTH, remote, pretty_ref,
-			    _("(non-fast-forward)"));
+		format_display(display, '!', _("[rejected]"), _("non-fast-forward"),
+			       remote, pretty_ref);
 		return 1;
 	}
 }
@@ -714,11 +712,10 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
 				rc |= update_local_ref(ref, what, rm, &note);
 				free(ref);
 			} else
-				strbuf_addf(&note, "* %-*s %-*s -> FETCH_HEAD",
-					    TRANSPORT_SUMMARY_WIDTH,
-					    *kind ? kind : "branch",
-					    REFCOL_WIDTH,
-					    *what ? what : "HEAD");
+				format_display(&note, '*',
+					       *kind ? kind : "branch", NULL,
+					       *what ? what : "HEAD",
+					       "FETCH_HEAD");
 			if (note.len) {
 				if (verbosity >= 0 && !shown_url) {
 					fprintf(stderr, _("From %.*s\n"),
@@ -812,13 +809,15 @@ static int prune_refs(struct refspec *refs, int ref_count, struct ref *ref_map,
 
 	if (verbosity >= 0) {
 		for (ref = stale_refs; ref; ref = ref->next) {
+			struct strbuf sb = STRBUF_INIT;
 			if (!shown_url) {
 				fprintf(stderr, _("From %.*s\n"), url_len, url);
 				shown_url = 1;
 			}
-			fprintf(stderr, " x %-*s %-*s -> %s\n",
-				TRANSPORT_SUMMARY(_("[deleted]")),
-				REFCOL_WIDTH, _("(none)"), prettify_refname(ref->name));
+			format_display(&sb, 'x', _("[deleted]"), NULL,
+				       _("(none)"), prettify_refname(ref->name));
+			fprintf(stderr, " %s\n",sb.buf);
+			strbuf_release(&sb);
 			warn_dangling_symref(stderr, dangling_msg, ref->name);
 		}
 	}
-- 
2.8.2.531.gd073806
Nguyễn Thái Ngọc Duy· Jul 1, 2016, 16:03 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v5 5/5] fetch: reduce duplicate in ref update status lines with placeholder

In the "remote -> local" line, if either ref is a substring of the other, the common part in the other string is replaced with "*". For example

    abc                -> origin/abc
    refs/pull/123/head -> pull/123
become
    abc         -> origin/*
    refs/*/head -> pull/123
Activated with fetch.output=compact.

For the record, this output is not perfect. A single giant ref can push all refs very far to the right and likely be wrapped around. We may have a few options:

 - exclude these long lines smarter
 - break the line after "->", exclude it from column width calculation
 - implement a new format, { -> origin/}foo, which makes the problem
   go away at the cost of a bit harder to read
 - reverse all the arrows so we have "* <- looong-ref", again still
   hard to read.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Documentation/config.txt    |  5 +++
 Documentation/git-fetch.txt |  5 +++
 builtin/fetch.c             | 77 ++++++++++++++++++++++++++++++++++++++++++++-
 t/t5510-fetch.sh            | 17 +++++++++-
 4 files changed, 102 insertions(+), 2 deletions(-)
Show changes to 4 files +102 −2

Documentation/config.txt, Documentation/git-fetch.txt, builtin/fetch.c, t/t5510-fetch.sh

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2e1b2e4..7f6e58d 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1220,6 +1220,11 @@ fetch.prune::
 	If true, fetch will automatically behave as if the `--prune`
 	option was given on the command line.  See also `remote.<name>.prune`.
 
+fetch.output::
+	Control how ref update status is printed. Valid values are
+	`full` and `compact`. Default value is `full`. See section
+	OUTPUT in linkgit:git-fetch[1] for detail.
+
 format.attach::
 	Enable multipart/mixed attachments as the default for
 	'format-patch'.  The value can also be a double quoted string
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 771dde5..9e42169 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -116,6 +116,11 @@ representing the status of a single ref. Each line is of the form:
 The status of up-to-date refs is shown only if the --verbose option is
 used.
 
+In compact output mode, specified with configuration variable
+fetch.output, if either entire `<from>` or `<to>` is found in the
+other string, it will be substituted with `*` in the other string. For
+example, `master -> origin/master` becomes `master -> origin/*`.
+
 flag::
 	A single character indicating the status of the ref:
 (space);; for a successfully fetched fast-forward;
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 2bc609b..0a2eed1 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -451,6 +451,7 @@ fail:
 }
 
 static int refcol_width = 10;
+static int compact_format;
 
 static void adjust_refcol_width(const struct ref *ref)
 {
@@ -462,6 +463,7 @@ static void adjust_refcol_width(const struct ref *ref)
 
 	max    = term_columns();
 	rlen   = utf8_strwidth(prettify_refname(ref->name));
+
 	llen   = utf8_strwidth(prettify_refname(ref->peer_ref->name));
 
 	/*
@@ -470,10 +472,19 @@ static void adjust_refcol_width(const struct ref *ref)
 	 * anyway because we don't know if the error explanation part
 	 * will be printed in update_local_ref)
 	 */
+	if (compact_format) {
+		llen = 0;
+		max = max * 2 / 3;
+	}
 	len = 21 /* flag and summary */ + rlen + 4 /* -> */ + llen;
 	if (len >= max)
 		return;
 
+	/*
+	 * Not precise calculation for compact mode because '*' can
+	 * appear on the left hand side of '->' and shrink the column
+	 * back.
+	 */
 	if (refcol_width < rlen)
 		refcol_width = rlen;
 }
@@ -481,6 +492,16 @@ static void adjust_refcol_width(const struct ref *ref)
 static void prepare_format_display(struct ref *ref_map)
 {
 	struct ref *rm;
+	const char *format = "full";
+
+	git_config_get_string_const("fetch.output", &format);
+	if (!strcasecmp(format, "full"))
+		compact_format = 0;
+	else if (!strcasecmp(format, "compact"))
+		compact_format = 1;
+	else
+		die(_("configuration fetch.output contains invalid value %s"),
+		    format);
 
 	for (rm = ref_map; rm; rm = rm->next) {
 		if (rm->status == REF_STATUS_REJECT_SHALLOW ||
@@ -492,12 +513,66 @@ static void prepare_format_display(struct ref *ref_map)
 	}
 }
 
+static void print_remote_to_local(struct strbuf *display,
+				  const char *remote, const char *local)
+{
+	strbuf_addf(display, "%-*s -> %s", refcol_width, remote, local);
+}
+
+static int find_and_replace(struct strbuf *haystack,
+			    const char *needle,
+			    const char *placeholder)
+{
+	const char *p = strstr(haystack->buf, needle);
+	int plen, nlen;
+
+	if (!p)
+		return 0;
+
+	if (p > haystack->buf && p[-1] != '/')
+		return 0;
+
+	plen = strlen(p);
+	nlen = strlen(needle);
+	if (plen > nlen && p[nlen] != '/')
+		return 0;
+
+	strbuf_splice(haystack, p - haystack->buf, nlen,
+		      placeholder, strlen(placeholder));
+	return 1;
+}
+
+static void print_compact(struct strbuf *display,
+			  const char *remote, const char *local)
+{
+	struct strbuf r = STRBUF_INIT;
+	struct strbuf l = STRBUF_INIT;
+
+	if (!strcmp(remote, local)) {
+		strbuf_addf(display, "%-*s -> *", refcol_width, remote);
+		return;
+	}
+
+	strbuf_addstr(&r, remote);
+	strbuf_addstr(&l, local);
+
+	if (!find_and_replace(&r, local, "*"))
+		find_and_replace(&l, remote, "*");
+	print_remote_to_local(display, r.buf, l.buf);
+
+	strbuf_release(&r);
+	strbuf_release(&l);
+}
+
 static void format_display(struct strbuf *display, char code,
 			   const char *summary, const char *error,
 			   const char *remote, const char *local)
 {
 	strbuf_addf(display, "%c %-*s ", code, TRANSPORT_SUMMARY(summary));
-	strbuf_addf(display, "%-*s -> %s", refcol_width, remote, local);
+	if (!compact_format)
+		print_remote_to_local(display, remote, local);
+	else
+		print_compact(display, remote, local);
 	if (error)
 		strbuf_addf(display, "  (%s)", error);
 }
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index f50497e..6032776 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -693,7 +693,7 @@ test_expect_success 'fetch aligned output' '
 	test_commit looooooooooooong-tag &&
 	(
 		cd full-output &&
-		git fetch origin 2>&1 | \
+		git -c fetch.output=full fetch origin 2>&1 | \
 			grep -e "->" | cut -c 22- >../actual
 	) &&
 	cat >expect <<-\EOF &&
@@ -703,4 +703,19 @@ test_expect_success 'fetch aligned output' '
 	test_cmp expect actual
 '
 
+test_expect_success 'fetch compact output' '
+	git clone . compact &&
+	test_commit extraaa &&
+	(
+		cd compact &&
+		git -c fetch.output=compact fetch origin 2>&1 | \
+			grep -e "->" | cut -c 22- >../actual
+	) &&
+	cat >expect <<-\EOF &&
+	master     -> origin/*
+	extraaa    -> *
+	EOF
+	test_cmp expect actual
+'
+
 test_done
-- 
2.8.2.531.gd073806
Nguyễn Thái Ngọc Duy· Jul 1, 2016, 16:03 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v5 3/5] fetch: change flag code for displaying tag update and deleted ref

This makes the fetch flag code consistent with push, where '-' means deleted ref.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Documentation/git-fetch.txt | 4 ++--
 builtin/fetch.c             | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)
Show changes to 2 files +4 −4

Documentation/git-fetch.txt, builtin/fetch.c

diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index cbf441f..771dde5 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -120,8 +120,8 @@ flag::
 	A single character indicating the status of the ref:
 (space);; for a successfully fetched fast-forward;
 `+`;; for a successful forced update;
-`x`;; for a successfully pruned ref;
-`-`;; for a successful tag update;
+`-`;; for a successfully pruned ref;
+`t`;; for a successful tag update;
 `*`;; for a successfully fetched new ref;
 `!`;; for a ref that was rejected or failed to update; and
 `=`;; for a ref that was up to date and did not need fetching.
diff --git a/builtin/fetch.c b/builtin/fetch.c
index a7f152a..8177f90 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -500,7 +500,7 @@ static int update_local_ref(struct ref *ref,
 	    starts_with(ref->name, "refs/tags/")) {
 		int r;
 		r = s_update_ref("updating tag", ref, 0);
-		format_display(display, r ? '!' : '-', _("[tag update]"),
+		format_display(display, r ? '!' : 't', _("[tag update]"),
 			       r ? _("unable to update local ref") : NULL,
 			       remote, pretty_ref);
 		return r;
@@ -814,7 +814,7 @@ static int prune_refs(struct refspec *refs, int ref_count, struct ref *ref_map,
 				fprintf(stderr, _("From %.*s\n"), url_len, url);
 				shown_url = 1;
 			}
-			format_display(&sb, 'x', _("[deleted]"), NULL,
+			format_display(&sb, '-', _("[deleted]"), NULL,
 				       _("(none)"), prettify_refname(ref->name));
 			fprintf(stderr, " %s\n",sb.buf);
 			strbuf_release(&sb);
-- 
2.8.2.531.gd073806
Nguyễn Thái Ngọc Duy· Jul 1, 2016, 16:03 UTC · re: Nguyễn Thái Ngọc Duy · lore

[PATCH v5 4/5] fetch: align all "remote -> local" output

We do align "remote -> local" output by allocating 10 columns to "remote". That produces aligned output only for short refs. An extra pass is performed to find the longest remote ref name (that does not produce a line longer than terminal width) to produce better aligned output.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 builtin/fetch.c  | 47 +++++++++++++++++++++++++++++++++++++++++++++--
 t/t5510-fetch.sh | 15 +++++++++++++++
 2 files changed, 60 insertions(+), 2 deletions(-)
Show changes to 2 files +60 −2

builtin/fetch.c, t/t5510-fetch.sh

diff --git a/builtin/fetch.c b/builtin/fetch.c
index 8177f90..2bc609b 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -15,6 +15,7 @@
 #include "submodule.h"
 #include "connected.h"
 #include "argv-array.h"
+#include "utf8.h"
 
 static const char * const builtin_fetch_usage[] = {
 	N_("git fetch [<options>] [<repository> [<refspec>...]]"),
@@ -449,14 +450,54 @@ fail:
 			   : STORE_REF_ERROR_OTHER;
 }
 
-#define REFCOL_WIDTH  10
+static int refcol_width = 10;
+
+static void adjust_refcol_width(const struct ref *ref)
+{
+	int max, rlen, llen, len;
+
+	/* uptodate lines are only shown on high verbosity level */
+	if (!verbosity && !oidcmp(&ref->peer_ref->old_oid, &ref->old_oid))
+		return;
+
+	max    = term_columns();
+	rlen   = utf8_strwidth(prettify_refname(ref->name));
+	llen   = utf8_strwidth(prettify_refname(ref->peer_ref->name));
+
+	/*
+	 * rough estimation to see if the output line is too long and
+	 * should not be counted (we can't do precise calculation
+	 * anyway because we don't know if the error explanation part
+	 * will be printed in update_local_ref)
+	 */
+	len = 21 /* flag and summary */ + rlen + 4 /* -> */ + llen;
+	if (len >= max)
+		return;
+
+	if (refcol_width < rlen)
+		refcol_width = rlen;
+}
+
+static void prepare_format_display(struct ref *ref_map)
+{
+	struct ref *rm;
+
+	for (rm = ref_map; rm; rm = rm->next) {
+		if (rm->status == REF_STATUS_REJECT_SHALLOW ||
+		    !rm->peer_ref ||
+		    !strcmp(rm->name, "HEAD"))
+			continue;
+
+		adjust_refcol_width(rm);
+	}
+}
 
 static void format_display(struct strbuf *display, char code,
 			   const char *summary, const char *error,
 			   const char *remote, const char *local)
 {
 	strbuf_addf(display, "%c %-*s ", code, TRANSPORT_SUMMARY(summary));
-	strbuf_addf(display, "%-*s -> %s", REFCOL_WIDTH, remote, local);
+	strbuf_addf(display, "%-*s -> %s", refcol_width, remote, local);
 	if (error)
 		strbuf_addf(display, "  (%s)", error);
 }
@@ -618,6 +659,8 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
 		goto abort;
 	}
 
+	prepare_format_display(ref_map);
+
 	/*
 	 * We do a pass for each fetch_head_status type in their enum order, so
 	 * merged entries are written before not-for-merge. That lets readers
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 454d896..f50497e 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -688,4 +688,19 @@ test_expect_success 'fetching with auto-gc does not lock up' '
 	)
 '
 
+test_expect_success 'fetch aligned output' '
+	git clone . full-output &&
+	test_commit looooooooooooong-tag &&
+	(
+		cd full-output &&
+		git fetch origin 2>&1 | \
+			grep -e "->" | cut -c 22- >../actual
+	) &&
+	cat >expect <<-\EOF &&
+	master               -> origin/master
+	looooooooooooong-tag -> looooooooooooong-tag
+	EOF
+	test_cmp expect actual
+'
+
 test_done
-- 
2.8.2.531.gd073806
Junio C Hamano· Jul 1, 2016, 23:21 UTC · re: Nguyễn Thái Ngọc Duy · lore

Re: [PATCH v5 0/5] Better ref summary alignment in "git fetch"

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:
Show 7 quoted lines
> I'm not sure if we should bring back "{ -> origin/}foo" format. I can
> do it if someone still wants it.
> ...
> +In compact output mode, specified with configuration variable
> +fetch.output, if either entire `<from>` or `<to>` is found in the
> +other string, it will be substituted with `*` in the other string. For
> +example, `master -> origin/master` becomes `master -> origin/*`.

What is the desired property we would want to see in the end result of this series (or possible replacement of it)? Easier to read by humans? Cut-and-paste friendliness? Alignment?

I think the largest objection against "{ -> origin/}master" was that it wasn't cut-and-paste ready. There might have been other attempts during the rerolls leading to this v5, but I have to say that what we ended up with, "master -> origin/*", is no more cut-and-paste friendly than "{ -> origin/}master".

I personally do not care much about cut-and-paste friendliness, and I see the cover-letter is titled with "alignment", but if the alignment is the sole issue, I would have to say "master -> origin/*" is such a great improvement over "{ -> origin/}master".

So, I do not see strong reason to reject this, but I am not enthused by the topic, either.

Duy Nguyen· Jul 2, 2016, 04:39 UTC · re: Junio C Hamano · lore

Re: [PATCH v5 0/5] Better ref summary alignment in "git fetch"

On Sat, Jul 2, 2016 at 1:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 13 quoted lines
> Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:
>
>> I'm not sure if we should bring back "{ -> origin/}foo" format. I can
>> do it if someone still wants it.
>> ...
>> +In compact output mode, specified with configuration variable
>> +fetch.output, if either entire `<from>` or `<to>` is found in the
>> +other string, it will be substituted with `*` in the other string. For
>> +example, `master -> origin/master` becomes `master -> origin/*`.
>
> What is the desired property we would want to see in the end result
> of this series (or possible replacement of it)?  Easier to read by
> humans?  Cut-and-paste friendliness?  Alignment?
Easier to read, which is largely improved by aligning output.
Show 5 quoted lines
> I think the largest objection against "{ -> origin/}master" was that
> it wasn't cut-and-paste ready.  There might have been other attempts
> during the rerolls leading to this v5, but I have to say that what
> we ended up with, "master -> origin/*", is no more cut-and-paste
> friendly than "{ -> origin/}master".

The true cut-paste friendly is the old output, though "master -> origin/*" is a tiny bit friendlier than "{ -> origin/}master" because you can double click on master in the former to select it (origin/ requires some typing, not much with the help of tab-completion). Double clicking on "origin/}master" may or may not select master alone, depending on your terminal settings.

-- 
Duy
Marc Branchaud· Jul 4, 2016, 13:17 UTC · re: Nguyễn Thái Ngọc Duy · lore

Re: [PATCH v5 0/5] Better ref summary alignment in "git fetch"

On 2016-07-01 12:03 PM, Nguyễn Thái Ngọc Duy wrote:
> v5 changes the substitute symbol from '$' to '*' in compact mode and
> makes sure long lines in compact mode will not make the remote ref
> column too big (it's far from perfect but I think it's still good to
> do).
I think the first 4 patches are great.

I have no opinion on the 5th patch, as I don't expect to use the compact format in any of its proposed forms (and I can't come up with an alternative).

		M.
Duy Nguyen· Jul 4, 2016, 15:08 UTC · re: Marc Branchaud · lore

Re: [PATCH v5 0/5] Better ref summary alignment in "git fetch"

On Mon, Jul 4, 2016 at 3:17 PM, Marc Branchaud <marcnarc@xiplink.com> wrote:
Show 13 quoted lines
> On 2016-07-01 12:03 PM, Nguyễn Thái Ngọc Duy wrote:
>>
>> v5 changes the substitute symbol from '$' to '*' in compact mode and
>> makes sure long lines in compact mode will not make the remote ref
>> column too big (it's far from perfect but I think it's still good to
>> do).
>
>
> I think the first 4 patches are great.
>
> I have no opinion on the 5th patch, as I don't expect to use the compact
> format in any of its proposed forms (and I can't come up with an
> alternative).

I started using compact mode for a couple days now and I find it nice. Because line lengths are shortened nearly by half, I can now have two vertical tmux panes in a window without wrapping.

-- 
Duy

← back to recent threads