On Sat, 16 Feb 2008, Paul Mackerras wrote:
>
> When using both path and commit limiting, git log --parents --boundary
> rewrites the parents that are actually in the graph but doesn't
> rewrite the parents on the boundary, that is, the boundary parents may
> be commits that don't modify any of the specified paths. I'm
> wondering if there is a way to get the boundary parents rewritten too.
Hmm. Right now we never rewrite uninteresting parents. The reason is
rather simple: we simply haven't followed the chain down uninteresting
commits!
Changing that is pretty hard. The thing is, we do the commit range
limiting mostly separately from the commit parent simplification: one
happens while actually walking the commits, the other one happens
after-the-fact when you do the "simplify_commit()" thing.
In addition to that problem (which is likely solvable: we do actually do
a lot of the groundwork for the later simplification stage during the
first stage, so we might be able to just move more of that logic up), we
actually explicitly do *not* simplify uninteresting commits, ie we have:
if (!revs->simplify_history || (p->object.flags & UNINTERESTING)) {
/* Even if a merge with an uninteresting
* side branch brought the entire change
* we are interested in, we do not want
* to lose the other branches of this
* merge, so we just keep going.
*/
pp = &parent->next;
continue;
}
in there, where the comment says it all: we literally *avoid* simplifying
uninteresting parents, and if the commit itself is uninteresting, we go
even further, and don't even compare the trees at all! (See the big
comment in revision.c: add_parents_to_list, and note how it checks for the
UNINTERESTING bit and returns early without even calling
try_to_simplify_commit() for such a commit).
So right now, not only is the code not really organized for what you ask,
it actually explicitly tries to avoid doing what you ask.
That said, I'm not sure either of these problems are really impossible (or
even hard) issues to avoid.
We could simply move the "try_to_simplify_commit()" call up, and remove
some of the code that explicitly avoids simplifying negative commits. But
the logic on when to stop even traversing the list is fundamentally pretty
hard, and that might require splitting up UNINTERESTING into two separate
bits: a "fairly uninteresting" bit (which means that it is negative) and a
"_really_ uninteresting bit" (which means that not only was it negtive,
but it also changed the tree, so the parents of this commit are *really*
not interesting any more, even after simplification).
Then the "can we stop traversing the tree" code would have to look at the
"really uninteresting" bit rather than just the regular uninteresting one.
Quite frankly, I suspect it's not worth it, and maybe you just shouldn't
do that optimization and limit the commits in other ways instead (ie you
might try to limit them *numerically* instead of by using negative
commits, and do one first run with the number of commits limited to <n>,
and then if that wasn't enough to re-connect the trees, you do the whole
thing)
Linus
-
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
