Possible BUG in 'git log --parents'

Possible BUG in 'git log --parents'

[Marco Costalba]

git-rev-list shows parents correctly, git-log no, in particulary there
is parent 913419f that is shown 3 times instead of 1. Testing on git
repository.

$ git --version
git version 1.5.3.rc0.11.ge2b1a

$ git-rev-list --parents --header addafaf92e -n1 -- diff.h
addafaf92eeb86033da91323d0d3ad7a496dae83
913419fcc648dd43d7f7afdd94fa25aee4f9798a
ea726d02e9677a66586d7ffebe97f112ab6dab33
46a6c2620ba421397eec627b8eb18eb530e694fc
tree e3be15f54f01e3aa1f8ec830ac87da5f85a23480
parent 6b94f1e404afc552e5139c4357331843f5be61ad
parent 93b74bca86f59b8df410b6fd4803b88ee0f304bf
parent ea726d02e9677a66586d7ffebe97f112ab6dab33
parent b33aba518456bee97bde1fef4fe17ab6bf401bbe
parent 6b1ddbdd6e02719ae2be55dc141a176187e5027e
author Junio C Hamano <junkio@cox.net> 1138436169 -0800
committer Junio C Hamano <junkio@cox.net> 1138436169 -0800

    Merge lt/revlist,jc/diff,jc/revparse,jc/abbrev


$ git-log --parents --pretty=raw addafaf92e -n1 -- diff.h
commit addafaf92eeb86033da91323d0d3ad7a496dae83
913419fcc648dd43d7f7afdd94fa25aee4f9798a 913419fcc648dd43d7f7a
fdd94fa25aee4f9798a ea726d02e9677a66586d7ffebe97f112ab6dab33
913419fcc648dd43d7f7afdd94fa25aee4f9798a 46a6c262
0ba421397eec627b8eb18eb530e694fc
tree e3be15f54f01e3aa1f8ec830ac87da5f85a23480
parent 6b94f1e404afc552e5139c4357331843f5be61ad
parent 93b74bca86f59b8df410b6fd4803b88ee0f304bf
parent ea726d02e9677a66586d7ffebe97f112ab6dab33
parent b33aba518456bee97bde1fef4fe17ab6bf401bbe
parent 6b1ddbdd6e02719ae2be55dc141a176187e5027e
author Junio C Hamano <junkio@cox.net> 1138436169 -0800
committer Junio C Hamano <junkio@cox.net> 1138436169 -0800

    Merge lt/revlist,jc/diff,jc/revparse,jc/abbrev

Re: Possible BUG in 'git log --parents'

[Junio C Hamano]

"Marco Costalba" <mcostalba@gmail.com> writes:

> git-rev-list shows parents correctly, git-log no, in particulary there
> is parent 913419f that is shown 3 times instead of 1. Testing on git
> repository.
>
> $ git-log --parents --pretty=raw addafaf92e -n1 -- diff.h
> commit addafaf92eeb86033da91323d0d3ad7a496dae83
> 913419fcc648dd43d7f7afdd94fa25aee4f9798a 913419fcc648dd43d7f7a
> fdd94fa25aee4f9798a ea726d02e9677a66586d7ffebe97f112ab6dab33
> 913419fcc648dd43d7f7afdd94fa25aee4f9798a 46a6c262
> 0ba421397eec627b8eb18eb530e694fc
> tree e3be15f54f01e3aa1f8ec830ac87da5f85a23480
> parent 6b94f1e404afc552e5139c4357331843f5be61ad
> parent 93b74bca86f59b8df410b6fd4803b88ee0f304bf
> parent ea726d02e9677a66586d7ffebe97f112ab6dab33
> parent b33aba518456bee97bde1fef4fe17ab6bf401bbe
> parent 6b1ddbdd6e02719ae2be55dc141a176187e5027e
> author Junio C Hamano <junkio@cox.net> 1138436169 -0800
> committer Junio C Hamano <junkio@cox.net> 1138436169 -0800

Line wrapping in the middle of a single object name makes it
hard to read doesn't it?

The commit does have 5 parents, among which, three of them merge
branches that do not touch the named paths (in this case it
happens to be a single "diff.h") and parent simplification leads
to the same ancestor.

I recall we added an extra logic in rev-list side to squash the
parent commits that artificially becomes duplicate due to this
history simplification logic, which we might want to port to
git-log.  However, I have a slight suspicion that we earlier
decided not to do so on purpose with git-log and for a good
reason.  I do not have much energy left tonight to dig into this
right now, but mailing list log and commit log messages for
rev-list.c, builtin-log.c and builtin-rev-list.c might tell you
more.

Re: Possible BUG in 'git log --parents'

[Marco Costalba]

On 7/7/07, Junio C Hamano <gitster@pobox.com> wrote:
>
> Line wrapping in the middle of a single object name makes it
> hard to read doesn't it?
>

Sorry!

> I recall we added an extra logic in rev-list side to squash the
> parent commits that artificially becomes duplicate due to this
> history simplification logic, which we might want to port to
> git-log.  However, I have a slight suspicion that we earlier
> decided not to do so on purpose with git-log and for a good
> reason.  I do not have much energy left tonight to dig into this
> right now, but mailing list log and commit log messages for
> rev-list.c, builtin-log.c and builtin-rev-list.c might tell you
> more.
>

I will take a look hoping to *not* find anything important, now that
qgit rely on git log instead of git-rev-list to show the graph, I
would really hope that it is possible to patch git-log in the same way
then git-rev-list.

Thanks
Marco

Re: Possible BUG in 'git log --parents'

[Marco Costalba]

