From: Linus Torvalds <torvalds@osdl.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: Handling large files with GIT
Date: Tue, 14 Feb 2006 18:18:21 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0602141811050.3691@g5.osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0602141741210.3691@g5.osdl.org>
On Tue, 14 Feb 2006, Linus Torvalds wrote:
>
> Finally (a more serious caveat):
> - doing things through stdout may end up being so expensive that we'd
> need to do something else. In particular, it's likely that I should
> not actually output the "merge results", but instead output a "merge
> results as they _differ_ from branch1"
>
> In many ways, the really _interesting_ part of a merge is not the result,
> but how it _changes_ the branch we're merging into. That's particularly
> important as it should hopefully also mean that the output size for any
> reasonable case is minimal (and tracks what we actually need to do to the
> current state to create the final result).
Here, btw, is the trivial diff to turn my previous "tree-resolve" into a
"resolve tree relative to the current branch".
In particular, it makes the example merge perhaps even more interesting,
and makes the "merging directories and merging files should use different
heuristics more obvious". It's quite instructive, I think.
So if you want to test this, the merge I have been testing with is the
last infiniband merge in the kernel:
git-merge-tree 3c3b809 4cbf876 7d2babc
and you'll need to spend a few moments on thinking about what the
"directory merge" thing there means: in particular, we should probably
make the
if (entry[2].sha1) {
test be
if (entry[2].sha && !S_ISDIR(entry[2].mode)) {
(and same for "resolve to entry[1]" case for that matter) so that we never
create a "resolve()" that picks a whole subdirectory from one of the
branches.
The current logic is "logical", just probably not what we want.
Linus
----
diff --git a/merge-tree.c b/merge-tree.c
index 0d6d434..0bf871c 100644
--- a/merge-tree.c
+++ b/merge-tree.c
@@ -55,9 +55,19 @@ static int same_entry(struct name_entry
a->mode == b->mode;
}
-static void resolve(const char *base, struct name_entry *result)
+static void resolve(const char *base, struct name_entry *branch1, struct name_entry *result)
{
- printf("0 %06o %s %s%s\n", result->mode, sha1_to_hex(result->sha1), base, result->path);
+ char branch1_sha1[50];
+
+ /* If it's already branch1, don't bother showing it */
+ if (!branch1)
+ return;
+ memcpy(branch1_sha1, sha1_to_hex(branch1->sha1), 41);
+
+ printf("0 %06o->%06o %s->%s %s%s\n",
+ branch1->mode, result->mode,
+ branch1_sha1, sha1_to_hex(result->sha1),
+ base, result->path);
}
static int unresolved_directory(const char *base, struct name_entry n[3])
@@ -183,21 +193,21 @@ static void merge_trees(struct tree_desc
/* Same in both? */
if (same_entry(entry+1, entry+2)) {
if (entry[0].sha1) {
- resolve(base, entry+1);
+ resolve(base, NULL, entry+1);
continue;
}
}
if (same_entry(entry+0, entry+1)) {
if (entry[2].sha1) {
- resolve(base, entry+2);
+ resolve(base, entry+1, entry+2);
continue;
}
}
if (same_entry(entry+0, entry+2)) {
if (entry[1].sha1) {
- resolve(base, entry+1);
+ resolve(base, NULL, entry+1);
continue;
}
}
next prev parent reply other threads:[~2006-02-15 2:18 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-08 9:14 Handling large files with GIT Martin Langhoff
2006-02-08 11:54 ` Johannes Schindelin
2006-02-08 16:34 ` Linus Torvalds
2006-02-08 17:01 ` Linus Torvalds
2006-02-08 20:11 ` Junio C Hamano
2006-02-08 21:20 ` Florian Weimer
2006-02-08 22:35 ` Martin Langhoff
2006-02-13 1:26 ` Ben Clifford
2006-02-13 3:42 ` Linus Torvalds
2006-02-13 4:57 ` Linus Torvalds
2006-02-13 5:05 ` Linus Torvalds
2006-02-13 23:17 ` Ian Molton
2006-02-13 23:19 ` Martin Langhoff
2006-02-14 18:56 ` Johannes Schindelin
2006-02-14 19:52 ` Linus Torvalds
2006-02-14 21:21 ` Sam Vilain
2006-02-14 22:01 ` Linus Torvalds
2006-02-14 22:30 ` Junio C Hamano
2006-02-15 0:40 ` Sam Vilain
2006-02-15 1:39 ` Junio C Hamano
2006-02-15 4:03 ` Sam Vilain
2006-02-15 2:07 ` Martin Langhoff
2006-02-15 2:05 ` Linus Torvalds
2006-02-15 2:18 ` Linus Torvalds [this message]
2006-02-15 2:33 ` Linus Torvalds
2006-02-15 3:58 ` Linus Torvalds
2006-02-15 9:54 ` Junio C Hamano
2006-02-15 15:44 ` Linus Torvalds
2006-02-15 17:16 ` Linus Torvalds
2006-02-16 3:25 ` Linus Torvalds
2006-02-16 3:29 ` Junio C Hamano
2006-02-16 20:32 ` Fredrik Kuivinen
2006-02-13 5:55 ` Jeff Garzik
2006-02-13 6:07 ` Keith Packard
2006-02-14 0:07 ` Martin Langhoff
2006-02-13 16:19 ` Linus Torvalds
2006-02-13 4:40 ` Martin Langhoff
2006-02-09 4:54 ` Greg KH
2006-02-09 5:38 ` Martin Langhoff
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=Pine.LNX.4.64.0602141811050.3691@g5.osdl.org \
--to=torvalds@osdl.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).