Re: [PATCH] merge-base

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Apr 14, 2005, 17:17 UTC
Message-ID: <Pine.LNX.4.21.0504141234490.30848-100000@iabervon.org>
In-Reply-To: <Pine.LNX.4.58.0504132040020.7211@ppc970.osdl.org>

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*