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