Thread (4 messages) flat view 4 messages, 3 authors, 2016-06-15

Re: [PATCH 3/3] Make clear_commit_marks() clean harder

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:32

Rene Scharfe [off-list ref] writes:
Don't care if objects have been parsed or not and don't stop when we
reach a commit that is already clean -- its parents could be dirty.
There is something quite wrong with this patch.  When you are
dealing with complex commit ancestry, this ends up traversing
the same parent over and over again.

I tried to do a merge in linux-2.6 history with these two
commits:

	v2.6.17-g29454dd
	v2.6.17-gd6b0c53

The former is Linus's head at this writing, and the latter is
James Bottomley's scsi-misc head.

	git describe 29454dd d6b0c53

from the "master" branch returns immediately (the use there can
assume that the mark is set and contiguous, I think) while the
one with this patch takes forever.

Another example is to try changing get_merge_bases() to always
clean-up as Johannes had originally and try computing the merge
base between the two.  Just before it starts to clean-up, it has
only seen 5983 objects (object.c::nr_objs) and it definitely
would be faster to clean flags from all these objects than to
wait for the two calls to clear_commit_marks() to complete,
which seems to also take forever.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help