On Sun, 17 Apr 2005, Daniel Barkalow wrote:
> --- 45f926575d2c44072bfcf2317dbf3f0fbb513a4e/revision.h  (mode:100644 
> sha1:28d0de3261a61f68e4e0948a25a416a515cd2e83)
> +++ 37a0b01b85c2999243674d48bfc71cdba0e5518e/revision.h  (mode:100644 
> sha1:523bde6e14e18bb0ecbded8f83ad4df93fc467ab)
> @@ -24,6 +24,7 @@
>       unsigned int flags;
>       unsigned char sha1[20];
>       unsigned long date;
> +     unsigned char tree[20];
>       struct parent *parent;
>  };

I think this is really wrong.

The whole point of "revision.h" is that it's a generic framework for 
keeping track of relationships between different objects. And those 
objects are in no way just "commit" objects.

For example, fsck uses this "struct revision" to create a full free of 
_all_ the object dependencies, which means that a "struct revision" can be 
any object at all - it's not in any way limited to commit objects, and 
there is no "tree" object that is associated with these things at all.

Besides, why do you want the tree? There's really nothing you can do with 
the tree to a first approximation - you need to _first_ do the 
reachability analysis entirely on the commit dependencies, and then when 
you've selected a set of commits, you can just output those.

Later phases will indeed look up what the tree is, but that's only after
you've decided on the commit object. There's no point in looking up (or
even trying to just remember) _all_ the tree objects.


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

Reply via email to