quilt-dev
[Top][All Lists]
Advanced

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

Re: [Quilt-dev] quilt new overrides SUBDIR


From: Andreas Gruenbacher
Subject: Re: [Quilt-dev] quilt new overrides SUBDIR
Date: Tue, 13 Jul 2004 01:30:25 +0200
User-agent: KMail/1.6.2

On Monday 12 July 2004 18:13, Joe Green wrote:
> Andreas Gruenbacher wrote:
> > Indeed. The idea behind this was as follows: If a patches sub-directory
> > exists further up the tree but not in the root of the working tree, the
> > new command will break out of the working tree and create patches further
> > up the tree. I repeatedly stumbled over this problem in the beginning.
> > (The import command has the same problem, but it currently has no
> > workaround.)
>
> How about something like the attached patch?  It assumes that if both
> the QUILT_PATCHES directory and the SERIES file have been found, the
> SUBDIR value can be trusted.  Otherwise it generates an error, and the
> user must specify "-f" to create a new root in the current directory.
> This seems like it should be reliable, unless maybe QUILT_SERIES is set
> to an absolute path.

The series file may also be in the QUILT_PATCHES directory, and this is often 
useful, too. So checking for both doesn't give a lot more confidence about 
the directory to choose.

I really wanted to avoid creating patches with `quilt new' above the current 
directory in the default case. How does an option sound that turns off this 
check, and accepts the next higher-level patches directory it finds? (I'm 
thinking about a long option, e.g., --check-parent-dirs that people could add 
to quiltrc when needed.)

> What do you think about making the users always specify "-f" for the
> first patch, to make sure they really want to create a new root in the
> current directory?  That could be implemented with small modifications
> to this patch.

Unfortunately this doesn't solve the problem.

I am quite happy that quilt does not require and special setup steps, and I 
would prefer to keep it that way.

Thanks,
-- 
Andreas Gruenbacher <address@hidden>
SUSE Labs, SUSE LINUX AG




reply via email to

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