Re: [PATCH 2/2] Add a 'source' decorator for commits
- From
Pierre Habouzit <madcoder@debian.org>
- Date
- Oct 28, 2008, 13:11 UTC
- Message-ID
- <20081028131116.GA8272@artemis.googlewifi.com>
- In-Reply-To
- <20081028054539.GA23195@sigill.intra.peff.net>
On Tue, Oct 28, 2008 at 05:45:40AM +0000, Jeff King wrote:
Show 13 quoted lines
> On Mon, Oct 27, 2008 at 01:07:10PM -0700, Linus Torvalds wrote: > > Of course, if the commit is reachable through multiple sources (which is > > common), our particular choice of "first" reachable is entirely random > > and depends on the particular path we happened to follow. > > Hmm. It would be nice to keep even a simple counter to get a "distance" > from the ref and choose the one with the smallest distance (I think we > can get away without the complex rules that git-describe uses, since we > are not interested in describing the full commit, but rather finding a > "likely" branch). > > However, that would require making multiple passes over the commit > graph, which might impact the startup speed.
Actually I tried to do that (and you meant name-rev --contains rather than describe actually ;p), and I stopped because it's too slow. I believe the proper way to do that is to help git-log knowing which are the short (topic) branches, and to crawl incrementally using a date-based hack. This would basically work a bit like this. Let's imaging you want to crawl "next" in git and know which topics from pu are in it. You would say e.g.:
git-log --topics=*/* next (as pretty much every */* is a topic branch for git.git).
Then one has to know which are the heads of every topic branches first, then crawl next the usual way, except that when you arrive to a point that is a topic branch head, you don't look that way. You remember the date of that point, and continue to crawl "next" a bit further so that you can start annotating the topic's commits you've stumbled upon. And you do that, you look at jd/topic (as in John Doe topic branch) and mark all the commits as being from jd/topic, until you either go back to some commit from next, or your current commit date is younger than your current "next" crawling front. In the former case, you're done with that topic, in the latter you must continue to preprocess "next" a bit more.
That should allow incremental output, FSVO incremental (in the git.git kind of integration, you have buckets of topic branches merges, and basically we would have output being spit bucket per bucket I believe).
If you do that, you don't really need to keep distance scores, this should, I believe, yield decent enough results, while being incremental, which should yield almost instantaneous output.
Point is, I've no clue how to do that with our crawling primitives right now, to be fair, I didn't looked at it because I'm lazy and don't have enough topic branches to work with in my projects, so it's not an itch yet ;)
-- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org