From: Thomas Rast <trast@student.ethz.ch>
To: "Santi Béjar" <santi@agolina.net>
Cc: jemmyw <jeremy@boost.co.nz>, git@vger.kernel.org
Subject: Re: retrospective move
Date: Wed, 4 Feb 2009 13:33:38 +0100 [thread overview]
Message-ID: <200902041333.40776.trast@student.ethz.ch> (raw)
In-Reply-To: <adf1fd3d0902040231h2fb6f199oee143e36a7501a2a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]
Santi Béjar wrote:
> 2009/2/4 Thomas Rast <trast@student.ethz.ch>:
> > 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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2009-02-04 12:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-04 8:43 retrospective move jemmyw
2009-02-04 9:17 ` Thomas Rast
2009-02-04 10:31 ` Santi Béjar
2009-02-04 12:33 ` Thomas Rast [this message]
2009-02-04 12:57 ` Santi Béjar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200902041333.40776.trast@student.ethz.ch \
--to=trast@student.ethz.ch \
--cc=git@vger.kernel.org \
--cc=jeremy@boost.co.nz \
--cc=santi@agolina.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.