>>>>> "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.



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