octopus limit

octopus limit

[Len Brown]

it would be nice if a merge of more than 16 branches failed
right at the start, rather than chunking along doing merges
and then giving up, leaving my repo in an intermediate state.

cheers,
-len

git merge test acpica bugzilla-10807-v2 bugzilla-10927 bugzilla-6217 
bugzilla-9684 bugzilla-9704 bugzilla-9772 compal-laptop debug-test 
dev-printk fujitsu-laptop gpe-debug misc per-cpu pnp-v3 suspend wmi-2.6.27
Already up-to-date with c4e6a2e64e948de42473e9c829181d768b1258c3
Trying simple merge with aa10d9f35361d3b260750f305ba8eb41c78e1a29
Trying simple merge with 23ac069d8be58c314af149dca2bb42dafdc38069
Trying simple merge with 60d40a50886415040888bde5133ccfeab40d945f
Trying simple merge with a7f34ae2abc9cb51a5b906f2da0aaa697f1a8883
Simple merge did not work, trying automatic merge.
Auto-merging drivers/acpi/events/evgpe.c
Trying simple merge with 009733ab59c05c4331c5504001587562e66a0d2b
Trying simple merge with 7004cf59cbfa54bc5ef0b3c5e0f81af410365e07
Trying simple merge with ad7f0d9feee6980a3ab3ea806854f56817d1da8e
Simple merge did not work, trying automatic merge.
Auto-merging drivers/acpi/processor_core.c
Auto-merging drivers/acpi/scan.c
Auto-merging kernel/cpu.c
Trying simple merge with 46c636862ee7e2f45e3369393f7c00761727e674
Simple merge did not work, trying automatic merge.
Auto-merging MAINTAINERS
Trying simple merge with 9e030ab0bffdc8b6d8be663b639bd5e2374537f0
Simple merge did not work, trying automatic merge.
Auto-merging drivers/acpi/namespace/nsxfeval.c
Auto-merging drivers/acpi/utilities/utmisc.c
Trying simple merge with 48e25157d315ec5fed3f5e1db88119dcde6175ea
Trying simple merge with 770c091f85a922d92505e2da8b30cf30dd6bc2f3
Simple merge did not work, trying automatic merge.
Auto-merging MAINTAINERS
Auto-merging drivers/misc/Kconfig
Trying simple merge with bb9babebc64541307d2eca41ed8e4c977f4beb10
Simple merge did not work, trying automatic merge.
Auto-merging drivers/acpi/hardware/hwgpe.c
Auto-merging include/acpi/achware.h
Auto-merging include/acpi/acpixf.h
Trying simple merge with eac9c2dc06e1ea25efebcd3d508c0ae40f4a9ece
Simple merge did not work, trying automatic merge.
Auto-merging include/acpi/aclocal.h
Trying simple merge with e1d755bbddba413c4050db1bfbe1f7e17dee3002
Simple merge did not work, trying automatic merge.
Auto-merging drivers/acpi/processor_core.c
Auto-merging drivers/acpi/processor_idle.c
Auto-merging drivers/acpi/processor_throttling.c
Auto-merging include/acpi/processor.h
Trying simple merge with f382348d43f80b6267a0881729366be2e5542ace
Trying simple merge with a143f92aca5eaf9a4ac608f7d208592e514574ed
Simple merge did not work, trying automatic merge.
Auto-merging drivers/acpi/sleep/main.c
Trying simple merge with 1a76b5a83e977cee4cd27c2f45a239a5faa9c1cc
fatal: Too many parents (16 max)

Re: octopus limit

[Matthieu Moy]

Len Brown <lenb@kernel.org> writes:

> it would be nice if a merge of more than 16 branches failed
> right at the start, rather than chunking along doing merges
> and then giving up, leaving my repo in an intermediate state.

There's a patch around which should remove this limitation (I think
it's the builtin-ification of merge).

-- 
Matthieu

Re: octopus limit

[Johannes Schindelin]

Hi,

On Thu, 26 Jun 2008, Len Brown wrote:

> it would be nice if a merge of more than 16 branches failed right at the 
> start, rather than chunking along doing merges and then giving up, 
> leaving my repo in an intermediate state.

