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,
currently).
-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
