From: "Catalin Marinas" <catalin.marinas@gmail.com>
To: "Karl Hasselström" <kha@treskal.com>
Cc: Sean <seanlkml@sympatico.ca>, git@vger.kernel.org
Subject: Re: renames in StGIT
Date: Tue, 24 Oct 2006 09:48:44 +0100 [thread overview]
Message-ID: <b0943d9e0610240148s15d6ec5ch6114360a603fcd71@mail.gmail.com> (raw)
In-Reply-To: <20061024081732.GA29265@diana.vm.bytemark.co.uk>
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
next prev parent reply other threads:[~2006-10-24 8:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-22 1:39 renames in StGIT Karl Hasselström
2006-10-23 16:47 ` Catalin Marinas
[not found] ` <20061023125344.f82426ad.seanlkml@sympatico.ca>
2006-10-24 8:17 ` Karl Hasselström
2006-10-24 8:48 ` Catalin Marinas [this message]
2006-10-24 9:16 ` Karl Hasselström
2006-10-24 10:25 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b0943d9e0610240148s15d6ec5ch6114360a603fcd71@mail.gmail.com \
--to=catalin.marinas@gmail.com \
--cc=git@vger.kernel.org \
--cc=kha@treskal.com \
--cc=seanlkml@sympatico.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).