Why not show ORIG_HEAD in git-log --decorate?

Why not show ORIG_HEAD in git-log --decorate?

[Yury Polyanskiy]

Hello list!

It would be very convenient if after git-pull I could see the new
merged-in commits in the git-log. The simplest solution for this is to
simply mark ORIG_HEAD in the output of git-log --decorate (and ideally
also in gitk).

Just thought to throw in this idea to developers. Perhaps it is not
that hard to implement.

Best,
Yury

Re: Why not show ORIG_HEAD in git-log --decorate?

[Jeff King]

On Fri, Apr 09, 2010 at 12:07:00PM -0400, Yury Polyanskiy wrote:

> It would be very convenient if after git-pull I could see the new
> merged-in commits in the git-log. The simplest solution for this is to
> simply mark ORIG_HEAD in the output of git-log --decorate (and ideally
> also in gitk).

I think most people do something like:

  gitk HEAD^..ORIG_HEAD

To see everything in ORIG_HEAD that isn't in HEAD^ (the first parent of
HEAD, or what you had just before the pull).

> Just thought to throw in this idea to developers. Perhaps it is not
> that hard to implement.

Marking ORIG_HEAD in git-log is pretty straightforward. If we wanted to
do that, probably MERGE_HEAD and FETCH_HEAD should be marked, too.
I don't really have an opinion, as I don't generally use "git log
--decorate", but the patch for git-log would look something like what is
below (I am not planning on taking it further, but if somebody wants to
think more about the issues, they are welcome to pick it up and work on
it).

gitk would need a separate patch, as it uses a separate mechanism.

diff --git a/log-tree.c b/log-tree.c
index d3ae969..e2034c4 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -43,7 +43,7 @@ void load_ref_decorations(int flags)
 	if (!loaded) {
 		loaded = 1;
 		for_each_ref(add_ref_decoration, &flags);
-		head_ref(add_ref_decoration, &flags);
+		for_each_metaref(add_ref_decoration, &flags);
 	}
 }
 
diff --git a/refs.c b/refs.c
index d3db15a..eef7e13 100644
--- a/refs.c
+++ b/refs.c
@@ -663,6 +663,28 @@ int head_ref(each_ref_fn fn, void *cb_data)
 	return 0;
 }
 
+int for_each_metaref(each_ref_fn fn, void *cb_data)
+{
+	static const char *meta_refs[] = {
+		"HEAD",
+		"ORIG_HEAD",
+		"FETCH_HEAD",
+		"MERGE_HEAD",
+	};
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(meta_refs); i++) {
+		unsigned char sha1[20];
+		int flag;
+		if (resolve_ref(meta_refs[i], sha1, 1, &flag)) {
+			int ret = fn(meta_refs[i], sha1, flag, cb_data);
+			if (ret)
+				return ret;
+		}
+	}
+	return 0;
+}
+
 int for_each_ref(each_ref_fn fn, void *cb_data)
 {
 	return do_for_each_ref("refs/", fn, 0, 0, cb_data);
diff --git a/refs.h b/refs.h
index 4a18b08..7e72c4d 100644
--- a/refs.h
+++ b/refs.h
@@ -19,6 +19,7 @@ struct ref_lock {
  */
 typedef int each_ref_fn(const char *refname, const unsigned char *sha1, int flags, void *cb_data);
 extern int head_ref(each_ref_fn, void *);
+extern int for_each_metaref(each_ref_fn, void *);
 extern int for_each_ref(each_ref_fn, void *);
 extern int for_each_ref_in(const char *, each_ref_fn, void *);
 extern int for_each_tag_ref(each_ref_fn, void *);

Re: Why not show ORIG_HEAD in git-log --decorate?

[Björn Steinbrink]

On 2010.04.09 21:29:03 -0400, Jeff King wrote:
> On Fri, Apr 09, 2010 at 12:07:00PM -0400, Yury Polyanskiy wrote:
> 
> > It would be very convenient if after git-pull I could see the new
> > merged-in commits in the git-log. The simplest solution for this is to
> > simply mark ORIG_HEAD in the output of git-log --decorate (and ideally
> > also in gitk).
> 
> I think most people do something like:
> 
>   gitk HEAD^..ORIG_HEAD
> 
> To see everything in ORIG_HEAD that isn't in HEAD^ (the first parent of
> HEAD, or what you had just before the pull).

I guess you meant to say "gitk ORIG_HEAD.." there. ORIG_HEAD is already
the pre-pull state. So if the merge actually created a merge commit,
then HEAD^ == ORIG_HEAD, and if it was a fast-forward, then ORIG_HEAD is
either the same as HEAD^ or one of its ancestors. In either case,
HEAD^..ORIG_HEAD will be empty.

Björn

Re: Why not show ORIG_HEAD in git-log --decorate?

[Jeff King]

On Sat, Apr 10, 2010 at 11:00:42AM +0200, Björn Steinbrink wrote:

> > I think most people do something like:
> > 
> >   gitk HEAD^..ORIG_HEAD
> > 
> > To see everything in ORIG_HEAD that isn't in HEAD^ (the first parent of
> > HEAD, or what you had just before the pull).
> 
> I guess you meant to say "gitk ORIG_HEAD.." there. ORIG_HEAD is already
> the pre-pull state. So if the merge actually created a merge commit,
> then HEAD^ == ORIG_HEAD, and if it was a fast-forward, then ORIG_HEAD is
> either the same as HEAD^ or one of its ancestors. In either case,
> HEAD^..ORIG_HEAD will be empty.

Urgh, yes. Sorry, I was totally not thinking when I wrote that.

I never use ORIG_HEAD, as I always do a fetch + inspect + merge, rather
than pull. But I can't even figure out what thought process led me to
write what I did above.

Thanks for the correction.

-Peff