Re: retrospective move

From: Thomas Rast <trast@student.ethz.ch>
Date: Feb 4, 2009, 09:17 UTC
Message-ID: <200902041017.47564.trast@student.ethz.ch>
In-Reply-To: <21826423.post@talk.nabble.com>

jemmyw wrote:

Show 6 quoted lines

> 
> 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