{"thread":{"id":"10376","subject":"[RFC/PATCH] git-fetch: mega-terse fetch output","startedAt":"2007-10-19T06:22:19Z","lastAt":"2007-10-23T08:39:46Z","messageCount":40,"participants":["Jeff King","David Symonds","Shawn O. Pearce","Johannes Sixt","David Kastrup","Santi Béjar","Andreas Ericsson","Theodore Tso","Nicolas Pitre","Johannes Schindelin","Karl Hasselström","Steven Grimm","Sam Ravnborg","Miles Bader"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"56526","messageId":"20071019062219.GA28499@coredump.intra.peff.net","threadId":"10376","inReplyTo":null,"subject":"[RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T06:22:19Z","receivedAt":"2007-10-19T06:22:19Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"This makes the fetch output much more terse. It is likely to\nbe very controversial. Here's an example of the new output:\n\nIndexing objects: 100% (1061/1061), done.\nResolving deltas: 100% (638/638), done.\n==> git://repo.or.cz/git/spearce.git\n * branch gitk -> origin/gitk\n * branch maint -> origin/maint (fast forward)\n * branch master -> origin/master (fast forward)\n * branch next -> origin/next (fast forward)\n - branch pu -> origin/pu (non-fast forward, refused)\n * branch todo -> origin/todo (fast forward)\n==> git://repo.or.cz/git/spearce.git\n * tag v1.5.3.2 -> v1.5.3.2\n\nParticular changes include:\n  - rather than each updated ref stating the remote url, the\n    url is printed once before any refs\n  - refs which did not update get a '-' rather than a '*'\n  - the order is changed from \"$to: storing $from\" to\n    \"$from -> $to\"\n  - we abbreviate the local refs (chopping refs/heads,\n    refs/tags, refs/remotes). This means we're losing\n    information, but hopefully it is obvious when storing\n    \"origin/master\" that it is in refs/remotes.\n  - fast forward information goes at the end\n  - cut out \"Auto-following ...\" text\n\nWhat do people think? Some changes? All?\n\nOther questions:\n  - Is the \"==>\" too ugly? It needs to be short (many urls\n    are almost 80 characters already), and it needs to stand\n    out from the \"resolving deltas\" line, so I think some\n    symbol is reasonable.\n  - Should we omit \"(fast forward)\" since it is the usual\n    case?\n  - Should refs/remotes/* keep the \"remotes/\" part?\n  - If you read the patch, there are a few cases covered\n    that I don't show in the example. Are they ugly or\n    better? I can't even figure out how to\n    get the '==' case to show up.\n  - Should tags always just say \"tag $foo\". Do we ever\n    actually map the tags when following?\n  - How annoying is the doubled '==> $url' line? It comes\n    from the fact that we fetch the tags separately.\n\nSomebody mentioned colorization on irc. I think that is reasonable but\nshould definitely wait for another patch.\n\n---\n builtin-fetch.c |   73 +++++++++++++++++++++++++------------------------------\n 1 files changed, 33 insertions(+), 40 deletions(-)\n\nIt drops more lines than it adds, so it _must_ be good!\n\ndiff --git a/builtin-fetch.c b/builtin-fetch.c\nindex 3442f3d..4440521 100644\n--- a/builtin-fetch.c\n+++ b/builtin-fetch.c\n@@ -123,12 +123,6 @@ static struct ref *get_ref_map(struct transport *transport,\n \treturn ref_map;\n }\n \n-static void show_new(enum object_type type, unsigned char *sha1_new)\n-{\n-\tfprintf(stderr, \"  %s: %s\\n\", typename(type),\n-\t\tfind_unique_abbrev(sha1_new, DEFAULT_ABBREV));\n-}\n-\n static int s_update_ref(const char *action,\n \t\t\tstruct ref *ref,\n \t\t\tint check_old)\n@@ -157,6 +151,11 @@ static int update_local_ref(struct ref *ref,\n \tstruct commit *current = NULL, *updated;\n \tenum object_type type;\n \tstruct branch *current_branch = branch_get(NULL);\n+\tconst char *pretty_ref = ref->name + (\n+\t\t!prefixcmp(ref->name, \"refs/heads/\") ? 11 :\n+\t\t!prefixcmp(ref->name, \"refs/tags/\") ? 10 :\n+\t\t!prefixcmp(ref->name, \"refs/remotes/\") ? 13 :\n+\t\t0);\n \n \ttype = sha1_object_info(ref->new_sha1, NULL);\n \tif (type < 0)\n@@ -164,19 +163,15 @@ static int update_local_ref(struct ref *ref,\n \n \tif (!*ref->name) {\n \t\t/* Not storing */\n-\t\tif (verbose) {\n-\t\t\tfprintf(stderr, \"* fetched %s\\n\", note);\n-\t\t\tshow_new(type, ref->new_sha1);\n-\t\t}\n+\t\tif (verbose)\n+\t\t\tfprintf(stderr, \" * branch %s -> FETCH_HEAD\\n\", note);\n \t\treturn 0;\n \t}\n \n \tif (!hashcmp(ref->old_sha1, ref->new_sha1)) {\n-\t\tif (verbose) {\n-\t\t\tfprintf(stderr, \"* %s: same as %s\\n\",\n-\t\t\t\tref->name, note);\n-\t\t\tshow_new(type, ref->new_sha1);\n-\t\t}\n+\t\tif (verbose)\n+\t\t\tfprintf(stderr, \" - %s == %s\\n\",\n+\t\t\t\tnote, pretty_ref);\n \t\treturn 0;\n \t}\n \n@@ -189,30 +184,33 @@ static int update_local_ref(struct ref *ref,\n \t\t * the head, and the old value of the head isn't empty...\n \t\t */\n \t\tfprintf(stderr,\n-\t\t\t\" * %s: Cannot fetch into the current branch.\\n\",\n-\t\t\tref->name);\n+\t\t\t\" - %s: Cannot fetch into the current branch.\\n\",\n+\t\t\tpretty_ref);\n \t\treturn 1;\n \t}\n \n \tif (!is_null_sha1(ref->old_sha1) &&\n \t    !prefixcmp(ref->name, \"refs/tags/\")) {\n-\t\tfprintf(stderr, \"* %s: updating with %s\\n\",\n-\t\t\tref->name, note);\n-\t\tshow_new(type, ref->new_sha1);\n+\t\tfprintf(stderr, \" * tag %s -> %s\\n\",\n+\t\t\tnote, pretty_ref);\n \t\treturn s_update_ref(\"updating tag\", ref, 0);\n \t}\n \n \tcurrent = lookup_commit_reference(ref->old_sha1);\n \tupdated = lookup_commit_reference(ref->new_sha1);\n \tif (!current || !updated) {\n-\t\tchar *msg;\n-\t\tif (!strncmp(ref->name, \"refs/tags/\", 10))\n+\t\tconst char *msg;\n+\t\tconst char *what;\n+\t\tif (!strncmp(ref->name, \"refs/tags/\", 10)) {\n \t\t\tmsg = \"storing tag\";\n-\t\telse\n+\t\t\twhat = \"tag\";\n+\t\t}\n+\t\telse {\n \t\t\tmsg = \"storing head\";\n-\t\tfprintf(stderr, \"* %s: storing %s\\n\",\n-\t\t\tref->name, note);\n-\t\tshow_new(type, ref->new_sha1);\n+\t\t\twhat = \"branch\";\n+\t\t}\n+\t\tfprintf(stderr, \" * %s %s -> %s\\n\",\n+\t\t\twhat, note, pretty_ref);\n \t\treturn s_update_ref(msg, ref, 0);\n \t}\n \n@@ -220,23 +218,19 @@ static int update_local_ref(struct ref *ref,\n \tstrcpy(newh, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV));\n \n \tif (in_merge_bases(current, &updated, 1)) {\n-\t\tfprintf(stderr, \"* %s: fast forward to %s\\n\",\n-\t\t\tref->name, note);\n-\t\tfprintf(stderr, \"  old..new: %s..%s\\n\", oldh, newh);\n+\t\tfprintf(stderr, \" * branch %s -> %s (fast forward)\\n\",\n+\t\t\tnote, pretty_ref);\n \t\treturn s_update_ref(\"fast forward\", ref, 1);\n \t}\n \tif (!force && !ref->force) {\n \t\tfprintf(stderr,\n-\t\t\t\"* %s: not updating to non-fast forward %s\\n\",\n-\t\t\tref->name, note);\n-\t\tfprintf(stderr,\n-\t\t\t\"  old...new: %s...%s\\n\", oldh, newh);\n+\t\t\t\" - branch %s -> %s (non-fast forward, refused)\\n\",\n+\t\t\tnote, pretty_ref);\n \t\treturn 1;\n \t}\n \tfprintf(stderr,\n-\t\t\"* %s: forcing update to non-fast forward %s\\n\",\n-\t\tref->name, note);\n-\tfprintf(stderr, \"  old...new: %s...%s\\n\", oldh, newh);\n+\t\t\" * branch %s -> %s (non-fast forward)\\n\",\n+\t\tnote, pretty_ref);\n \treturn s_update_ref(\"forced-update\", ref, 1);\n }\n \n@@ -249,6 +243,8 @@ static void store_updated_refs(const char *url, struct ref *ref_map)\n \tconst char *what, *kind;\n \tstruct ref *rm;\n \n+\tfprintf(stderr, \"==> %s\\n\", url);\n+\n \tfp = fopen(git_path(\"FETCH_HEAD\"), \"a\");\n \tfor (rm = ref_map; rm; rm = rm->next) {\n \t\tstruct ref *ref = NULL;\n@@ -308,7 +304,7 @@ static void store_updated_refs(const char *url, struct ref *ref_map)\n \t\t\tnote);\n \n \t\tif (ref)\n-\t\t\tupdate_local_ref(ref, note, verbose);\n+\t\t\tupdate_local_ref(ref, what, verbose);\n \t}\n \tfclose(fp);\n }\n@@ -368,9 +364,6 @@ static struct ref *find_non_local_tags(struct transport *transport,\n \t\tif (!path_list_has_path(&existing_refs, ref_name) &&\n \t\t    !path_list_has_path(&new_refs, ref_name) &&\n \t\t    lookup_object(ref->old_sha1)) {\n-\t\t\tfprintf(stderr, \"Auto-following %s\\n\",\n-\t\t\t\tref_name);\n-\n \t\t\tpath_list_insert(ref_name, &new_refs);\n \n \t\t\trm = alloc_ref(strlen(ref_name) + 1);\n-- \n1.5.3.4.1252.g21baf-dirty\n"},{"id":"56527","messageId":"ee77f5c20710182339g30d025f0tfe74479d672ae36e@mail.gmail.com","threadId":"10376","inReplyTo":"20071019062219.GA28499@coredump.intra.peff.net","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2007-10-19T06:39:56Z","receivedAt":"2007-10-19T06:39:56Z","isPatch":true,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On 19/10/2007, Jeff King <peff@peff.net> wrote:\n> This makes the fetch output much more terse. It is likely to\n> be very controversial. Here's an example of the new output:\n>\n> Indexing objects: 100% (1061/1061), done.\n> Resolving deltas: 100% (638/638), done.\n> ==> git://repo.or.cz/git/spearce.git\n>  * branch gitk -> origin/gitk\n>  * branch maint -> origin/maint (fast forward)\n>  * branch master -> origin/master (fast forward)\n>  * branch next -> origin/next (fast forward)\n>  - branch pu -> origin/pu (non-fast forward, refused)\n>  * branch todo -> origin/todo (fast forward)\n> ==> git://repo.or.cz/git/spearce.git\n>  * tag v1.5.3.2 -> v1.5.3.2\n\nWhat about making it even more terse so it's even easier to visually\nscan: (mainly thinking that fast-forwarding is so common it could be\nconsidered the \"default\")\n\n> ==> git://repo.or.cz/git/spearce.git\n * gitk -> origin/gitk (new)\n * maint -> origin/maint\n * master -> origin/master\n * next -> origin/next\n - pu -> origin/pu (refused)\n * todo -> origin/todo\n==> git://repo.or.cz/git/spearce.git\n * tag v1.5.3.2\n\nAlso, perhaps the trailing notes (fast forward, refused, etc.) should\nbe significantly indented to the right to stand out even further from\nbranch names that might be quite long.\n\nDave.\n"},{"id":"56528","messageId":"20071019064620.GA28932@coredump.intra.peff.net","threadId":"10376","inReplyTo":"ee77f5c20710182339g30d025f0tfe74479d672ae36e@mail.gmail.com","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T06:46:20Z","receivedAt":"2007-10-19T06:46:20Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 19, 2007 at 04:39:56PM +1000, David Symonds wrote:\n\n> What about making it even more terse so it's even easier to visually\n> scan: (mainly thinking that fast-forwarding is so common it could be\n> considered the \"default\")\n\nReasonable. I think it would be easier to scan if the fields were\ncolumn-aligned, but that requires making a few passes, which would\nchange the current code quite a bit. Or we could just fake it and give\nit 20 characters for a branch name, padded with spaces.\n\n> > ==> git://repo.or.cz/git/spearce.git\n>  * gitk -> origin/gitk (new)\n\nI miss the \"branch\" designator, personally. I do like the \"new\" to\ndifferentiate from fast-forward.\n\n>  * maint -> origin/maint\n>  * master -> origin/master\n>  * next -> origin/next\n>  - pu -> origin/pu (refused)\n\nI think this needs to explain why it was refused (non-fast forward,\nrefused). And you may still have:\n\n * pu -> origin/pu (non-fast forward)\n\nfor forced updates.\n\n> ==> git://repo.or.cz/git/spearce.git\n>  * tag v1.5.3.2\n\nI am fine with that, as long as there aren't cases where we lose\ninformation (i.e., where the local and remote tag names differ).\n\n> Also, perhaps the trailing notes (fast forward, refused, etc.) should\n> be significantly indented to the right to stand out even further from\n> branch names that might be quite long.\n\nAgain, we could probably fake that by fixing the minimum column width of\nthe other fields.\n\n-Peff\n"},{"id":"56533","messageId":"20071019073938.GN14735@spearce.org","threadId":"10376","inReplyTo":"ee77f5c20710182339g30d025f0tfe74479d672ae36e@mail.gmail.com","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-19T07:39:39Z","receivedAt":"2007-10-19T07:39:39Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"David Symonds <dsymonds@gmail.com> wrote:\n> On 19/10/2007, Jeff King <peff@peff.net> wrote:\n> > This makes the fetch output much more terse. It is likely to\n> > be very controversial. Here's an example of the new output:\n> >\n> > Indexing objects: 100% (1061/1061), done.\n> > Resolving deltas: 100% (638/638), done.\n> > ==> git://repo.or.cz/git/spearce.git\n> >  * branch gitk -> origin/gitk\n> >  * branch maint -> origin/maint (fast forward)\n> >  * branch master -> origin/master (fast forward)\n> >  * branch next -> origin/next (fast forward)\n> >  - branch pu -> origin/pu (non-fast forward, refused)\n> >  * branch todo -> origin/todo (fast forward)\n> > ==> git://repo.or.cz/git/spearce.git\n> >  * tag v1.5.3.2 -> v1.5.3.2\n> \n> What about making it even more terse so it's even easier to visually\n> scan: (mainly thinking that fast-forwarding is so common it could be\n> considered the \"default\")\n\nWhat about this on top of Jeff's patch?\n\n$ git fetch jc\n...\n==> git://repo.or.cz/alt-git.git\n * tag junio-gpg-pub ......................... (new)\n * tag v1.5.0 .......................... (tag moved)\n\n$ git fetch me\n...\n==> git://repo.or.cz/git/spearce.git\n * branch gitk -> spearce/gitk ............... (new)\n * branch maint -> spearce/maint\n * branch master -> spearce/master\n * branch next -> spearce/next\n * branch pu -> spearce/pu ......... (forced update)\n * branch todo -> spearce/todo ............... (new)\n\nThe width of the terminal is computed to produce the ... padding.\nI used a very narrow terminal to produce the above so it doesn't\nlinewrap badly in email.  If we cannot get the terminal width then\nwe just don't produce the padding.\n\nWe also only show the URL once now, and only if at least one ref\nwas somehow changed.  This way we avoid showing the URL on a no-op\nor twice when we are fetching tags too.\n\n--8>--\ndiff --git a/builtin-fetch.c b/builtin-fetch.c\nindex 35fbfae..9d48f06 100644\n--- a/builtin-fetch.c\n+++ b/builtin-fetch.c\n@@ -14,6 +14,7 @@ static const char fetch_usage[] = \"git-fetch [-a | --append] [--upload-pack <upl\n static int append, force, tags, no_tags, update_head_ok, verbose, quiet;\n static char *default_rla = NULL;\n static struct transport *transport;\n+static int ws_cols, shown_url;\n \n static void unlock_pack(void)\n {\n@@ -143,6 +144,50 @@ static int s_update_ref(const char *action,\n \treturn 0;\n }\n \n+static void show_update(const char *status,\n+\t\tconst char *remote_name,\n+\t\tconst char *op,\n+\t\tconst char *local_name,\n+\t\tconst char *reason)\n+{\n+\tif (!shown_url) {\n+\t\tfprintf(stderr, \"==> %s\\n\", transport->url);\n+\t\tshown_url = 1;\n+\t}\n+\n+\tfputc(' ', stderr);\n+\tfputs(status, stderr);\n+\n+\tfputc(' ', stderr);\n+\tfputs(remote_name, stderr);\n+\n+\tif (op) {\n+\t\tfputc(' ', stderr);\n+\t\tfputs(op, stderr);\n+\t}\n+\n+\tif (local_name) {\n+\t\tfputc(' ', stderr);\n+\t\tfputs(local_name, stderr);\n+\t}\n+\n+\tif (reason) {\n+\t\tif (ws_cols) {\n+\t\t\tsize_t n = strlen(status) + strlen(remote_name) + 2;\n+\t\t\tif (op)\n+\t\t\t\tn += 1 + strlen(op);\n+\t\t\tif (local_name)\n+\t\t\t\tn += 1 + strlen(local_name);\n+\t\t\tn = ws_cols - n - strlen(reason) - 4;\n+\t\t\tfputc(' ', stderr);\n+\t\t\twhile (n--)\n+\t\t\t\tfputc('.', stderr);\n+\t\t}\n+\t\tfprintf(stderr, \" (%s)\", reason);\n+\t}\n+\tfputc('\\n', stderr);\n+}\n+\n static int update_local_ref(struct ref *ref,\n \t\t\t    const char *note,\n \t\t\t    int verbose)\n@@ -164,14 +209,13 @@ static int update_local_ref(struct ref *ref,\n \tif (!*ref->name) {\n \t\t/* Not storing */\n \t\tif (verbose)\n-\t\t\tfprintf(stderr, \" * branch %s -> FETCH_HEAD\\n\", note);\n+\t\t\tshow_update(\"* branch\", note, \"->\", \"FETCH_HEAD\", NULL);\n \t\treturn 0;\n \t}\n \n \tif (!hashcmp(ref->old_sha1, ref->new_sha1)) {\n \t\tif (verbose)\n-\t\t\tfprintf(stderr, \" - %s == %s\\n\",\n-\t\t\t\tnote, pretty_ref);\n+\t\t\tshow_update(\"-\", note, \"==\", pretty_ref, \"unchanged\");\n \t\treturn 0;\n \t}\n \n@@ -183,16 +227,14 @@ static int update_local_ref(struct ref *ref,\n \t\t * If this is the head, and it's not okay to update\n \t\t * the head, and the old value of the head isn't empty...\n \t\t */\n-\t\tfprintf(stderr,\n-\t\t\t\" - %s: Cannot fetch into the current branch.\\n\",\n-\t\t\tpretty_ref);\n+\t\tshow_update(\"-\", pretty_ref, NULL, NULL,\n+\t\t\t\"Cannot fetch into the current branch.\");\n \t\treturn 1;\n \t}\n \n \tif (!is_null_sha1(ref->old_sha1) &&\n \t    !prefixcmp(ref->name, \"refs/tags/\")) {\n-\t\tfprintf(stderr, \" * tag %s -> %s\\n\",\n-\t\t\tnote, pretty_ref);\n+\t\tshow_update(\"* tag\", note, NULL, NULL, \"tag moved\");\n \t\treturn s_update_ref(\"updating tag\", ref, 0);\n \t}\n \n@@ -200,17 +242,13 @@ static int update_local_ref(struct ref *ref,\n \tupdated = lookup_commit_reference(ref->new_sha1);\n \tif (!current || !updated) {\n \t\tconst char *msg;\n-\t\tconst char *what;\n \t\tif (!strncmp(ref->name, \"refs/tags/\", 10)) {\n-\t\t\tmsg = \"storing tag\";\n-\t\t\twhat = \"tag\";\n-\t\t}\n-\t\telse {\n-\t\t\tmsg = \"storing head\";\n-\t\t\twhat = \"branch\";\n+\t\t\tmsg = \"storing new tag\";\n+\t\t\tshow_update(\"* tag\", note, NULL, NULL, \"new\");\n+\t\t} else {\n+\t\t\tmsg = \"storing new head\";\n+\t\t\tshow_update(\"* branch\", note, \"->\", pretty_ref, \"new\");\n \t\t}\n-\t\tfprintf(stderr, \" * %s %s -> %s\\n\",\n-\t\t\twhat, note, pretty_ref);\n \t\treturn s_update_ref(msg, ref, 0);\n \t}\n \n@@ -218,19 +256,14 @@ static int update_local_ref(struct ref *ref,\n \tstrcpy(newh, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV));\n \n \tif (in_merge_bases(current, &updated, 1)) {\n-\t\tfprintf(stderr, \" * branch %s -> %s (fast forward)\\n\",\n-\t\t\tnote, pretty_ref);\n+\t\tshow_update(\"* branch\", note, \"->\", pretty_ref, NULL);\n \t\treturn s_update_ref(\"fast forward\", ref, 1);\n \t}\n \tif (!force && !ref->force) {\n-\t\tfprintf(stderr,\n-\t\t\t\" - branch %s -> %s (non-fast forward, refused)\\n\",\n-\t\t\tnote, pretty_ref);\n+\t\tshow_update(\"- branch\", note, \"->\", pretty_ref, \"non-fast forward, refused\");\n \t\treturn 1;\n \t}\n-\tfprintf(stderr,\n-\t\t\" * branch %s -> %s (non-fast forward)\\n\",\n-\t\tnote, pretty_ref);\n+\tshow_update(\"* branch\", note, \"->\", pretty_ref, \"forced update\");\n \treturn s_update_ref(\"forced-update\", ref, 1);\n }\n \n@@ -243,8 +276,6 @@ static void store_updated_refs(const char *url, struct ref *ref_map)\n \tconst char *what, *kind;\n \tstruct ref *rm;\n \n-\tfprintf(stderr, \"==> %s\\n\", url);\n-\n \tfp = fopen(git_path(\"FETCH_HEAD\"), \"a\");\n \tfor (rm = ref_map; rm; rm = rm->next) {\n \t\tstruct ref *ref = NULL;\n@@ -440,6 +471,13 @@ static void set_option(const char *name, const char *value)\n \t\t\tname, transport->url);\n }\n \n+static void determine_window_size(void)\n+{\n+\tstruct winsize ws;\n+\tif (!ioctl(2, TIOCGWINSZ, &ws))\n+\t\tws_cols = ws.ws_col;\n+}\n+\n int cmd_fetch(int argc, const char **argv, const char *prefix)\n {\n \tstruct remote *remote;\n@@ -565,6 +603,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)\n \t\tref_nr = j;\n \t}\n \n+\tdetermine_window_size();\n \tsignal(SIGINT, unlock_pack_on_signal);\n \tatexit(unlock_pack);\n \treturn do_fetch(transport, parse_ref_spec(ref_nr, refs), ref_nr);\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex f23d934..e823aca 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -44,6 +44,7 @@\n #include <limits.h>\n #include <sys/param.h>\n #include <sys/types.h>\n+#include <sys/ioctl.h>\n #include <dirent.h>\n #include <sys/time.h>\n #include <time.h>\n\n-- \nShawn.\n"},{"id":"56535","messageId":"20071019075725.GA29436@coredump.intra.peff.net","threadId":"10376","inReplyTo":"20071019073938.GN14735@spearce.org","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T07:57:25Z","receivedAt":"2007-10-19T07:57:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 19, 2007 at 03:39:39AM -0400, Shawn O. Pearce wrote:\n\n> What about this on top of Jeff's patch?\n> \n> $ git fetch jc\n> ...\n> ==> git://repo.or.cz/alt-git.git\n>  * tag junio-gpg-pub ......................... (new)\n>  * tag v1.5.0 .......................... (tag moved)\n\nHonestly, I find it a bit ugly with the dots.\n\n> $ git fetch me\n> ...\n> ==> git://repo.or.cz/git/spearce.git\n>  * branch gitk -> spearce/gitk ............... (new)\n>  * branch maint -> spearce/maint\n>  * branch master -> spearce/master\n>  * branch next -> spearce/next\n>  * branch pu -> spearce/pu ......... (forced update)\n>  * branch todo -> spearce/todo ............... (new)\n\nMore so with the ragged right of the branch names. I think it would\nprobably look better to line up the columns, but that will eventually\nlook ugly when somebody tries to fetch sp/totally-annoying-branchname.\n\nI also think having the dots for some lines and others looks awkward.\n\n> The width of the terminal is computed to produce the ... padding.\n> I used a very narrow terminal to produce the above so it doesn't\n> linewrap badly in email.  If we cannot get the terminal width then\n> we just don't produce the padding.\n\nUgh. I strongly suspect that it would look ugly on anything bigger than\nabout 80 columns, anyway. You are probably better off just not worrying\nabout the terminal width, and always using an 80-ish column total. And\nthen you don't have to worry about the ugly ioctl call.\n\n> We also only show the URL once now, and only if at least one ref\n> was somehow changed.  This way we avoid showing the URL on a no-op\n> or twice when we are fetching tags too.\n\nMuch nicer, and I like the refactoring into a separate show_update\nfunction (especially if somebody ends up adding color later).\n\n> +\t\t\tshow_update(\"* branch\", note, \"->\", \"FETCH_HEAD\", NULL);\n\nHrm, btw, I can't seem to get this one to show (I was curious how ugly\nthe FETCH_HEAD would look).\n\n>  \t\tif (verbose)\n> -\t\t\tfprintf(stderr, \" - %s == %s\\n\",\n> -\t\t\t\tnote, pretty_ref);\n> +\t\t\tshow_update(\"-\", note, \"==\", pretty_ref, \"unchanged\");\n>  \t\treturn 0;\n\nAlso, I was unable to generate a test case that showed this one. Did\nyou?\n\n> -\t\t\tmsg = \"storing tag\";\n> [...]\n> +\t\t\tmsg = \"storing new tag\";\n\nNice.\n\n> +\t\tshow_update(\"- branch\", note, \"->\", pretty_ref, \"non-fast forward, refused\");\n\nLine wrap?\n\n> +static void determine_window_size(void)\n> +{\n> +\tstruct winsize ws;\n> +\tif (!ioctl(2, TIOCGWINSZ, &ws))\n> +\t\tws_cols = ws.ws_col;\n> +}\n> +\n\nUgh. How portable is this?\n\n-Peff\n"},{"id":"56538","messageId":"20071019080755.GO14735@spearce.org","threadId":"10376","inReplyTo":"20071019075725.GA29436@coredump.intra.peff.net","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-19T08:07:55Z","receivedAt":"2007-10-19T08:07:55Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jeff King <peff@peff.net> wrote:\n> On Fri, Oct 19, 2007 at 03:39:39AM -0400, Shawn O. Pearce wrote:\n> \n> > What about this on top of Jeff's patch?\n> > \n> > $ git fetch jc\n> > ...\n> > ==> git://repo.or.cz/alt-git.git\n> >  * tag junio-gpg-pub ......................... (new)\n> >  * tag v1.5.0 .......................... (tag moved)\n> \n> Ugh. I strongly suspect that it would look ugly on anything bigger than\n> about 80 columns, anyway. You are probably better off just not worrying\n> about the terminal width, and always using an 80-ish column total. And\n> then you don't have to worry about the ugly ioctl call.\n\nThen you get linewrap on smaller terminals, and bigger ones don't\nline up the right side.  *shrug*\n \n> > +\t\t\tshow_update(\"* branch\", note, \"->\", \"FETCH_HEAD\", NULL);\n> \n> Hrm, btw, I can't seem to get this one to show (I was curious how ugly\n> the FETCH_HEAD would look).\n\nYea, I can't easily see how to get this to generate.\n \n> >  \t\tif (verbose)\n> > -\t\t\tfprintf(stderr, \" - %s == %s\\n\",\n> > -\t\t\t\tnote, pretty_ref);\n> > +\t\t\tshow_update(\"-\", note, \"==\", pretty_ref, \"unchanged\");\n> >  \t\treturn 0;\n> \n> Also, I was unable to generate a test case that showed this one. Did\n> you?\n\ngit fetch -v jc\n\n> > +static void determine_window_size(void)\n> > +{\n> > +\tstruct winsize ws;\n> > +\tif (!ioctl(2, TIOCGWINSZ, &ws))\n> > +\t\tws_cols = ws.ws_col;\n> > +}\n> > +\n> \n> Ugh. How portable is this?\n\nNo clue.  It compiles fine here on Mac OS X and on Linux, but those\nare both reasonably modern UNIX systems.  Older systems like Solaris\n8 or an ancient OpenBSD might have an issue.  I suspect though that\nthis is a reasonably standard thing but its not in POSIX so uh,\nprobably a bad thing to do.\n\n-- \nShawn.\n"},{"id":"56539","messageId":"20071019081127.GA30168@coredump.intra.peff.net","threadId":"10376","inReplyTo":"20071019080755.GO14735@spearce.org","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T08:11:28Z","receivedAt":"2007-10-19T08:11:28Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 19, 2007 at 04:07:55AM -0400, Shawn O. Pearce wrote:\n\n> Then you get linewrap on smaller terminals, and bigger ones don't\n> line up the right side.  *shrug*\n\nBigger ones will line up, just not on the far right side of the\nterminal. I guess we ought to support smaller terminals, though).\n\n> > > +\t\t\tshow_update(\"* branch\", note, \"->\", \"FETCH_HEAD\", NULL);\n> > Hrm, btw, I can't seem to get this one to show (I was curious how ugly\n> > the FETCH_HEAD would look).\n> Yea, I can't easily see how to get this to generate.\n\nI thought \"git-fetch bare_url\" would do it, since then we have no\nremote fetchspec to look up, but it doesn't.\n\n> > Also, I was unable to generate a test case that showed this one. Did\n> > you?\n> git fetch -v jc\n\nAh, thanks.\n\n-Peff\n"},{"id":"56542","messageId":"864pgncy9y.fsf@lola.quinscape.zz","threadId":"10376","inReplyTo":"2007101\u00049081127.GA30168@coredump.intra.peff.net","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-19T08:19:05Z","receivedAt":"2007-10-19T08:19:05Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Fri, Oct 19, 2007 at 04:07:55AM -0400, Shawn O. Pearce wrote:\n>\n>> Then you get linewrap on smaller terminals, and bigger ones don't\n>> line up the right side.  *shrug*\n>\n> Bigger ones will line up, just not on the far right side of the\n> terminal. I guess we ought to support smaller terminals, though).\n\nI don't see why.  80 columns has been the standard layout for\nsomething like 40 or 50 years or so.  It is the standard punch card\nwidth and required to display Fortran code fitted to this width\n(column 73 to 80 are ignored in non-free-format Fortran and used for\nline identification).\n\nAll people using smaller terminals are used to wrapping trouble.  We\nreally don't need to go overboard supporting Commodore 64 users with\ngit.\n\n-- \nDavid Kastrup\n"},{"id":"56541","messageId":"471868FC.20409@viscovery.net","threadId":"10376","inReplyTo":"20071019073938.GN14735@spearce.org","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-10-19T08:21:16Z","receivedAt":"2007-10-19T08:21:16Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Shawn O. Pearce schrieb:\n> $ git fetch jc\n> ...\n> ==> git://repo.or.cz/alt-git.git\n>  * tag junio-gpg-pub ......................... (new)\n>  * tag v1.5.0 .......................... (tag moved)\n> \n> $ git fetch me\n> ...\n> ==> git://repo.or.cz/git/spearce.git\n>  * branch gitk -> spearce/gitk ............... (new)\n>  * branch maint -> spearce/maint\n>  * branch master -> spearce/master\n>  * branch next -> spearce/next\n>  * branch pu -> spearce/pu ......... (forced update)\n>  * branch todo -> spearce/todo ............... (new)\n> \n> The width of the terminal is computed to produce the ... padding.\n\nI like the wording of the status tags.\n\nBut the padding does not convince me. How does this look on very wide\nterminals? Maybe use 80 as a maximum?\n\n> +\t\tif (ws_cols) {\n> +\t\t\tsize_t n = strlen(status) + strlen(remote_name) + 2;\n> +\t\t\tif (op)\n> +\t\t\t\tn += 1 + strlen(op);\n> +\t\t\tif (local_name)\n> +\t\t\t\tn += 1 + strlen(local_name);\n> +\t\t\tn = ws_cols - n - strlen(reason) - 4;\n> +\t\t\tfputc(' ', stderr);\n> +\t\t\twhile (n--)\n> +\t\t\t\tfputc('.', stderr);\n\n\t\t\twhile (n-- > 0)\n\notherwise you're screwed if your terminal is too narrow.\n\n> +static void determine_window_size(void)\n> +{\n\n#ifdef TIOCGWINSZ\n\n> +\tstruct winsize ws;\n> +\tif (!ioctl(2, TIOCGWINSZ, &ws))\n> +\t\tws_cols = ws.ws_col;\n\n#endif\n\n> +}\n\nPretty please. We don't have TIOCGWINSZ on Windows.\n\n-- Hannes\n"},{"id":"56546","messageId":"20071019083957.GA32400@coredump.intra.peff.net","threadId":"10376","inReplyTo":"864pgncy9y.fsf@lola.quinscape.zz","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T08:39:57Z","receivedAt":"2007-10-19T08:39:57Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 19, 2007 at 10:19:05AM +0200, David Kastrup wrote:\n\n> I don't see why.  80 columns has been the standard layout for\n> something like 40 or 50 years or so.  It is the standard punch card\n> width and required to display Fortran code fitted to this width\n> (column 73 to 80 are ignored in non-free-format Fortran and used for\n> line identification).\n\nI almost said that, but it seems unnecessarily restrictive. Do people\nuse git on handhelds (or use them to connect to decent machines that run\ngit)? If it's related to the actual functioning of the program, then\nfine, but it seems unnecessarily strict for something that is just eye\ncandy anyway.\n\n> All people using smaller terminals are used to wrapping trouble.  We\n\nThat is a good point...people on tiny screens are likely to be wrapping\non the _other_ lines anyway. I wonder how awful our progress meters look\non a tiny terminal.\n\nReally, I'm fine with assuming an 80 char terminal. I just didn't want\nto be in the position of defending it as a useful feature when somebody\ncomplained.\n\n-Peff\n"},{"id":"56552","messageId":"8aa486160710190303l4ce996daqf5c8025c857ea8@mail.gmail.com","threadId":"10376","inReplyTo":"20071019073938.GN14735@spearce.org","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-10-19T10:03:24Z","receivedAt":"2007-10-19T10:03:24Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"Another possibility is with just some minor reductions from the\ncurrent output, as:\n\n$ git fetch spearce\n...\nFrom git://repo.or.cz/git/spearce\n* spearce/gitk: fast forward to branch 'gitk'\n  old..new: 0d6df4d..2b5afb7\n* spearce/maint: fast forward to branch 'maint'\n  old..new: 1aa3d01..e7187e4\n* spearce/master: fast forward to branch 'master'\n  old..new: de61e42..7840ce6\n* spearce/next: fast forward to branch 'next'\n  old..new: 895be02..2fe5433\n* spearce/pu: forcing update to non-fast forward branch 'pu'\n  old...new: 89fa332...1e4c517\n\nThis way it is slightly less terse than the other proposals but not\nthat cryptic and it normally fits in one line without padding. And I\nreally like to see what has changed explicitly with the old..new line.\n\n  Santi\n"},{"id":"56553","messageId":"47188990.1040606@op5.se","threadId":"10376","inReplyTo":"20071019062219.GA28499@coredump.intra.peff.net","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-19T10:40:16Z","receivedAt":"2007-10-19T10:40:16Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jeff King wrote:\n>   - we abbreviate the local refs (chopping refs/heads,\n>     refs/tags, refs/remotes). This means we're losing\n>     information, but hopefully it is obvious when storing\n>     \"origin/master\" that it is in refs/remotes.\n\nI like this, since \"origin/master\" is how that branch is supposed to\nbe used.\n\n\n>   - fast forward information goes at the end\n>   - cut out \"Auto-following ...\" text\n> \n> What do people think? Some changes? All?\n> \n\nPossibly re-listing \"refused\" messages last so users who pull from\nrepos with a huge amount of branches can see it at the bottom.\n\n> Other questions:\n>   - Is the \"==>\" too ugly? It needs to be short (many urls\n>     are almost 80 characters already), and it needs to stand\n>     out from the \"resolving deltas\" line, so I think some\n>     symbol is reasonable.\n\nSkip the marker altogether and indent the output two spaces.\n\n>   - Should we omit \"(fast forward)\" since it is the usual\n>     case?\n\nI think so, yes, or perhaps just shorten it to 'ff' so the 'refused' and\n'merged' messages stand out a bit more.\n\n>   - Should refs/remotes/* keep the \"remotes/\" part?\n\nI think not. It's used as origin/master (by end-users anyways), so writing\nwhat they're familiar with is most likely the correct thing to do.\n\n>   - How annoying is the doubled '==> $url' line? It comes\n>     from the fact that we fetch the tags separately.\n> \n\nFairly annoying. I'd prefer if it was squelched the second time.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"56554","messageId":"47188AC1.9010006@op5.se","threadId":"10376","inReplyTo":"20071019073938.GN14735@spearce.org","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-19T10:45:21Z","receivedAt":"2007-10-19T10:45:21Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n> \n> What about this on top of Jeff's patch?\n> \n> $ git fetch jc\n> ...\n> ==> git://repo.or.cz/alt-git.git\n>  * tag junio-gpg-pub ......................... (new)\n>  * tag v1.5.0 .......................... (tag moved)\n> \n> $ git fetch me\n> ...\n> ==> git://repo.or.cz/git/spearce.git\n>  * branch gitk -> spearce/gitk ............... (new)\n>  * branch maint -> spearce/maint\n>  * branch master -> spearce/master\n>  * branch next -> spearce/next\n>  * branch pu -> spearce/pu ......... (forced update)\n>  * branch todo -> spearce/todo ............... (new)\n> \n> The width of the terminal is computed to produce the ... padding.\n> I used a very narrow terminal to produce the above so it doesn't\n> linewrap badly in email.  If we cannot get the terminal width then\n> we just don't produce the padding.\n> \n\nMelikes, although using a fairly narrow padding isn't necessarily\na bad idea. I usually hate it when the output on the left is 15 chars\nwide, the one on the right is 5-10 chars wide and there are 60 dots\nbetween them. It's ugly and doesn't make it a easier to read.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"56556","messageId":"47188C1A.2090600@op5.se","threadId":"10376","inReplyTo":"20071019073938.GN14735@spearce.org","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-19T10:51:06Z","receivedAt":"2007-10-19T10:51:06Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n>  \n> +static void determine_window_size(void)\n> +{\n> +\tstruct winsize ws;\n> +\tif (!ioctl(2, TIOCGWINSZ, &ws))\n> +\t\tws_cols = ws.ws_col;\n> +}\n> +\n\nI'd suggest re-using term_columns() from help.c instead. It's been in there\nsince the git wrapper was rewritten in C, so it's had a bit of testing and\nseems to work fairly well.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"56560","messageId":"20071019113822.GB16726@thunk.org","threadId":"10376","inReplyTo":"8aa486160710190303l4ce996daqf5c8025c857ea8@mail.gmail.com","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Theodore Tso","fromEmail":"tytso@thunk.org","sentAt":"2007-10-19T11:38:22Z","receivedAt":"2007-10-19T11:38:22Z","isPatch":true,"sender":{"key":"tytso@thunk.org","avatar":"https://gravatar.com/avatar/bc16cd364de8c963cca27953f33db8cd94de51b67922a7697620d8512a05ab01?d=mp&s=160"},"body":"On Fri, Oct 19, 2007 at 12:03:24PM +0200, Santi Béjar wrote:\n> This way it is slightly less terse than the other proposals but not\n> that cryptic and it normally fits in one line without padding. And I\n> really like to see what has changed explicitly with the old..new line.\n\nSame here.\n\nI find the old..new information occasionally useful, since it allows\nme to do the git diff --- something for which ORIG_HEAD isn't enough\nwhen you are pulling multiple heads, such as in git.  Can we keep that\noptional via a config or an command-line option?\n\nHmm... how about this?\n\n==> git://repo.or.cz/git/spearce.git\n * branch gitk -> spearce/gitk\t\t(new)\n * branch maint -> spearce/maint\t1aa3d01..e7187e4\n * branch master -> spearce/master\tde61e42..7840ce6\n * branch next -> spearce/next\t\t895be02..2fe5433\n + branch pu -> spearce/pu\t\t89fa332...1e4c517\n * branch todo -> spearce/todo\t\t(new)\n\nIf the branch is new, obviously old..new won't be useful.  The\nnon-fast forward branch is getting indicated twice, once with the \"+\"\nsign, and once with the triple dot in the range.   \n\nAs far as the padding, it would be a pain to figure out how to make\nthe right hand column be padded so that it starts 3 spaces after the\nlongest \"  * branch foo -> bar\" line, but that would look the best.\n\nFinally, one last question --- am I the only one who had to take a\nsecond look at the whether the arrow should be <- or ->?  The question\nis whether we are saying \"gitk is moving to include all of\nspearce/gitk\"; but I could also see it stated that we are assigning\nrefs/heads/gitk with refs/remotes/spearce/gitk, in which case the\narrow should be reversed.   Or maybe:\n\n==> git://repo.or.cz/git/spearce.git\n * branch gitk := spearce/gitk\t\t(new)\n * branch maint := spearce/maint\t1aa3d01..e7187e4\n * branch master := spearce/master\tde61e42..7840ce6\n * branch next := spearce/next\t\t895be02..2fe5433\n + branch pu := spearce/pu\t\t89fa332...1e4c517\n * branch todo := spearce/todo\t\t(new)\n\n(Or is that too Pascal-like?  :-)\n\n      \t       \t    \t       \t      \t  \t   - Ted\n"},{"id":"56568","messageId":"4718A3AB.7090301@viscovery.net","threadId":"10376","inReplyTo":"20071019113822.GB16726@thunk.org","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-10-19T12:31:39Z","receivedAt":"2007-10-19T12:31:39Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Theodore Tso schrieb:\n> ==> git://repo.or.cz/git/spearce.git\n>  * branch gitk -> spearce/gitk\t\t(new)\n>  * branch maint -> spearce/maint\t1aa3d01..e7187e4\n>  * branch master -> spearce/master\tde61e42..7840ce6\n>  * branch next -> spearce/next\t\t895be02..2fe5433\n>  + branch pu -> spearce/pu\t\t89fa332...1e4c517\n>  * branch todo -> spearce/todo\t\t(new)\n\n> As far as the padding, it would be a pain to figure out how to make\n> the right hand column be padded so that it starts 3 spaces after the\n> longest \"  * branch foo -> bar\" line, but that would look the best.\n\nBut this way it wouldn't be difficult at all:\n\n==> git://repo.or.cz/git/spearce.git\n  * (new)              gitk -> spearce/gitk\n  * 1aa3d01..e7187e4   maint -> spearce/maint\n  * de61e42..7840ce6   master -> spearce/master\n  * 895be02..2fe5433   next -> spearce/next\n  + 89fa332...1e4c517  pu -> spearce/pu\n  * (new)              todo -> spearce/todo\n\n(I don't know where to put the label 'branch'.)\n\nBTW, I like the ID ranges, too, and have used the information\noccasionally.\n\n-- Hannes\n"},{"id":"56570","messageId":"alpine.LFD.0.9999.0710190859400.19446@xanadu.home","threadId":"10376","inReplyTo":"20071019073938.GN14735@spearce.org","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T13:05:08Z","receivedAt":"2007-10-19T13:05:08Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 19 Oct 2007, Shawn O. Pearce wrote:\n\n> What about this on top of Jeff's patch?\n> \n> $ git fetch jc\n> ...\n> ==> git://repo.or.cz/alt-git.git\n>  * tag junio-gpg-pub ......................... (new)\n>  * tag v1.5.0 .......................... (tag moved)\n> \n> $ git fetch me\n> ...\n> ==> git://repo.or.cz/git/spearce.git\n>  * branch gitk -> spearce/gitk ............... (new)\n>  * branch maint -> spearce/maint\n>  * branch master -> spearce/master\n>  * branch next -> spearce/next\n>  * branch pu -> spearce/pu ......... (forced update)\n>  * branch todo -> spearce/todo ............... (new)\n> \n> The width of the terminal is computed to produce the ... padding.\n> I used a very narrow terminal to produce the above so it doesn't\n> linewrap badly in email.  If we cannot get the terminal width then\n> we just don't produce the padding.\n\nI like it.\n\nI would change the '*' to a '+' for a forced update (for similarity with \nthe + notation in refspecs), and a '!' instead of a '-' for refused \nupdate which might be more indicative of a refusal.\n\n\nNicolas\n"},{"id":"56571","messageId":"alpine.LFD.0.9999.0710190913280.19446@xanadu.home","threadId":"10376","inReplyTo":"8aa486160710190303l4ce996daqf5c8025c857ea8@mail.gmail.com","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T13:15:26Z","receivedAt":"2007-10-19T13:15:26Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 19 Oct 2007, Santi Béjar wrote:\n\n> Another possibility is with just some minor reductions from the\n> current output, as:\n> \n> $ git fetch spearce\n> ...\n> >From git://repo.or.cz/git/spearce\n> * spearce/gitk: fast forward to branch 'gitk'\n>   old..new: 0d6df4d..2b5afb7\n> * spearce/maint: fast forward to branch 'maint'\n>   old..new: 1aa3d01..e7187e4\n> * spearce/master: fast forward to branch 'master'\n>   old..new: de61e42..7840ce6\n> * spearce/next: fast forward to branch 'next'\n>   old..new: 895be02..2fe5433\n> * spearce/pu: forcing update to non-fast forward branch 'pu'\n>   old...new: 89fa332...1e4c517\n> \n> This way it is slightly less terse than the other proposals but not\n> that cryptic and it normally fits in one line without padding. And I\n> really like to see what has changed explicitly with the old..new line.\n\nI think the advantage of having only one line of output per branch \nreally outweight the need for old..new notation.  Do you really benefit \nfrom it?\n\n\nNicolas\n"},{"id":"56582","messageId":"alpine.LFD.0.9999.0710191009330.19446@xanadu.home","threadId":"10376","inReplyTo":"4718A3AB.7090301@viscovery.net","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T14:14:59Z","receivedAt":"2007-10-19T14:14:59Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 19 Oct 2007, Johannes Sixt wrote:\n\n> Theodore Tso schrieb:\n> > ==> git://repo.or.cz/git/spearce.git\n> >  * branch gitk -> spearce/gitk\t\t(new)\n> >  * branch maint -> spearce/maint\t1aa3d01..e7187e4\n> >  * branch master -> spearce/master\tde61e42..7840ce6\n> >  * branch next -> spearce/next\t\t895be02..2fe5433\n> >  + branch pu -> spearce/pu\t\t89fa332...1e4c517\n> >  * branch todo -> spearce/todo\t\t(new)\n> \n> > As far as the padding, it would be a pain to figure out how to make\n> > the right hand column be padded so that it starts 3 spaces after the\n> > longest \"  * branch foo -> bar\" line, but that would look the best.\n> \n> But this way it wouldn't be difficult at all:\n> \n> ==> git://repo.or.cz/git/spearce.git\n>  * (new)              gitk -> spearce/gitk\n>  * 1aa3d01..e7187e4   maint -> spearce/maint\n>  * de61e42..7840ce6   master -> spearce/master\n>  * 895be02..2fe5433   next -> spearce/next\n>  + 89fa332...1e4c517  pu -> spearce/pu\n>  * (new)              todo -> spearce/todo\n\nActually I think this is the best format so far: one line per branch, no \nterminal width issue (long branch names are simply wrapped), the \nold..new info is there also with the single character marker to quickly \nnotice the type of update.\n\n\nNicolas\n"},{"id":"56585","messageId":"Pine.LNX.4.64.0710191630180.16728@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"10376","inReplyTo":"alpine.LFD.0.9999.0710191009330.19446@xanadu.home","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-19T14:31:00Z","receivedAt":"2007-10-19T14:31:00Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 19 Oct 2007, Nicolas Pitre wrote:\n\n> On Fri, 19 Oct 2007, Johannes Sixt wrote:\n> \n> > ==> git://repo.or.cz/git/spearce.git\n> >  * (new)              gitk -> spearce/gitk\n> >  * 1aa3d01..e7187e4   maint -> spearce/maint\n> >  * de61e42..7840ce6   master -> spearce/master\n> >  * 895be02..2fe5433   next -> spearce/next\n> >  + 89fa332...1e4c517  pu -> spearce/pu\n> >  * (new)              todo -> spearce/todo\n> \n> Actually I think this is the best format so far: one line per branch, no \n> terminal width issue (long branch names are simply wrapped), the \n> old..new info is there also with the single character marker to quickly \n> notice the type of update.\n\nYes.  Definitely my favourite so far, too.\n\nCiao,\nDscho\n"},{"id":"56586","messageId":"8aa486160710190731v67626fd8wa94ba069a17f73ce@mail.gmail.com","threadId":"10376","inReplyTo":"alpine.LFD.0.9999.0710191009330.19446@xanadu.home","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-10-19T14:31:08Z","receivedAt":"2007-10-19T14:31:08Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 10/19/07, Nicolas Pitre <nico@cam.org> wrote:\n> On Fri, 19 Oct 2007, Johannes Sixt wrote:\n>\n> > Theodore Tso schrieb:\n> > > ==> git://repo.or.cz/git/spearce.git\n> > >  * branch gitk -> spearce/gitk              (new)\n> > >  * branch maint -> spearce/maint    1aa3d01..e7187e4\n> > >  * branch master -> spearce/master  de61e42..7840ce6\n> > >  * branch next -> spearce/next              895be02..2fe5433\n> > >  + branch pu -> spearce/pu          89fa332...1e4c517\n> > >  * branch todo -> spearce/todo              (new)\n> >\n> > > As far as the padding, it would be a pain to figure out how to make\n> > > the right hand column be padded so that it starts 3 spaces after the\n> > > longest \"  * branch foo -> bar\" line, but that would look the best.\n> >\n> > But this way it wouldn't be difficult at all:\n> >\n> > ==> git://repo.or.cz/git/spearce.git\n> >  * (new)              gitk -> spearce/gitk\n> >  * 1aa3d01..e7187e4   maint -> spearce/maint\n> >  * de61e42..7840ce6   master -> spearce/master\n> >  * 895be02..2fe5433   next -> spearce/next\n> >  + 89fa332...1e4c517  pu -> spearce/pu\n> >  * (new)              todo -> spearce/todo\n>\n> Actually I think this is the best format so far: one line per branch, no\n> terminal width issue (long branch names are simply wrapped), the\n> old..new info is there also with the single character marker to quickly\n> notice the type of update.\n\nI like it too. I would like to add some more descripton, because I\nthink for newbies the .. and ... can be overlooked. Something like:\n\n$ git fetch spearce\n...\nURL: git://repo.or.cz/git/spearce.git\n * (new)              spearce/gitk: new branch 'gitk'\n * 1aa3d01..e7187e4   spearce/maint: fast forward to branch 'maint'\n * de61e42..7840ce6   spearce/master: fast forward to branch 'master'\n * 895be02..2fe5433   spearce/next: fast forward to branch 'next'\n + 89fa332...1e4c517  spearce/pu: forcing update to non-fast forward branch 'pu'\n * (new)              spearce/todo: new branch spearce/todo\n\nI would also put 'URL:' instead '==>'.\n\nSanti\n"},{"id":"56587","messageId":"20071019143844.GB23765@diana.vm.bytemark.co.uk","threadId":"10376","inReplyTo":"20071019113822.GB16726@thunk.org","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-10-19T14:38:44Z","receivedAt":"2007-10-19T14:38:44Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-10-19 07:38:22 -0400, Theodore Tso wrote:\n\n> Finally, one last question --- am I the only one who had to take a\n> second look at the whether the arrow should be <- or ->? The\n> question is whether we are saying \"gitk is moving to include all of\n> spearce/gitk\"; but I could also see it stated that we are assigning\n> refs/heads/gitk with refs/remotes/spearce/gitk, in which case the\n> arrow should be reversed. Or maybe:\n>\n> ==> git://repo.or.cz/git/spearce.git\n>  * branch gitk := spearce/gitk                (new)\n>  * branch maint := spearce/maint              1aa3d01..e7187e4\n>  * branch master := spearce/master            de61e42..7840ce6\n>  * branch next := spearce/next                895be02..2fe5433\n>  + branch pu := spearce/pu                    89fa332...1e4c517\n>  * branch todo := spearce/todo                (new)\n\nI think the reasoning behind the \"foo -> spearce/foo\" syntax is that\n\"(refs/heads/)foo\" in the remote repository has been fetched to\n\"(refs/remotes/)spearce/foo\" in the local repository.\n\nI might be deluded, though.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"56589","messageId":"20071019144015.GC23765@diana.vm.bytemark.co.uk","threadId":"10376","inReplyTo":"8aa486160710190731v67626fd8wa94ba069a17f73ce@mail.gmail.com","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-10-19T14:40:15Z","receivedAt":"2007-10-19T14:40:15Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-10-19 16:31:08 +0200, Santi Béjar wrote:\n\n> I would also put 'URL:' instead '==>'.\n\nSeconded.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"56588","messageId":"4718C1DE.5030708@viscovery.net","threadId":"10376","inReplyTo":"8aa486160710190731v67626fd8wa94ba069a17f73ce@mail.gmail.com","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-10-19T14:40:30Z","receivedAt":"2007-10-19T14:40:30Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Santi Béjar schrieb:\n> On 10/19/07, Nicolas Pitre <nico@cam.org> wrote:\n>> On Fri, 19 Oct 2007, Johannes Sixt wrote:\n>>> ==> git://repo.or.cz/git/spearce.git\n>>>  * (new)              gitk -> spearce/gitk\n>>>  * 1aa3d01..e7187e4   maint -> spearce/maint\n>>>  * de61e42..7840ce6   master -> spearce/master\n>>>  * 895be02..2fe5433   next -> spearce/next\n>>>  + 89fa332...1e4c517  pu -> spearce/pu\n>>>  * (new)              todo -> spearce/todo\n> \n> I like it too. I would like to add some more descripton, because I\n> think for newbies the .. and ... can be overlooked.\n\nThe '*' could go away, then the '+' is more visible.\n\n-- Hanes\n"},{"id":"56590","messageId":"Pine.LNX.4.64.0710191640250.16728@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"10376","inReplyTo":"8aa486160710190731v67626fd8wa94ba069a17f73ce@mail.gmail.com","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-19T14:41:07Z","receivedAt":"2007-10-19T14:41:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 19 Oct 2007, Santi B?jar wrote:\n\n> On 10/19/07, Nicolas Pitre <nico@cam.org> wrote:\n> > On Fri, 19 Oct 2007, Johannes Sixt wrote:\n> >\n> > > Theodore Tso schrieb:\n> > > > ==> git://repo.or.cz/git/spearce.git\n> > > >  * branch gitk -> spearce/gitk              (new)\n> > > >  * branch maint -> spearce/maint    1aa3d01..e7187e4\n> > > >  * branch master -> spearce/master  de61e42..7840ce6\n> > > >  * branch next -> spearce/next              895be02..2fe5433\n> > > >  + branch pu -> spearce/pu          89fa332...1e4c517\n> > > >  * branch todo -> spearce/todo              (new)\n> > >\n> > > > As far as the padding, it would be a pain to figure out how to make\n> > > > the right hand column be padded so that it starts 3 spaces after the\n> > > > longest \"  * branch foo -> bar\" line, but that would look the best.\n> > >\n> > > But this way it wouldn't be difficult at all:\n> > >\n> > > ==> git://repo.or.cz/git/spearce.git\n> > >  * (new)              gitk -> spearce/gitk\n> > >  * 1aa3d01..e7187e4   maint -> spearce/maint\n> > >  * de61e42..7840ce6   master -> spearce/master\n> > >  * 895be02..2fe5433   next -> spearce/next\n> > >  + 89fa332...1e4c517  pu -> spearce/pu\n> > >  * (new)              todo -> spearce/todo\n> >\n> > Actually I think this is the best format so far: one line per branch, no\n> > terminal width issue (long branch names are simply wrapped), the\n> > old..new info is there also with the single character marker to quickly\n> > notice the type of update.\n> \n> I like it too. I would like to add some more descripton, because I\n> think for newbies the .. and ... can be overlooked. Something like:\n> \n> $ git fetch spearce\n> ...\n> URL: git://repo.or.cz/git/spearce.git\n>  * (new)              spearce/gitk: new branch 'gitk'\n\nNah, that is just duplication.\n\n>  * 1aa3d01..e7187e4   spearce/maint: fast forward to branch 'maint'\n>  * de61e42..7840ce6   spearce/master: fast forward to branch 'master'\n>  * 895be02..2fe5433   spearce/next: fast forward to branch 'next'\n>  + 89fa332...1e4c517  spearce/pu: forcing update to non-fast forward branch 'pu'\n\nBetter to say (forced) if need be.  But I do not think so.  I like Hannes' \nproposal as-is.\n\nCiao,\nDscho\n"},{"id":"56592","messageId":"alpine.LFD.0.9999.0710191050090.19446@xanadu.home","threadId":"10376","inReplyTo":"8aa486160710190731v67626fd8wa94ba069a17f73ce@mail.gmail.com","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T14:52:57Z","receivedAt":"2007-10-19T14:52:57Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 19 Oct 2007, Santi Béjar wrote:\n\n> I like it too. I would like to add some more descripton, because I\n> think for newbies the .. and ... can be overlooked. Something like:\n> \n> $ git fetch spearce\n> ...\n> URL: git://repo.or.cz/git/spearce.git\n>  * (new)              spearce/gitk: new branch 'gitk'\n>  * 1aa3d01..e7187e4   spearce/maint: fast forward to branch 'maint'\n>  * de61e42..7840ce6   spearce/master: fast forward to branch 'master'\n>  * 895be02..2fe5433   spearce/next: fast forward to branch 'next'\n>  + 89fa332...1e4c517  spearce/pu: forcing update to non-fast forward branch 'pu'\n>  * (new)              spearce/todo: new branch spearce/todo\n\nWell, I don't like it as much.  First I don't think newbies will care \nmuch more even if the type of update is spelled out verbosely.  Better \nkeep it short and add all the necessary information in the fetch man \npage instead.\n\n\nNicolas\n"},{"id":"56593","messageId":"alpine.LFD.0.9999.0710191053390.19446@xanadu.home","threadId":"10376","inReplyTo":"4718C1DE.5030708@viscovery.net","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T14:54:41Z","receivedAt":"2007-10-19T14:54:41Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 19 Oct 2007, Johannes Sixt wrote:\n\n> The '*' could go away, then the '+' is more visible.\n\nAgreed.  ' ' = fast forward, '+' = forced update, and '!' = refused.\n\n\nNicolas\n"},{"id":"56594","messageId":"alpine.LFD.0.9999.0710191055120.19446@xanadu.home","threadId":"10376","inReplyTo":"Pine.LNX.4.64.0710191640250.16728@wbgn129.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T14:56:23Z","receivedAt":"2007-10-19T14:56:23Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 19 Oct 2007, Johannes Schindelin wrote:\n\n> Better to say (forced) if need be.  But I do not think so.  I like Hannes' \n> proposal as-is.\n\nI'm of that opinion too.  Except maybe using a space instead of * for \nfast forward, so the other types stand out more.\n\n\nNicolas\n"},{"id":"56595","messageId":"alpine.LFD.0.9999.0710191058570.19446@xanadu.home","threadId":"10376","inReplyTo":"20071019143844.GB23765@diana.vm.bytemark.co.uk","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T15:03:00Z","receivedAt":"2007-10-19T15:03:00Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 19 Oct 2007, Karl Hasselström wrote:\n\n> On 2007-10-19 07:38:22 -0400, Theodore Tso wrote:\n> \n> > Finally, one last question --- am I the only one who had to take a\n> > second look at the whether the arrow should be <- or ->? The\n> > question is whether we are saying \"gitk is moving to include all of\n> > spearce/gitk\"; but I could also see it stated that we are assigning\n> > refs/heads/gitk with refs/remotes/spearce/gitk, in which case the\n> > arrow should be reversed. Or maybe:\n> >\n> > ==> git://repo.or.cz/git/spearce.git\n> >  * branch gitk := spearce/gitk                (new)\n> >  * branch maint := spearce/maint              1aa3d01..e7187e4\n> >  * branch master := spearce/master            de61e42..7840ce6\n> >  * branch next := spearce/next                895be02..2fe5433\n> >  + branch pu := spearce/pu                    89fa332...1e4c517\n> >  * branch todo := spearce/todo                (new)\n> \n> I think the reasoning behind the \"foo -> spearce/foo\" syntax is that\n> \"(refs/heads/)foo\" in the remote repository has been fetched to\n> \"(refs/remotes/)spearce/foo\" in the local repository.\n\nWell, the important thing is that the _content_ is moving from the \nremote repository to the local one.  That's how the arrow should be \ninterpreted conceptually.  The fact that technically we end up assigning \nthe local ref with the remote value is a technical issue.\n\n\nNicolas\n"},{"id":"56596","messageId":"4718D25A.7040109@midwinter.com","threadId":"10376","inReplyTo":"20071019073938.GN14735@spearce.org","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-10-19T15:50:50Z","receivedAt":"2007-10-19T15:50:50Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"On 19/10/2007, Jeff King <peff@peff.net> wrote:\n > This makes the fetch output much more terse. It is likely to\n > be very controversial. Here's an example of the new output:\n >\n > Indexing objects: 100% (1061/1061), done.\n > Resolving deltas: 100% (638/638), done.\n\nThose two lines are actually my beef with the fetch output. As a newbie, \nI had no idea what \"Indexing objects\" actually meant. We have this thing \ncalled \"the index\" in git so I would expect \"Indexing objects\" to have \nsomething to do with that, but it doesn't seem to.\n\nHow about something more descriptive of the high-level operation that's \ngoing on, along the lines of:\n\nGathering changes from remote: 100% (1061/1061), done.\nApplying changes locally: 100% (638/638), done.\n\n-Steve\n"},{"id":"56597","messageId":"4718D310.3040101@midwinter.com","threadId":"10376","inReplyTo":"4718D25A.7040109@midwinter.com","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-10-19T15:53:52Z","receivedAt":"2007-10-19T15:53:52Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"(Sorry for the repeat; my mail client tried to send this as HTML at \nfirst and the git list rejected it.)\n\nOn 19/10/2007, Jeff King <peff@peff.net> wrote:\n > This makes the fetch output much more terse. It is likely to\n > be very controversial. Here's an example of the new output:\n >\n > Indexing objects: 100% (1061/1061), done.\n > Resolving deltas: 100% (638/638), done.\n\nThose two lines are actually my beef with the fetch output. As a newbie, \nI had no idea what \"Indexing objects\" actually meant. We have this thing \ncalled \"the index\" in git so I would expect \"Indexing objects\" to have \nsomething to do with that, but it doesn't seem to.\n\nHow about something more descriptive of the high-level operation that's \ngoing on, along the lines of:\n\nGathering changes from remote: 100% (1061/1061), done.\nApplying changes locally: 100% (638/638), done.\n\n-Steve\n"},{"id":"56599","messageId":"alpine.LFD.0.9999.0710191211210.19446@xanadu.home","threadId":"10376","inReplyTo":"4718D25A.7040109@midwinter.com","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T16:12:41Z","receivedAt":"2007-10-19T16:12:41Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 19 Oct 2007, Steven Grimm wrote:\n\n> On 19/10/2007, Jeff King <peff@peff.net> wrote:\n> > This makes the fetch output much more terse. It is likely to\n> > be very controversial. Here's an example of the new output:\n> >\n> > Indexing objects: 100% (1061/1061), done.\n> > Resolving deltas: 100% (638/638), done.\n> \n> Those two lines are actually my beef with the fetch output. As a newbie, I had\n> no idea what \"Indexing objects\" actually meant. We have this thing called \"the\n> index\" in git so I would expect \"Indexing objects\" to have something to do\n> with that, but it doesn't seem to.\n> \n> How about something more descriptive of the high-level operation that's going\n> on, along the lines of:\n> \n> Gathering changes from remote: 100% (1061/1061), done.\n> Applying changes locally: 100% (638/638), done.\n\nThis is even more wrong.\n\nAgreed, indexing objects might not be the best description.  It probably \nwill become \"receiving objects\" along with a bandwitth meter.\n\n\nNicolas\n"},{"id":"56603","messageId":"20071019172610.GE30825@uranus.ravnborg.org","threadId":"10376","inReplyTo":"alpine.LFD.0.9999.0710191211210.19446@xanadu.home","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2007-10-19T17:26:10Z","receivedAt":"2007-10-19T17:26:10Z","isPatch":true,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"On Fri, Oct 19, 2007 at 12:12:41PM -0400, Nicolas Pitre wrote:\n> On Fri, 19 Oct 2007, Steven Grimm wrote:\n> \n> > On 19/10/2007, Jeff King <peff@peff.net> wrote:\n> > > This makes the fetch output much more terse. It is likely to\n> > > be very controversial. Here's an example of the new output:\n> > >\n> > > Indexing objects: 100% (1061/1061), done.\n> > > Resolving deltas: 100% (638/638), done.\n> > \n> > Those two lines are actually my beef with the fetch output. As a newbie, I had\n> > no idea what \"Indexing objects\" actually meant. We have this thing called \"the\n> > index\" in git so I would expect \"Indexing objects\" to have something to do\n> > with that, but it doesn't seem to.\n> > \n> > How about something more descriptive of the high-level operation that's going\n> > on, along the lines of:\n> > \n> > Gathering changes from remote: 100% (1061/1061), done.\n> > Applying changes locally: 100% (638/638), done.\n> \n> This is even more wrong.\n> \n> Agreed, indexing objects might not be the best description.  It probably \n> will become \"receiving objects\" along with a bandwitth meter.\n\nThe term 'objects' here always confuses me. What is often my first\nthing to check the number of individual commits being added after\na git pull. Wether a commit touches one or several files is less\nimportant (to my way of using git).\n\n\tSam\n"},{"id":"56609","messageId":"alpine.LFD.0.9999.0710191431450.19446@xanadu.home","threadId":"10376","inReplyTo":"20071019172610.GE30825@uranus.ravnborg.org","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T18:51:30Z","receivedAt":"2007-10-19T18:51:30Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 19 Oct 2007, Sam Ravnborg wrote:\n\n> On Fri, Oct 19, 2007 at 12:12:41PM -0400, Nicolas Pitre wrote:\n> > This is even more wrong.\n> > \n> > Agreed, indexing objects might not be the best description.  It probably \n> > will become \"receiving objects\" along with a bandwitth meter.\n> \n> The term 'objects' here always confuses me. What is often my first\n> thing to check the number of individual commits being added after\n> a git pull. Wether a commit touches one or several files is less\n> important (to my way of using git).\n\nLet me unconfuse you.\n\nGit storage is made of, well, objects.  You might think that objects are \nrelated to the number of files concerned by a set of commits during a \npull, but this is not the case.  It is well possible to have a commit \ntouching 100 files and have much fewer new objects created than that.  \nReverting a patch, for example, would only restore a reference to older \nobjects in the database.  The same is true if you move an entire \ndirectory around.\n\nThe opposite is also true: you can have more new objects than modified \nfiles for a single commit, depending on the directory depth.\n\nSo the number of objects has no exact relationship what so ever with the \nnumber of objects.  However the number of objects has a much more direct \ninfluence on the time to perform a fetch, and that is what we're \ndisplaying here.  After all when you issue a pull and wait for it to \ncomplete, you wait for X amount of objects to be transferred and not Y \namount of commits.\n\nThe important metric is therefore measured in \"objects\".  But you're \nfree to ignore it and only look at the percentage if you prefer.\n\n\nNicolas\n"},{"id":"56634","messageId":"20071019211755.GC751@thunk.org","threadId":"10376","inReplyTo":"alpine.LFD.0.9999.0710191058570.19446@xanadu.home","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-10-19T21:17:55Z","receivedAt":"2007-10-19T21:17:55Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Oct 19, 2007 at 11:03:00AM -0400, Nicolas Pitre wrote:\n> Well, the important thing is that the _content_ is moving from the \n> remote repository to the local one.  That's how the arrow should be \n> interpreted conceptually.  The fact that technically we end up assigning \n> the local ref with the remote value is a technical issue.\n\nIf the _content_ is moving from the remote repository to the local\none, I would think the arrow should be pointing from the remote\nrepoistory to the local one, i.e.:\n\n  * 895be02..2fe5433   next <- spearce/next\n\nBut right now we are proposing:\n\n  * 895be02..2fe5433   next -> spearce/next\n\nI would think the former makes more sense is the content is going\n*from* spearce/next into the local next branch.\n\nThis isn't a huge deal, but these tiny things make a large amount of\ndifference in usability for the novice who just getting started with\ngit....\n\n\t\t\t\t\t\t- Ted\n"},{"id":"56637","messageId":"alpine.LFD.0.9999.0710191739270.19446@xanadu.home","threadId":"10376","inReplyTo":"20071019211755.GC751@thunk.org","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-19T21:40:48Z","receivedAt":"2007-10-19T21:40:48Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 19 Oct 2007, Theodore Tso wrote:\n\n> On Fri, Oct 19, 2007 at 11:03:00AM -0400, Nicolas Pitre wrote:\n> > Well, the important thing is that the _content_ is moving from the \n> > remote repository to the local one.  That's how the arrow should be \n> > interpreted conceptually.  The fact that technically we end up assigning \n> > the local ref with the remote value is a technical issue.\n> \n> If the _content_ is moving from the remote repository to the local\n> one, I would think the arrow should be pointing from the remote\n> repoistory to the local one, i.e.:\n> \n>   * 895be02..2fe5433   next <- spearce/next\n> \n> But right now we are proposing:\n> \n>   * 895be02..2fe5433   next -> spearce/next\n> \n> I would think the former makes more sense is the content is going\n> *from* spearce/next into the local next branch.\n\nNo.  \"next\" is the name of the _remote_ branch that is stored locally in \nspearce/next.  So the arrow is correct.\n\n\nNicolas\n"},{"id":"56639","messageId":"20071019215811.GE751@thunk.org","threadId":"10376","inReplyTo":"alpine.LFD.0.9999.0710191739270.19446@xanadu.home","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Theodore Tso","fromEmail":"tytso@thunk.org","sentAt":"2007-10-19T21:58:11Z","receivedAt":"2007-10-19T21:58:11Z","isPatch":true,"sender":{"key":"tytso@thunk.org","avatar":"https://gravatar.com/avatar/bc16cd364de8c963cca27953f33db8cd94de51b67922a7697620d8512a05ab01?d=mp&s=160"},"body":"On Fri, Oct 19, 2007 at 05:40:48PM -0400, Nicolas Pitre wrote:\n> No.  \"next\" is the name of the _remote_ branch that is stored locally in \n> spearce/next.  So the arrow is correct.\n\nAh; yes, you're right.  I can see this being very confusing to the\nnewbie, though.  Enough so that in beginner mode we might want it to\nsay:\n\n   895be02..2fe5433   (remote) next -> (local) spearce/next\n\n... especially since the git pull might follow up the pull with a\nmerge from the local remotes/spearce/next to the local next branch.\nSo it would be a good idea that it is clear when we are referring to a\nlocal or a remote branch.\n\n   \t\t      \t       \t       \t       - Ted\n"},{"id":"56653","messageId":"20071020050019.GA27282@coredump.intra.peff.net","threadId":"10376","inReplyTo":"alpine.LFD.0.9999.0710191009330.19446@xanadu.home","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-20T05:00:19Z","receivedAt":"2007-10-20T05:00:19Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 19, 2007 at 10:14:59AM -0400, Nicolas Pitre wrote:\n\n> > ==> git://repo.or.cz/git/spearce.git\n> >  * (new)              gitk -> spearce/gitk\n> >  * 1aa3d01..e7187e4   maint -> spearce/maint\n> >  * de61e42..7840ce6   master -> spearce/master\n> >  * 895be02..2fe5433   next -> spearce/next\n> >  + 89fa332...1e4c517  pu -> spearce/pu\n> >  * (new)              todo -> spearce/todo\n> \n> Actually I think this is the best format so far: one line per branch, no \n> terminal width issue (long branch names are simply wrapped), the \n> old..new info is there also with the single character marker to quickly \n> notice the type of update.\n\nTechnically speaking, the hash IDs can be up to 80 characters long,\nsince they are meant to be unique abbreviations. But in practice, I\nthink leaving enough space for 10 + '...' + 10 should accomodate just\nabout any project (IIRC, the kernel's longest non-unique is around 9).\n\n-Peff\n"},{"id":"56671","messageId":"20071020065822.GW14735@spearce.org","threadId":"10376","inReplyTo":"20071020050019.GA27282@coredump.intra.peff.net","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-20T06:58:22Z","receivedAt":"2007-10-20T06:58:22Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jeff King <peff@peff.net> wrote:\n> On Fri, Oct 19, 2007 at 10:14:59AM -0400, Nicolas Pitre wrote:\n> \n> > > ==> git://repo.or.cz/git/spearce.git\n> > >  * (new)              gitk -> spearce/gitk\n> > >  * 1aa3d01..e7187e4   maint -> spearce/maint\n> > >  * de61e42..7840ce6   master -> spearce/master\n> > >  * 895be02..2fe5433   next -> spearce/next\n> > >  + 89fa332...1e4c517  pu -> spearce/pu\n> > >  * (new)              todo -> spearce/todo\n> > \n> > Actually I think this is the best format so far: one line per branch, no \n> > terminal width issue (long branch names are simply wrapped), the \n> > old..new info is there also with the single character marker to quickly \n> > notice the type of update.\n\nYea, I think this is almost the right format.\n\nNicolas Pitre <nico@cam.org> wrote:\n> Agreed.  ' ' = fast forward, '+' = forced update, and '!' = refused.\n \nWe're probably looking at something like this:\n\n>From git://repo.or.cz/git/spearce.git\n   1aa3d01..e7187e4   maint -> spearce/maint\n   de61e42..7840ce6   master -> spearce/master\n   895be02..2fe5433   next -> spearce/next\n   (new)              todo -> spearce/todo\n   (new)              tag v1.6.0\n + 89fa332...1e4c517  pu -> spearce/pu  (forced update)\n ! 2b5afb...289840    gitk -> spearce/gitk (non-fast forward)\n\nNotice the sorting order by *type* of update.  I think it makes\nthe code slightly more complicated in builtin-fetch as we need to\nclassify each ref into a type of update, then sort them by that\ntype, but it allows the end-user to see the most \"important\" (not\nsimple fast-forward updates) at the end of their terminal window,\nespecially if there were many fast-forward branches.  Within a\nclass of update we still sort by ref name.\n\n> Technically speaking, the hash IDs can be up to 80 characters long,\n> since they are meant to be unique abbreviations. But in practice, I\n> think leaving enough space for 10 + '...' + 10 should accomodate just\n> about any project (IIRC, the kernel's longest non-unique is around 9).\n\nWhich nicely solves the issue with the window size as we aren't\nreally worring about it here in this display.\n\n-- \nShawn.\n"},{"id":"56990","messageId":"buomyua6x7x.fsf@dhapc248.dev.necel.com","threadId":"10376","inReplyTo":"alpine.LFD.0.9999.0710190913280.19446@xanadu.home","subject":"Re: [RFC/PATCH] git-fetch: mega-terse fetch output","fromName":"Miles Bader","fromEmail":"miles.bader@necel.com","sentAt":"2007-10-23T08:39:46Z","receivedAt":"2007-10-23T08:39:46Z","isPatch":true,"sender":{"key":"miles.bader@necel.com","avatar":"https://gravatar.com/avatar/be062d4050eb88e04229cbdb60f803e1bd647923a015996c2439e76f23e336a7?d=mp&s=160"},"body":"Nicolas Pitre <nico@cam.org> writes:\n> I think the advantage of having only one line of output per branch \n> really outweight the need for old..new notation.  Do you really benefit \n> from it?\n\nThe \"one-line\" issue has already been resolved in other messages, but I\njust wanted to say I use this info all the time.\n\n-Miles\n\n-- \n\"Suppose He doesn't give a shit?  Suppose there is a God but He\njust doesn't give a shit?\"  [George Carlin]\n"}]}