Unexpected behaviour when trying to merge two new repositories.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]