Problem merging

Problem merging

[Luben Tuikov]

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

Re: Problem merging

[Junio C Hamano]

Luben Tuikov <ltuikov@yahoo.com> writes:

> 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.

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)?

Re: Problem merging

[Luben Tuikov]

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

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

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

Re: Problem merging

[Johannes Schindelin]

Hi,

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

> Sorry, but I am not a good enough cryptoanalyst to reverse SHA1
> hashes,

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

Re: Problem merging

[Ben Clifford]

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

>
> I think nobody is. Since there are infinitely many files having the  
> same
> SHA1 (pigeon-hole principle),
>

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?

-- 
Ben • ベン • Бэн • 벤 • 班明
http://www.hawaga.org.uk/ben/
My email is high latency but best way to contact me. Alternatively,  
SMS number(s) at above URL.

Re: Problem merging

[Johannes Schindelin]

Hi,

On Thu, 24 Nov 2005, Ben Clifford wrote:

> On 24 Nov 2005, at 00:49, Johannes Schindelin wrote:
> 
> > I think nobody is. Since there are infinitely many files having the same
> > SHA1 (pigeon-hole principle),
> 
> 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?

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

Re: Problem merging

[Andreas Ericsson]

Ben Clifford 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?
> 

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

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Problem merging

[H. Peter Anvin]

Ben Clifford wrote:
> On 24 Nov 2005, at 00:49, Johannes Schindelin wrote:
> 
>>
>> I think nobody is. Since there are infinitely many files having the  same
>> SHA1 (pigeon-hole principle),
> 
> 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?
> 

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

Re: Problem merging

[Fredrik Kuivinen]

On Tue, Nov 22, 2005 at 06:50:01PM -0800, Luben Tuikov wrote:
> 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.

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

Re: Problem merging

[Junio C Hamano]

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

> 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...

Agreed; will patch.