Santi Béjar wrote:
> 2009/2/4 Thomas Rast <trast@xxxxxxxxxxxxxxx>:
> > jemmyw wrote:
> >>
> >> Hi. Awhile ago I copied some files in my local repo then commited. In another
> >> commit I deleted the original files, so essentially I did a mv that git
> >> doesn't know about. Now I'm trying to merge from another branch where
> >> changes have happened to the files in their original locations, and it's
> >> making the merge somewhat difficult. Is there a way to ease this?
> >
> > Git never "knows" about a move, it only detects them after the fact.
> > A corollary of this is that 'git mv a b' is more or less the same as
> > 'cp a b; git rm a; git add b'.
> >
> > Now since you have a copy followed by a removal in two separate
> > commits, the merge logic won't treat this as a rename.
>
> I don't think it holds. Git only sees the endpoints and the bases, it
> does not matter if the "move" was actually two commits. Maybe they
> have changed dramatically and git is not able to detect the rename (or
> the files are small). Another possible cause could be that you have a
> lot of renames (see config merge.renamelimit).
Hmm, you're right. I stand corrected.
Here's a sequence of commands that makes a test case:
git init
seq 1 10 > A
git add A
git commit -m initial
seq 11 15 >> A
git commit -m second A
seq 16 20 >> A
git commit -m third
git checkout -b side HEAD~2
cp A B
git add B
git commit -m copy
seq 3 10 > B # <--
git commit -m edit B
git rm A
git commit -m delete
Then running
git merge master
goes through cleanly, but changing the line indicated above to 'seq 5
10' makes it less similar, falling through the detection and causing a
conflict. The minimum required similarity for merges does not seem to
be configurable unfortunately.
--
Thomas Rast
trast@{inf,student}.ethz.ch
Attachment:
signature.asc
Description: This is a digitally signed message part.
