>>>>> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> Just a heads-up - I'd really want to do the same thing to "merge-tree.c"
LT> too, but since you said that you were working on extending that to do
LT> recursion etc, I decided to hold off. So if you're working on it, maybe
LT> you can add the "-z" flag there too?
Sent as a separate patch already.
LT> I'm actually holding off merging the perl version exactly because you
LT> seemed to be working on the C version. I don't mind perl per se, but if
LT> there's a real solution coming down the line..
I'd take the hint, but I would say the current Perl version
would be far more usable than the C version I would come up with
by the end of this weekend because:
- the Perl version creates a new temporary directory and leaves
a ready-to-use dircache there---the only thing needed from
that point for you is to fix it up any conflicts and do
update-cache on that dircache. In that sense it is already
usable (Linus-usable, but probably not Pasky-usable due to
differences in phylosophy).
- the enhancement I am planning on the C version does not do
the real work itself, as you have originally written (the
workings and the output from it are outlined in [*R1*]).
Somebody has to write the executor part that does read-tree
the base, update-cache --cacheinfo --add for the selects,
runs 3-way merge on conflicting files and runs update-cache
for the merges, update-cache --remove for the deletes, before
it matches the usability of the Perl version. I do not
expect to have enough time this weekend to finish this.
I know of one case in Perl version I need to see if it does the
right thing but other than that it would be far better than the
C version I'm toying with.
Just to let you know, here is the plan I have for my part.
1. I am currently writing some test cases. The plan is first
to make sure the Perl version works OK with the test cases
to flush initial problems out.
2. After that I'll see if a dumb but recursive C version I
already have spits out the right instructions. This step is
to make sure that the test cases are sane, and by making
that sure, we will be able to say that we have something
usable in extremely short run (i.e. the Perl version) after
this step.
3. After that is done, I'll add the fourth argument to
merge-tree.c to specify the base so that it can cut down 90%
of trivial selects. Only after this happens the executioner
script would be useful performance wise.
[References]
*R1* <[EMAIL PROTECTED]>
-
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
