Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:

quoted text
> 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.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html