Re: [Gnu-arch-users] Re: Linus Torvalds <address@hidden> Re: log-buf-len dynamic

[Andrea Arcangeli]

On Sun, Oct 05, 2003 at 08:08:41PM -0400, Miles Bader wrote:
> On Sun, Oct 05, 2003 at 08:46:31PM +0200, Andrea Arcangeli wrote:
> > > I think patches will be around for a long time; the central developers
> > > may stop using them, but such things don't go away quickly.
> > 
> > yes. Though the majority of patches don't involve renames.
> 
> It is nice to handle them correctly though -- and currently with BK, Linus
> _does_ handle rename patches correctly (I was very impressed when I first saw
> it).

are you sure the reason isn't that every kernel developer but myself and
Davide (and a very few others) are using bitkeeper? are you sure
bitkeeper can detect renames automatically even if submitting it through
a patch?

> > > It occurs to me that perhaps it should have a `--no-add' option for
> > > people like you that don't want to tag every file considered source.
> > 
> > that sounds a nice idea, thanks. Additionally I'd like to shortly review
> > the changes it's doing before running the tla commands.  To avoid the
> > `cp x.c x.c.org; rm x.c` to be mistaken for a legitimate rename w/o me
> > noticing about it.
> 
> Yes, a --dry-run option is a good idea too.

yes.

> > I remeber Linus asking Andre to send him a script, not a patch, to
> > create drivers/ide and to fill it moving files from drivers/block to
> > drivers/ide, somewhere in between 2.2 and 2.4. Exactly to avoid applying
> > absoltuely unreadable and very huge patches (huge because they duplicate
> > info). This just shows how the 'patch/diff' is unusable anyways for those
> > sort of changes, it's not that patch doesn't work w/o taglines, patch
> > never worked, and it can't work, for these sort of changes.
> 
> It's not actually that bad, I think.  Here's a sample session:
> 
>  (1)  ...receive giganto patch...

;) ;)

>  (2)  patch < giganto.patch
>  (3)  tla-update-ids
>  (4)  tla what-changed
> 
> If you see funny output after step (3) or step (4), you can either fix it
> directly, or just do `tla undo' and go back to an earlier step.

that's cool yes.

> The advantage of receiving arch-specific patchs is that step (3) is
> unnecessary, so you avoid any mistakes that script makes -- and of course the

you're overlooking that point 2 will reject huge and fixing it up
won't be very trivial, you won't see the diffs anymore in whats changed
at point 4, even if you delete the old file and the rejects.  I'd need
to search a tree where the giganto patch applies cleanly first.  and
it's an huge slowdown having to do this for every giganto patch, I
definitely prefer to be able to evaluate the patch by only pressing
pg-down in the mailer, when you've to audit lots of patches that's so
much more confortable.  reducing the transfer in the network is a bonus
too.

> weirder the changes, the more likely the script will fuck them up (for
> instance moving a complete hierarchy will result in a lot of individual file
> moves instead of a single directory move, which is probably what you want;
> maybe this case could be auto-detected, but it's not entirely trivial to do
> so).
> 
> But the bulk of the work is in reviewing the changes (for which the concise
> output of `what-changed' is very useful)*, deciding if something is funny, and
> fixing the patch if it is (of course in Linus's case, this involves just
> dropping the patch the floor, so not much work really :-)

;)

you're perfectly right that reviewing the coincise output of what-changed is the
bulk of the work, but I'll be stuck at point 2, and even if I'm not
stuck at point 2 I'd prefer to see whats-changed directly into the
mailer.

normally with the huge rejects case, what happens is that you end
applying the patch by hand (this is also useful to better audit the
patch since you see the larger context at the same time), so I'd need to
do point 4 before point 2 (to choose if to reject or not), since point 2
may be done by hand, and point 3 will never happen.

> Of course it _is_ useful to avoid step (3), and the possibility of the script
> screwing up, so an extended patch format is probably a good thing -- but I
> don't think the lack of such a format is a show-stopper, or even a major
> concern.

It's not a showstopper, but it would be really a nice thing to have.

I believe the only reason it's not so important is that there are very
few renames normally.

thanks for all the help!

Andrea - If you prefer relying on open source software, check these links:
            rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
            http://www.cobite.com/cvsps/