Re: How to fork a file (git cp ?)

From: Stephen Bash <bash@genarts.com>
Date: May 4, 2011, 19:05 UTC
Message-ID: <14525153.18843.1304535945960.JavaMail.root@mail.hq.genarts.com>
In-Reply-To: <4DC19955.7040503@kdbg.org>

----- Original Message -----

Show 16 quoted lines

> From: "Johannes Sixt" <j6t@kdbg.org>
> Sent: Wednesday, May 4, 2011 2:22:13 PM
> Subject: Re: How to fork a file (git cp ?)
> 
> Am 04.05.2011 19:56, schrieb Mikhail T.:
> > I need to add a new thing to our project. The thing will be similar
> > to
> > what already exists. I'd like to "derive" the new files from the
> > existing ones -- without altering them and by preserving the
> > change-history.
> 
> You cannot. Git does not have such a thing as
> "copy-with-preserved-history".
> 
> You just cp the file and git add it. But you will not be able to
> follow a history of the file.

Log (and other commands) can search for copies while traversing history:

  -C[<n>]
  --find-copies[=<n>]
  Detect copies as well as renames. See also --find-copies-harder. If n is specified, it has the same meaning as for -M<n>.

  --find-copies-harder
  For performance reasons, by default, -C option finds copies only if the original file of the copy was modified in the same changeset. This flag makes the command inspect unmodified files as candidates for the source of copy. This is a very expensive operation for large projects, so use it with caution. Giving more than one -C option has the same effect.

But as I discovered a few weeks ago, the existing merge strategies don't understand copies (recursive can follow a rename, but if two files pass rename detection, I think the one with the higher similarity index wins).

Thanks, Stephen