On 24/10/06, Karl Hasselström <kha@xxxxxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html