Re: Renaming files with git not all that bad?

[Tassilo Horn]

Stefan Kangas <stefan@marxist.se> writes:

Hi Stefan,

>>> Couldn't the same effect be achieved in a simpler manner by copying the
>>> original file N times in one commit and then stripping the copies and
>>> original down to what they should eventually become?  (AFAIK, git has no
>>> problem detecting literal copies.)
>>
>> Indeed, I tried this and it works for me, as long as the first commit
>> is only literal copies. Maybe Git’s ancestry detection through copies
>> was not as advanced in the unspecified times when Raymond invented
>> his technique.
>
> I'm having no luck with this.
>
> Could you describe the exact steps you took?

I've just tried:

  git checkout -b copy-test
  cp lisp/image-dired.el lisp/image-dired-1.el
  cp lisp/image-dired.el lisp/image-dired-2.el
  git add lisp/image-dired-*.el
  git commit -m "copied image-dired.el twice"

Thereafter,

  git log -- lisp/image-dired-1.el lisp/image-dired-2.el

show only my "copied image-dired.el twice" commit unless I also specify
--follow.

I've also tried the "multiple renames on different branches followed by
an octopus merge" strategy but the result looks identical.

Oh, no, not quite.  It's the same wrt. "git log" but the difference is
that with the copy strategy, "git blame" will show you as having touched
all lines during the copy (which is sensible somehow) whereas they keep
the original previous last authors with the renaming strategy.

One problem with the renaming strategy is that the original file is
inevitably renamed after the merge, or at least you have to have one
branch in the merge where it is modified in the hope to get a conflict
so that you can keep all renamed versions and the original.  However,
since you want to move all image-dired related files into their own
directory, that's no problem whatsoever.

Bye,
Tassilo