On Wed, 13 Apr 2005, Linus Torvalds wrote:

> I agree. But I did the silly "common revision tracking" part slightly
> differently and in particular I already made fsck and rev-tree use the 
> same exact code.

I think I only saw a cut-and-paste version, and I didn't want to follow
that pattern.

> Also, I don't see why you did the "common parent" thing as part of the
> "library", since that really does seem to be a very specific to this 
> problem, and neither fsck nor rev-tree really wants it. 

That was just silly; on the other hand, I think I'll eventually want to
have a "support-for-merging" library file, so that people can write
alternative merging programs which call library functions to pick out
history details. But that obviously shouldn't be the same file that
rev-tree and fsck share, and I'll probably do that by pulling main() out
of the program later.

> Also, the date parsing really is a separate issue from the revision 
> tracking (fsck does not want date parsing, but rev-tool does), so I think 
> you might want to do for date parsing what I just did for the revision.h 
> thing? No point in tying them together.

I think there is some value in having a library file that completely
parses "commit"-tagged files. Having the date field in struct revision
without the code to parse it in the file that defines the struct seems
poor to me.

> So could I ask you to re-factor it and base it on my current tree? Make 
> the "merge-base" program have that common parent thing in it, and factor 
> out the common date parsing into "parse-date.c" or something?

I'm not actually using the date in merge-base, either, so I'll just leave
that alone for now (merge-base is based on generations, not time,

*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

Reply via email to