"Marco Costalba" <mcostalba@xxxxxxxxx> writes:
> On 7/7/07, Marco Costalba <mcostalba@xxxxxxxxx> wrote:
>> On 7/7/07, Junio C Hamano <gitster@xxxxxxxxx> 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@xxxxxxxxx>
---
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)
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
