On 2006-10-23 12:53:44 -0400, Sean wrote:
> On Mon, 23 Oct 2006 17:47:06 +0100
> "Catalin Marinas" <catalin.marinas@xxxxxxxxx> wrote:
>
> > On 22/10/06, Karl Hasselström <kha@xxxxxxxxxxx> 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@xxxxxxxxxxx
www.treskal.com/kalle
-
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