{"thread":{"id":"32345","subject":"Unexpected behaviour when trying to merge two new repositories.","startedAt":"2012-12-15T05:18:25Z","lastAt":"2012-12-15T05:18:25Z","messageCount":1,"participants":["Ben Aveling"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"204895","messageId":"50CC0821.7000103@optusnet.com.au","threadId":"32345","inReplyTo":null,"subject":"Unexpected behaviour when trying to merge two new repositories.","fromName":"Ben Aveling","fromEmail":"ben.aveling@optusnet.com.au","sentAt":"2012-12-15T05:18:25Z","receivedAt":"2012-12-15T05:18:25Z","isPatch":false,"sender":{"key":"ben.aveling@optusnet.com.au","avatar":null},"body":"\nHi,\n\nI have a directory of files that have been copied between different \nmachines, and then drifted apart.\n\nI was trying to merge the different versions into a single unified \nrepository.\n\nI succeeded, but I had to navigate though, and recover from, what seems \nto me to be counter-intuitive behaviour.\n\nLet me walk through a mock up of what I did.\n\nScenario 1. Merging two repositories.\n\nMock up first directory, and commit it.\n\n   > mkdir a\n   > git init a\n   Initialized empty Git repository in /tmp/a/.git/\n   > cd a\n   > echo 1 > 1\n   > echo 2 > 2\n   > git add .\n   > git commit -m \"add 1 and 2\"\n   [master (root-commit) 9a649ab] add 1 and 2\n    2 files changed, 2 insertions(+), 0 deletions(-)\n    create mode 100644 1\n    create mode 100644 2\n\nMock up second directory. Add files, but don't commit.\n\n   > mkdir b\n   > cd ../b\n   > git init\n   Initialized empty Git repository in /tmp/b/.git/\n   > echo 1 > 1\n   > echo 3 > 3\n   > git pull ../a\n   remote: Counting objects: 4, done.\n   remote: Compressing objects: 100% (2/2), done.\n   remote: Total 4 (delta 0), reused 0 (delta 0)\n   Unpacking objects: 100% (4/4), done.\n   From ../a\n    * branch            HEAD       -> FETCH_HEAD\n   error: Untracked working tree file '1' would be overwritten by merge.\n   > git add 1 3\n\nNow merge in the first directory.\n\n   > git pull ../a master\n   From ../a\n    * branch            master     -> FETCH_HEAD\n   Already up-to-date.\n   > git status\n   # On branch master\n   # Changes to be committed:\n   #   (use \"git reset HEAD <file>...\" to unstage)\n   #\n   #    deleted:    2\n   #    new file:   3\n   #\n\nThis surprised me. I wasn't expecting 2 to be deleted. And I wasn't \nexpecting to be told that it was \"Already up to date\".\n\nScenario 2. Merging two repositories with everything committed.\n\nMock up a third directory. Add files and this time, commit. Then merge \nfrom a.\n\n   > mkdir ../c\n   > cd ../c\n   > git init\n   Initialized empty Git repository in /tmp/c/.git/\n   > echo 1 > 1\n   > echo 4 > 4\n   > git add 1 4\n   > git commit -m \"add 1 and 4\"\n   [master (root-commit) b6081d9] add 1 and 4\n    2 files changed, 2 insertions(+), 0 deletions(-)\n    create mode 100644 1\n    create mode 100644 4\n   > git pull ../a master\n   warning: no common commits\n   remote: Counting objects: 4, done.\n   remote: Compressing objects: 100% (2/2), done.\n   remote: Total 4 (delta 0), reused 0 (delta 0)\n   Unpacking objects: 100% (4/4), done.\n   From ../a\n    * branch            master     -> FETCH_HEAD\n   Merge made by recursive.\n    2 |    1 +\n    1 files changed, 1 insertions(+), 0 deletions(-)\n    create mode 100644 2\n   > ll *\n   -rw-rw-r-- 1 ben ben 2 2012-12-15 15:02 1\n   -rw-rw-r-- 1 ben ben 2 2012-12-15 15:10 2\n   -rw-rw-r-- 1 ben ben 2 2012-12-15 15:03 4\n\nThis is what I was expecting the first time.\n\nIt seems that if there are no commits in the new repository, git doesn't \ndetect that there are no common commits.\n\nScenario 3. Merge with uncommitted changes.\n\nCreate another mock directory. Create some of the same files, but with \ndifferent contents. Again, add them but don't commit.\n\n   > mkdir ../d\n   > cd ../d\n   > git init\n   Initialized empty Git repository in /tmp/d/.git/\n   > echo 1a > 1\n   > echo 5 > 5\n   > git add 1 5\n   > git commit -m \"add 1 and 5\"\n   [master (root-commit) b6081d9] add 1 and 5\n    2 files changed, 2 insertions(+), 0 deletions(-)\n    create mode 100644 1\n    create mode 100644 5\n   > git pull ../a master\n   remote: Counting objects: 4, done.\n   remote: Compressing objects: 100% (2/2), done.\n   remote: Total 4 (delta 0), reused 0 (delta 0)\n   Unpacking objects: 100% (4/4), done.\n   From ../a\n    * branch            master     -> FETCH_HEAD\n   > git status\n   # On branch master\n   nothing to commit (working directory clean)\n   > ls -l\n   total 8\n   -rw-rw-r-- 1 ben ben 2 2012-12-15 15:31 1\n   -rw-rw-r-- 1 ben ben 2 2012-12-15 15:31 2\n\nThis too, surprised me.  This time, the incoming file was added where \nbefore it was deleted. And file 5 has vanished.\n\n   > git fsck\n   dangling blob a8994dc188ebbbc9e8a885470651a7fbb9127528\n   dangling blob 7ed6ff82de6bcc2a78243fc9c54d3ef5ac14da69\n   > cat 1\n   1\n   > git cat-file -p a8994dc188ebbbc9e8a885470651a7fbb9127528\n   1a\n   > git cat-file -p 7ed6ff82de6bcc2a78243fc9c54d3ef5ac14da69\n   5\n\nIn fact, both file 1 and file 5 have been 'lost'.  It's not obvious to \nme why this happens, except that it seems to be a feature of the need to \nmerge.\n\nThis seems inconsistent. In one case, we have merged all 3 files. In one \ncase, we have deleted incoming files. And in one case, we have 'lost' \nfiles that were already in the repository.\n\nIn one way, this is a slightly obscure edge case - merging into a new \nrepository and then adding but not committing the files.  But the people \nmost likely to do this are new git users - the ones who have to work \nhardest to recover the deleted/lost files.\n\n     Regards, Ben\n"}]}