[Top][All Lists]
[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