On Sun, 17 Apr 2005, Linus Torvalds wrote:
> 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.
I entirely missed this. No wonder my fsck-cache conversion wasn't going
so well...
> 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.
I actually want the tree for http-pull, not merging stuff. I was trying to
get a commit parser, not reachability at that point.
I think the right thing is to make a separate struct commit that has the
stuff I want in it, and probably do a struct tree at the same time.
-Daniel
*This .sig left intentionally blank*
-
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