FWIW I think the rewrite of git-merge as a builtin, which is currently in 
the works, lifts the limit.  However, this is only true if you do not use 
a custom script which calls commit-tree.

Ciao,
Dscho

[PATCH] commit-tree: lift completely arbitrary limit of 16 parents

[Johannes Schindelin]

There is no really good reason to have a merge with more than 16
parents, but we have a history of giving our users rope.

Combined with the fact that there was no good reason for that
arbitrary limit in the first place, here is an all-too-easy to fix.

Kind of wished-for by Len Brown.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	On Fri, 27 Jun 2008, Johannes Schindelin wrote:

	> On Thu, 26 Jun 2008, Len Brown wrote:
	> 
	> > it would be nice if a merge of more than 16 branches failed 
	> > right at the start, rather than chunking along doing merges and then 
	> > giving up, leaving my repo in an intermediate state.
	> 
	> FWIW I think the rewrite of git-merge as a builtin, which is 
	> currently in the works, lifts the limit.  However, this is only true if 
	> you do not use a custom script which calls commit-tree.

	And here is a patch to fix commit-tree.

 builtin-commit-tree.c |   43 ++++++++++++++++++++-----------------------
 1 files changed, 20 insertions(+), 23 deletions(-)

diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
index e5e4bdb..5931a92 100644
--- a/builtin-commit-tree.c
+++ b/builtin-commit-tree.c
@@ -24,26 +24,20 @@ static void check_valid(unsigned char *sha1, enum object_type expect)
 		    typename(expect));
 }
 
-/*
- * Having more than two parents is not strange at all, and this is
- * how multi-way merges are represented.
- */
-#define MAXPARENT (16)
-static unsigned char parent_sha1[MAXPARENT][20];
-
 static const char commit_tree_usage[] = "git-commit-tree <sha1> [-p <sha1>]* < changelog";
 
