Fredrik Kuivinen <freku045@xxxxxxxxxxxxxx> writes:
> On Sun, Aug 13, 2006 at 03:54:19PM +0200, Johannes Schindelin wrote:
>> Hi,
>>
>> I tested git-merge-recur vs. git-merge-recursive on the linux-2.6
>> repository last night. It contains 2298 two-head merges. _All_ of them
>> come out identically with -recur as compared to -recursive (looking at
>> the resulting index only).
>
> After the latest updates to git-merge-recur it passes all the tests I
> have too.
>
>> That was the good news. The bad news is: it _seems_, that -recur is only
>> about 6x faster than -recursive, not 10x, and this number becomes smaller,
>> the longer the merge takes. So I see a startup effect here, probably.
>
> That is a quite nice improvement anyway :)
Maybe we should welcome Linus back with a surprise change that
makes recur take over recursive ;-).
Well, maybe not *that* fast.
Here is what I have in mind.
* Not in too distant future, like this weekend, we would:
- remove "TEST" at toplevel;
- merge the C merge-recur work in "master".
At this stage, people still have to ask for "recur" by either
explicitly saying "-s recur" or by exporting the environment
variable GIT_USE_RECUR_FOR_RECURSIVE=YesPlease; git
developers are encouraged to use this while running tests and
production.
* Before stabilization for 1.4.3, we would:
- rename merge-recursive to merge-recursive-old and
merge-recur to merge-recursive.
- we remove GIT_USE_RECUR_FOR_RECURSIVE hack.
- we make --no-python in t/ directory no-op and only test C
recursive implementation by default.
After this, people who would want to keep using the original
recursive have to ask for it by "-s recursive-old".
* We release 1.4.3 with C recursive as the default merge
strategy.
I am not at this moment thinking about removing recursive in
Python altogether. We still have a few contrib scripts
(p4import and gitview) that are in Python, so doing that would
not remove our dependency on Python anyway.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html