On 7/7/07, Marco Costalba <mcostalba@gmail.com> wrote:
> On 7/7/07, Junio C Hamano <gitster@pobox.com> wrote:
>
>
> > git-log.  However, I have a slight suspicion that we earlier
> > decided not to do so on purpose with git-log and for a good
> > reason.  I do not have much energy left tonight to dig into this
> > right now, but mailing list log and commit log messages for
> > rev-list.c, builtin-log.c and builtin-rev-list.c might tell you
> > more.
> >
>
> I will take a look ...
>

The commit with the patch for git-rev-list is 884944239f2

I have found also the following commits, more or less related:
884944239f2          3381c790        2a0925be3

But I haven't found messages with downsides of using the same approach
also for git log.

So could you please apply the patch also for git-log if possible.

Thanks
Marco

Re: Possible BUG in 'git log --parents'

[Junio C Hamano]

"Marco Costalba" <mcostalba@gmail.com> writes:

> On 7/7/07, Marco Costalba <mcostalba@gmail.com> wrote:
>> On 7/7/07, Junio C Hamano <gitster@pobox.com> wrote:
>>
>>
>> > git-log.  However, I have a slight suspicion that we earlier
>> > decided not to do so on purpose with git-log and for a good
>> > reason.  I do not have much energy left tonight to dig into this
>> > right now, but mailing list log and commit log messages for
>> > rev-list.c, builtin-log.c and builtin-rev-list.c might tell you
>> > more.
>> >
>>
>> I will take a look ...
>>
>
> The commit with the patch for git-rev-list is 884944239f2

That's correct.  And I do not think of a reason for log and
rev-list to behave differently in this case now, so let's change
the behaviour of log.

There still is one thing I am a bit worried about, though.  You
can get the list of true, immediate parents in the raw format
("parent" lines) while getting the list of simplified parents on
the commit line (the topic of this thread).  Aren't there cases
where Porcelains would want to match up which immediate parent
lead to which simplified parent?  Using the illustration from
the commit log mesage of 88494423:

    
                      .---A---.
                     /         \
                    .---*---B---.
                   /    93b74bc  \
       ---*---o---o-----o---C-----o addafaf
          d8f6b34  \             /
                    .---o---D---.
                     \         /
                      .---E---.
                          3815f42
    
If we always show the five simplified parents as the response to
the --parent request, you would get:

  commit addafaf... d8f6b34... 93b74bc... d8f6b34... d8f6b34... 3815f42...
  tree e3be15f54f01e3aa1f8ec830ac87da5f85a23480
  parent 6b94f1e404afc552e5139c4357331843f5be61ad
  parent 93b74bca86f59b8df410b6fd4803b88ee0f304bf
  parent ea726d02e9677a66586d7ffebe97f112ab6dab33
  parent b33aba518456bee97bde1fef4fe17ab6bf401bbe
  parent 6b1ddbdd6e02719ae2be55dc141a176187e5027e

and you can tell 6b94f1e4 (the first immediate parent)
corresponds to d8f6b34, the first simplified parent, while
93b74bc (the second immediate parent) corresponds to 93b74bc
(the second simplified parent).  If we do the duplicate
omission, as we do for rev-list (and not for log as you found
out), you would not be able to tell which branch you can find by
reading the immediate parent list corresponds to what simplified
parent you can find from the --parent output.

But this worry applies to both rev-list and log, and it is no
reason to leave their behaviours different.

-- >8 --
Match "log --parent" output to "rev-list --parent" output.

We updated "rev-list --parent" output to omit duplicated parents
from the output long time ago, but this change was not side-ported
to "git-log".  There is no reason to leave them inconsistent.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

diff --git a/log-tree.c b/log-tree.c
index 8624d5a..24aea6b 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -6,13 +6,32 @@
 
 struct decoration name_decoration = { "object names" };
 
+static void clear_tmp_mark(struct commit_list *p)
+{
+	while (p) {
+		struct commit *c = p->item;
+		c->object.flags &= ~TMP_MARK;
+		p = p->next;
+	}
+}
+
 static void show_parents(struct commit *commit, int abbrev)
 {
 	struct commit_list *p;
+
+	/* TMP_MARK is a general purpose flag that can
+	 * be used locally, but the user should clean
+	 * things up after it is done with them.
+	 */
+	clear_tmp_mark(commit->parents);
 	for (p = commit->parents; p ; p = p->next) {
 		struct commit *parent = p->item;
+		if (parent->object.flags & TMP_MARK)
+			continue;
 		printf(" %s", diff_unique_abbrev(parent->object.sha1, abbrev));
+		parent->object.flags |= TMP_MARK;
 	}
+	clear_tmp_mark(commit->parents);
 }
 
 static void show_decorations(struct commit *commit)

Re: Possible BUG in 'git log --parents'

[Marco Costalba]

On 7/8/07, Junio C Hamano <gitster@pobox.com> wrote:
> Match "log --parent" output to "rev-list --parent" output.
>

Thanks. It works for me.

Re: Possible BUG in 'git log --parents'

[Marco Costalba]

On 7/8/07, Marco Costalba <mcostalba@gmail.com> wrote:
> On 7/8/07, Junio C Hamano <gitster@pobox.com> wrote:
> > Match "log --parent" output to "rev-list --parent" output.
> >
>
> Thanks. It works for me.
>

Sorry, I have to correct, it does *not* work for me.

Please apply your patch and give a look at:

git log --parents -n1 addafaf92e -r -m -- diff.h

What seems to happen is that duplicated entries are not removed by
diff machinery.

Although duplicated parents are correctly removed from parent list as
in git-rev-list, probably we should consider that git-log has also the
diff machinery attached.

Marco

P.S: Hope this little issue does not make you revert the patch ;-)