Re: renames in StGIT

From: Karl Hasselström <kha@treskal.com>
Date: Oct 24, 2006, 08:17 UTC
Message-ID: <20061024081732.GA29265@diana.vm.bytemark.co.uk>
In-Reply-To: <20061023125344.f82426ad.seanlkml@sympatico.ca>

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

Show 14 quoted lines

> 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