{"thread":{"id":"23393","subject":"Why not show ORIG_HEAD in git-log --decorate?","startedAt":"2010-04-09T16:07:00Z","lastAt":"2010-04-10T09:04:41Z","messageCount":4,"participants":["Yury Polyanskiy","Jeff King","Björn Steinbrink"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"139053","messageId":"s2zea182b21004090907i9af49416za4fdb4650af5ae29@mail.gmail.com","threadId":"23393","inReplyTo":null,"subject":"Why not show ORIG_HEAD in git-log --decorate?","fromName":"Yury Polyanskiy","fromEmail":"polyanskiy@gmail.com","sentAt":"2010-04-09T16:07:00Z","receivedAt":"2010-04-09T16:07:00Z","isPatch":false,"sender":{"key":"polyanskiy@gmail.com","avatar":null},"body":"Hello list!\n\nIt would be very convenient if after git-pull I could see the new\nmerged-in commits in the git-log. The simplest solution for this is to\nsimply mark ORIG_HEAD in the output of git-log --decorate (and ideally\nalso in gitk).\n\nJust thought to throw in this idea to developers. Perhaps it is not\nthat hard to implement.\n\nBest,\nYury\n"},{"id":"139099","messageId":"20100410012903.GA32428@coredump.intra.peff.net","threadId":"23393","inReplyTo":"s2zea182b21004090907i9af49416za4fdb4650af5ae29@mail.gmail.com","subject":"Re: Why not show ORIG_HEAD in git-log --decorate?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-10T01:29:03Z","receivedAt":"2010-04-10T01:29:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 09, 2010 at 12:07:00PM -0400, Yury Polyanskiy wrote:\n\n> It would be very convenient if after git-pull I could see the new\n> merged-in commits in the git-log. The simplest solution for this is to\n> simply mark ORIG_HEAD in the output of git-log --decorate (and ideally\n> also in gitk).\n\nI think most people do something like:\n\n  gitk HEAD^..ORIG_HEAD\n\nTo see everything in ORIG_HEAD that isn't in HEAD^ (the first parent of\nHEAD, or what you had just before the pull).\n\n> Just thought to throw in this idea to developers. Perhaps it is not\n> that hard to implement.\n\nMarking ORIG_HEAD in git-log is pretty straightforward. If we wanted to\ndo that, probably MERGE_HEAD and FETCH_HEAD should be marked, too.\nI don't really have an opinion, as I don't generally use \"git log\n--decorate\", but the patch for git-log would look something like what is\nbelow (I am not planning on taking it further, but if somebody wants to\nthink more about the issues, they are welcome to pick it up and work on\nit).\n\ngitk would need a separate patch, as it uses a separate mechanism.\n\ndiff --git a/log-tree.c b/log-tree.c\nindex d3ae969..e2034c4 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -43,7 +43,7 @@ void load_ref_decorations(int flags)\n \tif (!loaded) {\n \t\tloaded = 1;\n \t\tfor_each_ref(add_ref_decoration, &flags);\n-\t\thead_ref(add_ref_decoration, &flags);\n+\t\tfor_each_metaref(add_ref_decoration, &flags);\n \t}\n }\n \ndiff --git a/refs.c b/refs.c\nindex d3db15a..eef7e13 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -663,6 +663,28 @@ int head_ref(each_ref_fn fn, void *cb_data)\n \treturn 0;\n }\n \n+int for_each_metaref(each_ref_fn fn, void *cb_data)\n+{\n+\tstatic const char *meta_refs[] = {\n+\t\t\"HEAD\",\n+\t\t\"ORIG_HEAD\",\n+\t\t\"FETCH_HEAD\",\n+\t\t\"MERGE_HEAD\",\n+\t};\n+\tint i;\n+\n+\tfor (i = 0; i < ARRAY_SIZE(meta_refs); i++) {\n+\t\tunsigned char sha1[20];\n+\t\tint flag;\n+\t\tif (resolve_ref(meta_refs[i], sha1, 1, &flag)) {\n+\t\t\tint ret = fn(meta_refs[i], sha1, flag, cb_data);\n+\t\t\tif (ret)\n+\t\t\t\treturn ret;\n+\t\t}\n+\t}\n+\treturn 0;\n+}\n+\n int for_each_ref(each_ref_fn fn, void *cb_data)\n {\n \treturn do_for_each_ref(\"refs/\", fn, 0, 0, cb_data);\ndiff --git a/refs.h b/refs.h\nindex 4a18b08..7e72c4d 100644\n--- a/refs.h\n+++ b/refs.h\n@@ -19,6 +19,7 @@ struct ref_lock {\n  */\n typedef int each_ref_fn(const char *refname, const unsigned char *sha1, int flags, void *cb_data);\n extern int head_ref(each_ref_fn, void *);\n+extern int for_each_metaref(each_ref_fn, void *);\n extern int for_each_ref(each_ref_fn, void *);\n extern int for_each_ref_in(const char *, each_ref_fn, void *);\n extern int for_each_tag_ref(each_ref_fn, void *);\n"},{"id":"139139","messageId":"20100410090042.GA13109@atjola.homenet","threadId":"23393","inReplyTo":"20100410012903.GA32428@coredump.intra.peff.net","subject":"Re: Why not show ORIG_HEAD in git-log --decorate?","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2010-04-10T09:00:42Z","receivedAt":"2010-04-10T09:00:42Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2010.04.09 21:29:03 -0400, Jeff King wrote:\n> On Fri, Apr 09, 2010 at 12:07:00PM -0400, Yury Polyanskiy wrote:\n> \n> > It would be very convenient if after git-pull I could see the new\n> > merged-in commits in the git-log. The simplest solution for this is to\n> > simply mark ORIG_HEAD in the output of git-log --decorate (and ideally\n> > also in gitk).\n> \n> I think most people do something like:\n> \n>   gitk HEAD^..ORIG_HEAD\n> \n> To see everything in ORIG_HEAD that isn't in HEAD^ (the first parent of\n> HEAD, or what you had just before the pull).\n\nI guess you meant to say \"gitk ORIG_HEAD..\" there. ORIG_HEAD is already\nthe pre-pull state. So if the merge actually created a merge commit,\nthen HEAD^ == ORIG_HEAD, and if it was a fast-forward, then ORIG_HEAD is\neither the same as HEAD^ or one of its ancestors. In either case,\nHEAD^..ORIG_HEAD will be empty.\n\nBjörn\n"},{"id":"139140","messageId":"20100410090441.GA18772@coredump.intra.peff.net","threadId":"23393","inReplyTo":"20100410090042.GA13109@atjola.homenet","subject":"Re: Why not show ORIG_HEAD in git-log --decorate?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-10T09:04:41Z","receivedAt":"2010-04-10T09:04:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Apr 10, 2010 at 11:00:42AM +0200, Björn Steinbrink wrote:\n\n> > I think most people do something like:\n> > \n> >   gitk HEAD^..ORIG_HEAD\n> > \n> > To see everything in ORIG_HEAD that isn't in HEAD^ (the first parent of\n> > HEAD, or what you had just before the pull).\n> \n> I guess you meant to say \"gitk ORIG_HEAD..\" there. ORIG_HEAD is already\n> the pre-pull state. So if the merge actually created a merge commit,\n> then HEAD^ == ORIG_HEAD, and if it was a fast-forward, then ORIG_HEAD is\n> either the same as HEAD^ or one of its ancestors. In either case,\n> HEAD^..ORIG_HEAD will be empty.\n\nUrgh, yes. Sorry, I was totally not thinking when I wrote that.\n\nI never use ORIG_HEAD, as I always do a fetch + inspect + merge, rather\nthan pull. But I can't even figure out what thought process led me to\nwrite what I did above.\n\nThanks for the correction.\n\n-Peff\n"}]}