renames in StGIT

It doesn't seem like StGIT uses any of git's rename tracking stuff. Specifically, pushing patches doesn't seem to use rename-aware merging, and there is no way to tell diff to detect renames and copies.

Should this perhaps be an item in the TODO list?

On 22/10/06, Karl Hasselström <kha@treskal.com> wrote:

They are indeed not supported by StGIT. One of the reasons is that the push operation would probably take (much) longer (I haven't looked at the algorithm in detail but some comments in the git-diff documentation suggest that this is very expensive). Another reason is that I (used to) send patches to people not using GIT and therefore renames in the diff output were not welcomed.

Only if it doesn't drastically affect the performance.

On 2006-10-23 12:53:44 -0400, Sean wrote:

Yes, this is my opinion too, both for patch generation and pushing. Having it always on is a bad idea at least for patch generation for obvious reasons, and may be a bad idea for pushing for performance reasons, but I definitely think there should be a flag to enable it. There are situations when you know your upstream can read git patches, and being able to retry a failed push with rename detection instead of having to resolve the conflict manually could save lots of time, as Sean said. Besides, Linus is always bragging about how fast git merging is, and we all trust Linus, right? :-)

An optional flag is already available for the very handy "check if patch was merged upstream" feature, and it's definitely the right thing to do there. (Though I end up always using that flag even when I know my patches aren't in upstream, since the extra cost is barely noticeable.)

On 24/10/06, Karl Hasselström <kha@treskal.com> wrote:

Actually, it might not be a big performance impact. For diff generation in the export and mail commands, we should have a flag.

The push operation might not need a flag since it will only checks renames if all the other operations failed. A push with merge detection has the steps below (if one succeeds, push is finished):

1. check (exact) patch merges by reverse-applying the diff
2. apply the diff with git-diff | git-apply since this is faster than
a three-way merge
3. try a three-way merge between head, bottom and top

Step 3 above is handled per file by the stgit.gitmergeonefile.merge() function. This is the place where we should have the rename detection. Since, the majority of the patches don't rename files and, in most cases, the push finishes at step 2, it is probably safe to extend this function and the users won't notice a speed difference.

I'll add it to the TODO list.

On 2006-10-24 09:48:44 +0100, Catalin Marinas wrote:

Agreed.

Sounds good. I had a feeling it ought to be basically free in the majority of cases, so I'm glad to learn I'm right. :-)

On 24/10/06, Karl Hasselström <kha@treskal.com> wrote:

Might be even simpler for 'push' but I need to do more tests - instead of calling git-read-tree in git.merge(), just call git-merge-recursive which handles renames and it's fully tested. My simple test detected renames when pushing patches (both rename in base and rename in patch). I still have to do some tweaking and write proper tests (and probably make it less verbose).