Problem merging

Ok, background:

I've two branches of the same .git, _but_ they live in different directories (bearing the branches' names) with different index caches, but with the same identical objects directory (different HEADs of course). (in effect, I have both branches "checked out")

Branch A is the "trunk", branch B is trunk+my changes. I do:

branchA: git pull <remote> branchA: cd ../branchB/ branchB: git resolve HEAD branchA "merge trunk"

And I get:

Trying to merge 4b4a27dff4e2d4cc2eac1cde31aede834a966a48 into e1ef47b54d7e7e477f7f1eb3251a9d37f38e0469 using 989e4d6cbc69191c41ddf4b1c492457410376b43. Simple merge failed, trying Automatic merge Removing include/asm-um/ldt.h fatal: merge program failed Automatic merge failed, fix up by hand

This is with git HEAD: 2392ee98eb76aa821de53c93c9e36acb18d27fc0 -- latest as of now.

Is this a bug in git? Since this process has always worked before.

Thanks,
    Luben

Luben Tuikov <ltuikov@yahoo.com> writes:

As "Merging two branches" section in Documentation/tutorial.txt shows, it is one of the valid outcome from merge to leave conflicts and have you manually resolve. So this process probably is working correctly for you this time as well.

Sorry, but I am not a good enough cryptoanalyst to reverse SHA1 hashes, and I cannot tell if the merge you did *should* have resulted in the conflict or not, just by looking at the three commit object IDs.

What does "git diff" and "git diff HEAD" tell you after the merge procedure leaves conflict in the working tree (branchB directory, I mean)?

--- Junio C Hamano <junkio@cox.net> wrote:

Apparently include/asm-um/ldt.h has been renamed and this was giving problems.

I had to manually git-update-index --force-remove that file and then git resolve worked ok.

   Luben

Hi,

On Tue, 22 Nov 2005, Junio C Hamano wrote:

I think nobody is. Since there are infinitely many files having the same SHA1 (pigeon-hole principle), there probably are infinitely many of them which compile just fine (and therefore could be the original).

Now, I tried to find all of them, but I, too, failed ;-)

Ciao, Dscho

On 24 Nov 2005, at 00:49, Johannes Schindelin wrote:

hmm... pigeon-hole principle is just that there exists two files that have the same SHA-1 as each other... doesn't say anything about *all* SHA-1s, though?

Hi,

On Thu, 24 Nov 2005, Ben Clifford wrote:

Okay, the second part of the truth is: It would be a lousy cryptographic hash (which it isn't), if the SHA1s were not uniformly distributed over the possible data.

You actually can be reasonably sure that given the SHA1s of all messages of length up to N (N being an integer at least the number of bits of the hash, i.e. 160 for SHA1), the counts of the different SHA1s should be equal.

Ciao, Dscho

Ben Clifford wrote:

It doesn't have to say that explicitly. It's universally applicable to all static-size checksum algorithms given an infinite amount of inputs.

Ben Clifford wrote:

There are an infinite number of possible files (specifically, aleph-null.) There are a finite number of possible SHA-1's (specifically, 1461501637330902918203684832716283019655932542976.) Therefore the pidgeon-hole principle tells you there must be at least one SHA-1 value that hashes an infinite number of files (aleph-null, again.)

Given that SHA-1 is believed to be uniformly distributed, it's quite likely *ALL* SHA-1's hash an infinite number of files, but the pigeon-hole principle can't tell you that.

	-hpa

On Tue, Nov 22, 2005 at 06:50:01PM -0800, Luben Tuikov wrote:

Have you tried this merge with the recursive merge strategy?

Btw is there a reason why 'recursive' isn't the default merge strategy for git-merge? It might be a bit confusing that git-pull and git-merge have different default strategies...

- Fredrik

Fredrik Kuivinen <freku045@student.liu.se> writes:

Agreed; will patch.