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

From: Piotr Krukowiecki <piotr.krukowiecki@gmail.com>
Date: May 5, 2011, 20:01 UTC
Message-ID: <BANLkTikE8aMh6RUDzrh=SuOxvKxuPShQhQ@mail.gmail.com>
In-Reply-To: <4DC2FB0A.2090100@aldan.algebra.com>

On Thu, May 5, 2011 at 9:31 PM, Mikhail T. <mi+thun@aldan.algebra.com> wrote:

Show 7 quoted lines

> On 04.05.2011 22:14, Junio C Hamano wrote:
>>
>> I think that is what exactly "blame -C -C" gives you.
>
> For that to be useful, one has to suspect, the file was derived by copying
> something else... Simple "git log" will not suggest that -- unless the
> commit message, that adds the new copy of a file points to it...

Maybe it should be the default (performance issues?)

Show 7 quoted lines

> On 05.05.2011 14:02, Piotr Krukowiecki wrote:
>>
>> Maybe Mikhail wanted to say that if there's a git-mv as a shortcut for
>>   "cp old new ; rm old; add new"
>
> git-mv preserves the old's change-history in new, so it is more than the
> above, is not it?

It's the same IMO: log with --follow will follow both "copies" and "renames".

BTW, I don't understand why 'status' shows renames but not copies:

$ cp f fcp && git add fcp && git status # Changes to be committed: # new file: fcp

$ mv f fmv && git add fmv && git rm f && git status # Changes to be committed: # renamed: f -> fmv

I would expect sth like "copied: f -> fcp". Not sure what about one file copied to multiple files, but I suppose renames have the same problem.

It should not be a problem performance-wise...

>> then there should be a git-cp as a shortcut for
>
> Yes...

-- 
Piotr Krukowiecki