From: Linus Torvalds <torvalds@osdl.org>
To: Junio C Hamano <junkio@cox.net>, Git Mailing List <git@vger.kernel.org>
Subject: [PATCH/RFC 2/2] Make path-limiting be incremental when possible.
Date: Thu, 30 Mar 2006 17:05:25 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0603301652531.27203@g5.osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0603301648530.27203@g5.osdl.org>
This makes git-rev-list able to do path-limiting without having to parse
all of history before it starts showing the results.
This makes it things like "git log -- pathname" much more pleasant to use.
This is actually a pretty small patch, and the biggest part of it is
purely cleanups (turning the "goto next" statements into "continue"), but
it's conceptually a lot bigger than it looks.
What it does is that if you do a path-limited revision list, and you do
_not_ ask for pseudo-parenthood information, it won't do all the
path-limiting up-front, but instead do it incrementally in
"get_revision()".
This is an absolutely huge deal for anything like "git log -- <pathname>",
but also for some things that we don't do yet - like the "find where
things changed" logic I've described elsewhere, where we want to find the
previous revision that changed a file.
The reason I put "RFC" in the subject line is that while I've validated it
various ways, like doing
git-rev-list HEAD -- drivers/char/ | md5sum
before-and-after on the kernel archive, it's "git-rev-list" after all. In
other words, it's that really really subtle and complex central piece of
software. So while I think this is important and should go in asap, I also
think it should get lots of testing and eyeballs looking at the code.
Btw, don't even bother testing this with the git archive. git itself is so
small that parsing the whole revision history for it takes about a second
even with path limiting. The thing that _really_ shows this off is doing
git log drivers/
on the kernel archive, or even better, on the _historic_ kernel archive.
With this change, the response is instantaneous (although seeking to the
end of the result will obviously take as long as it ever did). Before this
change, the command would think about the result for tens of seconds - or
even minutes, in the case of the bigger old kernel archive - before
starting to output the results.
NOTE NOTE NOTE! Using path limiting with things like "gitk", which uses
the "--parents" flag to actually generate a pseudo-history of the
resulting commits won't actually see the improvement in interactivity,
since that forces git-rev-list to do the whole-history thing after all.
MAYBE we can fix that too at some point, but I won't promise anything.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/revision.c b/revision.c
index 0330f9f..0e3f074 100644
--- a/revision.c
+++ b/revision.c
@@ -702,7 +702,13 @@ int setup_revisions(int argc, const char
if (revs->prune_data) {
diff_tree_setup_paths(revs->prune_data);
revs->prune_fn = try_to_simplify_commit;
- revs->limited = 1;
+
+ /*
+ * If we fix up parent data, we currently cannot
+ * do that on-the-fly.
+ */
+ if (revs->parents)
+ revs->limited = 1;
}
return left;
@@ -763,23 +769,32 @@ struct commit *get_revision(struct rev_i
do {
struct commit *commit = revs->commits->item;
+
+ revs->commits = revs->commits->next;
+ /*
+ * If we haven't done the list limiting, we need to look at
+ * the parents here
+ */
+ if (!revs->limited)
+ add_parents_to_list(revs, commit, &revs->commits);
if (commit->object.flags & SHOWN)
- goto next;
+ continue;
if (!(commit->object.flags & BOUNDARY) &&
(commit->object.flags & UNINTERESTING))
- goto next;
+ continue;
if (revs->min_age != -1 && (commit->date > revs->min_age))
- goto next;
+ continue;
if (revs->max_age != -1 && (commit->date < revs->max_age))
return NULL;
if (revs->no_merges &&
commit->parents && commit->parents->next)
- goto next;
+ continue;
if (revs->prune_fn && revs->dense) {
if (!(commit->object.flags & TREECHANGE))
- goto next;
- rewrite_parents(commit);
+ continue;
+ if (revs->parents)
+ rewrite_parents(commit);
}
/* More to go? */
if (revs->max_count) {
@@ -792,13 +807,9 @@ struct commit *get_revision(struct rev_i
revs->commits = it->next;
free(it);
}
- else
- pop_most_recent_commit(&revs->commits, SEEN);
}
commit->object.flags |= SHOWN;
return commit;
-next:
- pop_most_recent_commit(&revs->commits, SEEN);
} while (revs->commits);
return NULL;
}
next prev parent reply other threads:[~2006-03-31 1:05 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-31 0:52 [PATCH/RFC 1/2] Move "--parent" parsing into generic revision.c library code Linus Torvalds
2006-03-31 1:05 ` Linus Torvalds [this message]
2006-03-31 6:05 ` [PATCH/RFC 2/2] Make path-limiting be incremental when possible Linus Torvalds
2006-03-31 6:45 ` Junio C Hamano
2006-03-31 19:39 ` Linus Torvalds
2006-03-31 20:35 ` Junio C Hamano
2006-03-31 20:50 ` Linus Torvalds
2006-03-31 6:16 ` Junio C Hamano
2006-03-31 6:42 ` Linus Torvalds
2006-03-31 7:02 ` Junio C Hamano
2006-04-02 0:35 ` Linus Torvalds
2006-04-02 3:11 ` Junio C Hamano
2006-04-02 3:17 ` [PATCH] revision: simplify argument parsing Junio C Hamano
[not found] ` <443063E2.1040904@lsrfire.ath.cx>
2006-04-03 4:22 ` Junio C Hamano
2006-04-02 3:17 ` [PATCH] revision: --max-age alone does not need limit_list() anymore Junio C Hamano
2006-03-31 8:28 ` [PATCH/RFC 2/2] Make path-limiting be incremental when possible Junio C Hamano
2006-03-31 19:44 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0603301652531.27203@g5.osdl.org \
--to=torvalds@osdl.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).