-static int new_parent(int idx)
+static void new_parent(struct commit *parent, struct commit_list **parents_p)
 {
-	int i;
-	unsigned char *sha1 = parent_sha1[idx];
-	for (i = 0; i < idx; i++) {
-		if (!hashcmp(parent_sha1[i], sha1)) {
+	unsigned char *sha1 = parent->object.sha1;
+	struct commit_list *parents;
+	for (parents = *parents_p; parents; parents = parents->next) {
+		if (!hashcmp(parents->item->object.sha1, sha1)) {
 			error("duplicate parent %s ignored", sha1_to_hex(sha1));
-			return 0;
+			return;
 		}
+		parents_p = &parents->next;
 	}
-	return 1;
+	commit_list_insert(parent, parents_p);
 }
 
 static const char commit_utf8_warn[] =
@@ -54,7 +48,7 @@ static const char commit_utf8_warn[] =
 int cmd_commit_tree(int argc, const char **argv, const char *prefix)
 {
 	int i;
-	int parents = 0;
+	struct commit_list *parents = NULL;
 	unsigned char tree_sha1[20];
 	unsigned char commit_sha1[20];
 	struct strbuf buffer;
@@ -69,18 +63,16 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
 
 	check_valid(tree_sha1, OBJ_TREE);
 	for (i = 2; i < argc; i += 2) {
+		unsigned char sha1[40];
 		const char *a, *b;
 		a = argv[i]; b = argv[i+1];
 		if (!b || strcmp(a, "-p"))
 			usage(commit_tree_usage);
 
-		if (parents >= MAXPARENT)
-			die("Too many parents (%d max)", MAXPARENT);
-		if (get_sha1(b, parent_sha1[parents]))
+		if (get_sha1(b, sha1))
 			die("Not a valid object name %s", b);
-		check_valid(parent_sha1[parents], OBJ_COMMIT);
-		if (new_parent(parents))
-			parents++;
+		check_valid(sha1, OBJ_COMMIT);
+		new_parent(lookup_commit(sha1), &parents);
 	}
 
 	/* Not having i18n.commitencoding is the same as having utf-8 */
@@ -94,8 +86,13 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
 	 * different order of parents will be a _different_ changeset even
 	 * if everything else stays the same.
 	 */
-	for (i = 0; i < parents; i++)
-		strbuf_addf(&buffer, "parent %s\n", sha1_to_hex(parent_sha1[i]));
+	while (parents) {
+		struct commit_list *next = parents->next;
+		strbuf_addf(&buffer, "parent %s\n",
+			sha1_to_hex(parents->item->object.sha1));
+		free(parents);
+		parents = next;
+	}
 
 	/* Person/date information */
 	strbuf_addf(&buffer, "author %s\n", git_author_info(IDENT_ERROR_ON_NO_NAME));
-- 
1.5.6.173.gde14c

Re: [PATCH] commit-tree: lift completely arbitrary limit of 16 parents

[Johannes Sixt]

Johannes Schindelin schrieb:
> @@ -69,18 +63,16 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
>  
>  	check_valid(tree_sha1, OBJ_TREE);
>  	for (i = 2; i < argc; i += 2) {
> +		unsigned char sha1[40];

		unsigned char sha1[20];

is sufficient here, /me thinks.

-- Hannes

Re: [PATCH] commit-tree: lift completely arbitrary limit of 16 parents

[Johannes Schindelin]

Hi,

On Fri, 27 Jun 2008, Johannes Sixt wrote:

> Johannes Schindelin schrieb:
> > @@ -69,18 +63,16 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
> >  
> >  	check_valid(tree_sha1, OBJ_TREE);
> >  	for (i = 2; i < argc; i += 2) {
> > +		unsigned char sha1[40];
> 
> 		unsigned char sha1[20];
> 
> is sufficient here, /me thinks.

Ooops.  Completely correct.

Junio, want me to fix it up?  Or do you want me not to bother with this 
patch at all?

Ciao,
Dscho

Re: octopus limit

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 296 bytes --]

On Fri, Jun 27, 2008 at 08:33:37AM +0200, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> There's a patch around which should remove this limitation (I think
> it's the builtin-ification of merge).

It's in 'pu', so in case you really need it *now*, then just get git.git
and build the 'pu' branch.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] commit-tree: lift completely arbitrary limit of 16 parents

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> -static int new_parent(int idx)
> +static void new_parent(struct commit *parent, struct commit_list **parents_p)
>  {
> -	int i;
> -	unsigned char *sha1 = parent_sha1[idx];
> -	for (i = 0; i < idx; i++) {
> -		if (!hashcmp(parent_sha1[i], sha1)) {
> +	unsigned char *sha1 = parent->object.sha1;
> +	struct commit_list *parents;
> +	for (parents = *parents_p; parents; parents = parents->next) {
> +		if (!hashcmp(parents->item->object.sha1, sha1)) {

Wouldn't it be enough to compare (parents->item == parent)?

> @@ -69,18 +63,16 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
>  
>  	check_valid(tree_sha1, OBJ_TREE);
>  	for (i = 2; i < argc; i += 2) {
> +		unsigned char sha1[40];

s/4/2/;

Re: [PATCH] commit-tree: lift completely arbitrary limit of 16 parents

[Johannes Schindelin]

Hi,

On Fri, 27 Jun 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > -static int new_parent(int idx)
> > +static void new_parent(struct commit *parent, struct commit_list **parents_p)
> >  {
> > -	int i;
> > -	unsigned char *sha1 = parent_sha1[idx];
> > -	for (i = 0; i < idx; i++) {
> > -		if (!hashcmp(parent_sha1[i], sha1)) {
> > +	unsigned char *sha1 = parent->object.sha1;
> > +	struct commit_list *parents;
> > +	for (parents = *parents_p; parents; parents = parents->next) {
> > +		if (!hashcmp(parents->item->object.sha1, sha1)) {
> 
> Wouldn't it be enough to compare (parents->item == parent)?

Probably, since we now use lookup_commit().  Feel free to change.

> > @@ -69,18 +63,16 @@ int cmd_commit_tree(int argc, const char **argv, 
> > const char *prefix)
> >  
> >  	check_valid(tree_sha1, OBJ_TREE);
> >  	for (i = 2; i < argc; i += 2) {
> > +		unsigned char sha1[40];
> 
> s/4/2/;

Yes, I admitted that already in response to Hannes.

Mea culpa, mea maxima culpa.

Sorry,
Dscho