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
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
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
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
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
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
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
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
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.
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
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
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
---
Hi,
Here is the new version of the merge algorithm patch.
The major changes compared to the previous patch are:
* No more messing around with merge-cache. git-ls-files used to get
the unmerged entries instead.
* The python code is now contained in two files, git-merge-script and
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
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
15 matches
Mail list logo