git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Junio C Hamano <junkio@cox.net>, Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 3/2] Optimize the two-way merge of git-read-tree too
Date: Fri, 10 Aug 2007 12:53:51 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.0.999.0708101240200.30176@woody.linux-foundation.org> (raw)
In-Reply-To: <alpine.LFD.0.999.0708101224110.30176@woody.linux-foundation.org>


On Fri, 10 Aug 2007, Linus Torvalds wrote:
> 
> This trivially optimizes the two-way merge case of git-read-tree too, 
> which affects switching branches.

Side note, if this wasn't obvious: this series of three patches (four, if 
you count the one in this email) obviates the need for Junio's hacky fix 
from yesterday that removed the "-i -m" flags from "git read-tree" in 
git-commit.sh, and made builtin-read-tree sometimes use the "read_tree()" 
function.

Now "unpack_trees()" is just fast enough that we don't need to avoid it 
(although it's probably still a good idea to eventually convert it to use 
the traverse_trees() infrastructure some day - just to avoid having 
extraneous tree traversal functions).

And as mentioned, the three-way case *should* be as trivial as the 
following. It passes all the tests, and I verified that a conflicting 
merge in the 100,000 file horror-case merged correctly (with the conflict 
markers) in 0.687 seconds with this, so it works, but I'm lazy and 
somebody else should double-check it.

(Again - *without* this patch, the merge took 8.355 seconds, so this patch 
really does make a huge difference for merge performance with lots and 
lots of files, and we're not talking percentages, we're talking 
orders-of-magnitude differences!)

		Linus

---
 unpack-trees.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/unpack-trees.c b/unpack-trees.c
index 810816e..ccfeb6e 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -667,7 +667,6 @@ int threeway_merge(struct cache_entry **stages,
 	int no_anc_exists = 1;
 	int i;
 
-	remove_entry(remove);		
 	for (i = 1; i < o->head_idx; i++) {
 		if (!stages[i] || stages[i] == o->df_conflict_entry)
 			any_anc_missing = 1;
@@ -730,8 +729,10 @@ int threeway_merge(struct cache_entry **stages,
 	}
 
 	/* #1 */
-	if (!head && !remote && any_anc_missing)
+	if (!head && !remote && any_anc_missing) {
+		remove_entry(remove);
 		return 0;
+	}
 
 	/* Under the new "aggressive" rule, we resolve mostly trivial
 	 * cases that we historically had git-merge-one-file resolve.
@@ -763,6 +764,7 @@ int threeway_merge(struct cache_entry **stages,
 		if ((head_deleted && remote_deleted) ||
 		    (head_deleted && remote && remote_match) ||
 		    (remote_deleted && head && head_match)) {
+			remove_entry(remove);
 			if (index)
 				return deleted_entry(index, index, o);
 			else if (ce && !head_deleted)
@@ -785,6 +787,7 @@ int threeway_merge(struct cache_entry **stages,
 		verify_uptodate(index, o);
 	}
 
+	remove_entry(remove);
 	o->nontrivial_merge = 1;
 
 	/* #2, #3, #4, #6, #7, #9, #10, #11. */

  reply	other threads:[~2007-08-10 19:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <alpine.LFD.0.999.0708101213560.30176@woody.linux-foundation.or g>
2007-08-10 19:15 ` [PATCH 1/2] Move old index entry removal from "unpack_trees()" into the individual functions Linus Torvalds
2007-08-10 19:21   ` [PATCH 2/2] Optimize the common cases of git-read-tree Linus Torvalds
2007-08-10 19:31     ` [PATCH 3/2] Optimize the two-way merge of git-read-tree too Linus Torvalds
2007-08-10 19:53       ` Linus Torvalds [this message]
2007-08-11  5:57         ` Junio C Hamano
2007-08-11  9:17         ` Junio C Hamano
2007-08-11 17:27           ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.0.999.0708101240200.30176@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).