Re: [PATCH 0/2] A new merge algorithm, take 3

2005-09-08 Thread Fredrik Kuivinen
On Wed, Sep 07, 2005 at 02:33:42PM -0400, Daniel Barkalow wrote: On Wed, 7 Sep 2005, Fredrik Kuivinen wrote: Of the 500 merge commits that currently exists in the kernel repository 19 produces non-clean merges with git-merge-script. The four merge cases listed in [EMAIL PROTECTED] are

Re: [PATCH 0/2] A new merge algorithm, take 3

2005-09-08 Thread Daniel Barkalow
On Thu, 8 Sep 2005, Fredrik Kuivinen wrote: On Wed, Sep 07, 2005 at 02:33:42PM -0400, Daniel Barkalow wrote: On Wed, 7 Sep 2005, Fredrik Kuivinen wrote: Of the 500 merge commits that currently exists in the kernel repository 19 produces non-clean merges with git-merge-script. The

Re: [PATCH 0/2] A new merge algorithm, take 3

2005-09-08 Thread Junio C Hamano
Chuck Lever [EMAIL PROTECTED] writes: Junio C Hamano wrote: Chuck Lever [EMAIL PROTECTED] writes: once the list implementation is working well, i plan to go back and replace it with something more sophisticated which can perform insertion, deletion, and searching efficiently. Well, what

Re: [PATCH 0/2] A new merge algorithm, take 3

2005-09-08 Thread Linus Torvalds
On Thu, 8 Sep 2005, Junio C Hamano wrote: Yes, the reading of three trees upfront is probably the culprit in your case However, note that _most_ tree reading just reads one. Merges may take half a second, and yes, when I did it, the fact that we move things around in the array is by far

Re: [PATCH 0/2] A new merge algorithm, take 3

2005-09-08 Thread Junio C Hamano
Linus Torvalds [EMAIL PROTECTED] writes: So the data structure is optimized for a different case than reading in trees. Big deal. That optimization is definitely worth it: it allows us to do the read_cache() with the actual index entries being totally read-only (a linked list would have to

Re: [PATCH 0/2] A new merge algorithm, take 3

2005-09-08 Thread Chuck Lever
Linus Torvalds wrote: On Thu, 8 Sep 2005, Junio C Hamano wrote: Yes, the reading of three trees upfront is probably the culprit in your case However, note that _most_ tree reading just reads one. Merges may take half a second, and yes, when I did it, the fact that we move things around

Re: [PATCH 0/2] A new merge algorithm, take 3

2005-09-08 Thread Linus Torvalds
On Thu, 8 Sep 2005, Chuck Lever wrote: in my case the merges were taking significantly longer than a half second. making this change is certainly not worth it if merges are running fast... Note that in cold-cache cases, all the expense of read-tree is in actually reading the tree

Re: [PATCH 0/2] A new merge algorithm, take 3

2005-09-08 Thread Chuck Lever
Linus Torvalds wrote: On Thu, 8 Sep 2005, Chuck Lever wrote: in my case the merges were taking significantly longer than a half second. making this change is certainly not worth it if merges are running fast... Note that in cold-cache cases, all the expense of read-tree is in actually

Re: [PATCH 0/2] A new merge algorithm, take 3

2005-09-08 Thread Fredrik Kuivinen
On Thu, Sep 08, 2005 at 11:27:35AM -0400, Daniel Barkalow wrote: ... The two cases my algorithm merges cleanly and git-resolve-script do not merge cleanly are 0e396ee43e445cb7c215a98da4e76d0ce354d9d7 and 0c168775709faa74c1b87f1e61046e0c51ade7f3. Both of them have two common ancestors.

Re: [PATCH 0/2] A new merge algorithm, take 3

2005-09-08 Thread Junio C Hamano
Junio C Hamano [EMAIL PROTECTED] writes: ... I'd like to leave what merge strategy to use as an user option, and leave the door open for other merge strategies to emerge later. I know Pasky wants to look into pcdv merge and other alternatives. This is still off-the-top-of-my-head, but the

Re: [PATCH 0/2] A new merge algorithm, take 3

2005-09-08 Thread A Large Angry SCM
Junio C Hamano wrote: [...] Subject: [PATCH] Multi-backend merge driver. This is just an illustration of concept patch. The new command 'git merge' takes the current head and one or more remote heads, with the commit log message for the automated case. If the heads being merged are simple

Re: [PATCH 0/2] A new merge algorithm, take 3

2005-09-08 Thread Daniel Barkalow
On Thu, 8 Sep 2005, Fredrik Kuivinen wrote: The first one agrees with what was actually committed. For the second one the difference between the tree produced by the algorithm and what was committed is: diff --git a/include/net/ieee80211.h b/include/net/ieee80211.h ---

Re: [PATCH 0/2] A new merge algorithm, take 3

2005-09-07 Thread Daniel Barkalow
On Wed, 7 Sep 2005, Fredrik Kuivinen wrote: Of the 500 merge commits that currently exists in the kernel repository 19 produces non-clean merges with git-merge-script. The four merge cases listed in [EMAIL PROTECTED] are cleanly merged by git-merge-script. Every merge commit which is cleanly

Re: [PATCH 0/2] A new merge algorithm, take 3

2005-09-07 Thread Junio C Hamano
Fredrik Kuivinen [EMAIL PROTECTED] writes: I guess the need for this has decreased with Daniel's new read-tree code. Is there any chance of getting this code merged into mainline git? I do not think Daniel's code decreased anything. The two algorithms are solving the same problem but they do