[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] --forward mostly harmless

From: James Blackwell
Subject: Re: [Gnu-arch-users] --forward mostly harmless
Date: Mon, 13 Sep 2004 16:45:57 -0400

In lists.arch.users, you wrote:
> On Sun, Sep 12, 2004 at 07:56:37PM -0700, Tom Lord wrote:
>> Seconded.  A less buggy implementation *might* be useful but I support
>> with "remove this which never worked properly and then await
>> legitimate demand (with skepticism) before installing a corrected
>> version" rather than simply "fix".

Miles wrote:
> It might be worth checking the sources to see if that's actually what
> the command does.

Yeah. While the discussion was flying around, I decided to actually look
at patch.c. After spending about 1/2 an hour looking at it, I think the
code is just as confusing as the documentation. 

Does anybody happen to be friends of Larry Wall? He's patch's original
daddy, and surely he could give an authoritive answer without very much

> I've always been kinda nervous about this behavior (because I often
> use it to re-merge linux patches which have been only partially
> applied upstream), and so tend to watch it with a jaundiced eye, but
> so far it's never actually done anything bad.

So pulling it out would hurt you. Darnit. And for just a moment I held a
hope that there would be a clear, obvious answer.

> For me, duplicate suppression of some sort is absolutely necessary,
> but I usually use `star-merge --three-way' anyway...

I absolutely agree that its something that we "need". When it comes to
building a model that we can clearly explain to the users, silently
skipping changesets that are already present is the right way to go. 

But (and this is a big one), that completely hoses us up when it comes
to impure changesets. I'm increasingly becoming convinced that we should
change all the tools to automatically protect against impure changesets,
and then turn arround and add a global -I (for impure) flag.. but that
opens up a whole 'nother can of worms about detecting impure changesets
prior to commit....

James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400

reply via email to

[Prev in Thread] Current Thread [Next in Thread]