Unexpected behaviour when trying to merge two new repositories.

Unexpected behaviour when trying to merge two new repositories.

[Ben Aveling]

Hi,

I have a directory of files that have been copied between different 
machines, and then drifted apart.

I was trying to merge the different versions into a single unified 
repository.

I succeeded, but I had to navigate though, and recover from, what seems 
to me to be counter-intuitive behaviour.

Let me walk through a mock up of what I did.

Scenario 1. Merging two repositories.

Mock up first directory, and commit it.

   > mkdir a
   > git init a
   Initialized empty Git repository in /tmp/a/.git/
   > cd a
   > echo 1 > 1
   > echo 2 > 2
   > git add .
   > git commit -m "add 1 and 2"
   [master (root-commit) 9a649ab] add 1 and 2
    2 files changed, 2 insertions(+), 0 deletions(-)
    create mode 100644 1
    create mode 100644 2

Mock up second directory. Add files, but don't commit.

   > mkdir b
   > cd ../b
   > git init
   Initialized empty Git repository in /tmp/b/.git/
   > echo 1 > 1
   > echo 3 > 3
   > git pull ../a
   remote: Counting objects: 4, done.
   remote: Compressing objects: 100% (2/2), done.
   remote: Total 4 (delta 0), reused 0 (delta 0)
   Unpacking objects: 100% (4/4), done.
   From ../a
    * branch            HEAD       -> FETCH_HEAD
   error: Untracked working tree file '1' would be overwritten by merge.
   > git add 1 3

Now merge in the first directory.

   > git pull ../a master
   From ../a
    * branch            master     -> FETCH_HEAD
   Already up-to-date.
   > git status
   # On branch master
   # Changes to be committed:
   #   (use "git reset HEAD <file>..." to unstage)
   #
   #    deleted:    2
   #    new file:   3
   #

This surprised me. I wasn't expecting 2 to be deleted. And I wasn't 
expecting to be told that it was "Already up to date".

Scenario 2. Merging two repositories with everything committed.

Mock up a third directory. Add files and this time, commit. Then merge 
from a.

   > mkdir ../c
   > cd ../c
   > git init
   Initialized empty Git repository in /tmp/c/.git/
   > echo 1 > 1
   > echo 4 > 4
   > git add 1 4
   > git commit -m "add 1 and 4"
   [master (root-commit) b6081d9] add 1 and 4
    2 files changed, 2 insertions(+), 0 deletions(-)
    create mode 100644 1
    create mode 100644 4
   > git pull ../a master
   warning: no common commits
   remote: Counting objects: 4, done.
   remote: Compressing objects: 100% (2/2), done.
   remote: Total 4 (delta 0), reused 0 (delta 0)
   Unpacking objects: 100% (4/4), done.
   From ../a
    * branch            master     -> FETCH_HEAD
   Merge made by recursive.
    2 |    1 +
    1 files changed, 1 insertions(+), 0 deletions(-)
    create mode 100644 2
   > ll *
   -rw-rw-r-- 1 ben ben 2 2012-12-15 15:02 1
   -rw-rw-r-- 1 ben ben 2 2012-12-15 15:10 2
   -rw-rw-r-- 1 ben ben 2 2012-12-15 15:03 4

This is what I was expecting the first time.

It seems that if there are no commits in the new repository, git doesn't 
detect that there are no common commits.

Scenario 3. Merge with uncommitted changes.

Create another mock directory. Create some of the same files, but with 
different contents. Again, add them but don't commit.

   > mkdir ../d
   > cd ../d
   > git init
   Initialized empty Git repository in /tmp/d/.git/
   > echo 1a > 1
   > echo 5 > 5
   > git add 1 5
   > git commit -m "add 1 and 5"
   [master (root-commit) b6081d9] add 1 and 5
    2 files changed, 2 insertions(+), 0 deletions(-)
    create mode 100644 1
    create mode 100644 5
   > git pull ../a master
   remote: Counting objects: 4, done.
   remote: Compressing objects: 100% (2/2), done.
   remote: Total 4 (delta 0), reused 0 (delta 0)
   Unpacking objects: 100% (4/4), done.
   From ../a
    * branch            master     -> FETCH_HEAD
   > git status
   # On branch master
   nothing to commit (working directory clean)
   > ls -l
   total 8
   -rw-rw-r-- 1 ben ben 2 2012-12-15 15:31 1
   -rw-rw-r-- 1 ben ben 2 2012-12-15 15:31 2

This too, surprised me.  This time, the incoming file was added where 
before it was deleted. And file 5 has vanished.

   > git fsck
   dangling blob a8994dc188ebbbc9e8a885470651a7fbb9127528
   dangling blob 7ed6ff82de6bcc2a78243fc9c54d3ef5ac14da69
   > cat 1
   1
   > git cat-file -p a8994dc188ebbbc9e8a885470651a7fbb9127528
   1a
   > git cat-file -p 7ed6ff82de6bcc2a78243fc9c54d3ef5ac14da69
   5

In fact, both file 1 and file 5 have been 'lost'.  It's not obvious to 
me why this happens, except that it seems to be a feature of the need to 
merge.

This seems inconsistent. In one case, we have merged all 3 files. In one 
case, we have deleted incoming files. And in one case, we have 'lost' 
files that were already in the repository.

In one way, this is a slightly obscure edge case - merging into a new 
repository and then adding but not committing the files.  But the people 
most likely to do this are new git users - the ones who have to work 
hardest to recover the deleted/lost files.

     Regards, Ben