gnu-arch-users
[Top][All Lists]
Advanced

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

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


From: Miles Bader
Subject: Re: [Gnu-arch-users] Re: Linus Torvalds <address@hidden> Re: log-buf-len dynamic
Date: Sun, 5 Oct 2003 20:08:41 -0400
User-agent: Mutt/1.3.28i

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).

> > 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.

> 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.

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
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 :-)

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.

* Of course, the cleaner changeset resulting from an `extended patch' would
  likely be easier to review too, if moved directories around or something...

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]




reply via email to

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