renames in StGIT

renames in StGIT

[Karl Hasselström]

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?

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: renames in StGIT

[Catalin Marinas]

On 22/10/06, Karl Hasselström <kha@treskal.com> wrote:
> 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.

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.

> Should this perhaps be an item in the TODO list?

Only if it doesn't drastically affect the performance.

-- 
Catalin

Re: renames in StGIT

[Karl Hasselström]

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

> On Mon, 23 Oct 2006 17:47:06 +0100
> "Catalin Marinas" <catalin.marinas@gmail.com> wrote:
>
> > On 22/10/06, Karl Hasselström <kha@treskal.com> wrote:
> >
> > > Should this perhaps be an item in the TODO list?
> >
> > Only if it doesn't drastically affect the performance.
>
> There are some situation where it would be really quite handy. The
> performance of the human having to hand resolve a failed push
> because of renames is often worse ;o) If it does become a
> performance problem, perhaps you could make it an optional parameter
> to "stg push".

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

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: renames in StGIT

[Catalin Marinas]

On 24/10/06, Karl Hasselström <kha@treskal.com> wrote:
> On 2006-10-23 12:53:44 -0400, Sean wrote:
> > There are some situation where it would be really quite handy. The
> > performance of the human having to hand resolve a failed push
> > because of renames is often worse ;o) If it does become a
> > performance problem, perhaps you could make it an optional parameter
> > to "stg push".
>
> 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.

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.

-- 
Catalin

Re: renames in StGIT

[Karl Hasselström]

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

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

Agreed.

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

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. :-)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: renames in StGIT

[Catalin Marinas]

On 24/10/06, Karl Hasselström <kha@treskal.com> wrote:
> On 2006-10-24 09:48:44 +0100, Catalin Marinas wrote:
> > 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.
>
> 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. :-)

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

-- 
Catalin