From: Thomas Rast <trast@student.ethz.ch>
To: jemmyw <jeremy@boost.co.nz>
Cc: git@vger.kernel.org
Subject: Re: retrospective move
Date: Wed, 4 Feb 2009 10:17:45 +0100 [thread overview]
Message-ID: <200902041017.47564.trast@student.ethz.ch> (raw)
In-Reply-To: <21826423.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 2439 bytes --]
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. Some ideas for
possible solutions:
* If your cp&rm commits are strictly local, you could squash them into
a single commit. See man git-rebase(1), especially the -i flag.
That way, the merge logic will recognise it as a rename.
* You can use an extra line of history that has a "real" one-step mv.
Suppose you currently have
*---*---*---*---* upstream
\
\
+--C--o--R--o--o local
where C is the copy and R is the removal. Then you can introduce an
extra "gateway" branch that does just the move:
*---*---*---*---* upstream
|\
| \
| +--M gateway
|
\
\
+--C--o--R--o--o local
Now merge gateway to local (i.e. git checkout local && git merge
gateway), and resolve all resulting conflicts. I think you can
actually use '-s ours' in that merge, but be sure to check the
results.
*---*---*---*---* upstream
|\
| \
| +--M gateway
| \
\ +----------+
\ \
+--C--o--R--o--o--1 local
Finally, you can use the gateway branch to "do the rename" on all
incoming new changes, by first merging upstream to gateway and later
again gateway to local, like so:
*---*---*---*---*. upstream
|\ \
| \ \
| +--M-------------2 gateway
| \ \
\ +----------+ \
\ \ \
+--C--o--R--o--o--1--3 local
It won't be very pretty history, but it should only give (rename
related) merge conflicts at M.
HTH :-)
--
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 9:19 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 [this message]
2009-02-04 10:31 ` Santi Béjar
2009-02-04 12:33 ` Thomas Rast
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=200902041017.47564.trast@student.ethz.ch \
--to=trast@student.ethz.ch \
--cc=git@vger.kernel.org \
--cc=jeremy@boost.co.nz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).