Re: [Quilt-dev] Quilt configuration associated with a source code tree/patch series

[Martin Quinson]

Hello there,

On Mon, May 05, 2014 at 11:03:28AM +0200, Jean Delvare wrote:
> Hi Martin, Frank,
> 
> Le Monday 05 May 2014 à 00:04 +0200, Martin Quinson a écrit :

> > It would be interesting to add the feature that you are speaking of.
> > The change could be as simple as the following (untested):
> > 
> > diff --git a/quilt/scripts/patchfns.in b/quilt/scripts/patchfns.in
> > index 5feee9f..d2113ec 100644
> > --- a/quilt/scripts/patchfns.in
> > +++ b/quilt/scripts/patchfns.in
> > @@ -1089,6 +1089,12 @@ fi
> >  
> >  DB="$QUILT_PC/applied-patches"
> >  
> > +# Source the repository-specific configuration
> > +if [ -e "$QUILT_PATCHES/quiltrc" ]
> > +then
> > +   source "$QUILT_PATCHES/quiltrc"
> 
> This raises a name space question. Although unlikely, "quiltrc" is a

The patch I just sent to check that the patch name does not contain
spaces and is not "series" makes it easy to deal with that namespace
conflict (that was part of the purpose).

> Also I think you want to move the code up in the patchfns file, right
> after the user's (or system) quiltrc file is read. Otherwise adding the
> default arguments for the current command will be done based on the
> wrong settings, which will defeat the point of project-specific
> settings.
> 
> > +fi
> > +
> >  if [ -z "$skip_version_check" ] && ! version_check
> >  then
> >     printf $"The working tree was created by an older version of quilt. 
> > Please run 'quilt upgrade'.\n" >&2
> > ------>8------
> > 
> > Note that this would override the user and global settings instead of
> > the contrary. Note also that for now, if both /etc/quilt.quiltrc and
> > ~/.quiltrc exist, only the ~/.quiltrc is used while the /etc one is
> > completely ignored (see at the beginning of bin/quilt.in)
> > 
> > If you guys like the idea of having a configuration file per
> > source tree, I'll cleanup my patch, document this new feature and
> > everything. 
> 
> I've been thinking about it too, but couldn't make up my mind one way or
> another. Thanks to both of you for bringing the topic up again, let's
> sort it out now.
> 
> If we try to add support for project-specific configuration files, we
> need to decide if the project-specific configuration file completely
> takes over the user or system configuration file (the same way the user
> settings currently do over system settings), or if the project-specific
> settings should be merged together with the user settings (we've never
> done that before.)
> 
> If the first case, it might be inconvenient as some settings really
> qualify as user preference and are not tied to a specific project. This
> is the case of EDITOR, QUILT_PAGER and QUILT_PATCHES_PREFIX for example.
> If we only read the project configuration file, the user will suddenly
> miss these settings. That would be very confusing. Unfortunately there
> is no automatic way to identify which settings are user-specific.
> 
> In the second case, we have to decide which configuration file will be
> the base and which configuration file will be the overlay. Letting all
> user settings take over project settings would pretty much void the
> point of having a project-specific configuration file in the first
> place, so obviously it would have to be the other way around. Which is
> what Martin proposed if I read the code correctly, so apparently we
> agree on that, which is good :)
> 
> Note that it then becomes each project's responsibility to come up with
> a sane quilt configuration file, and not overwrite settings which only
> affect the user and not the project. For example, it would be perfectly
> legitimate for a project to set QUILT_REFRESH_ARGS, but QUILT_DIFF_ARGS
> should be left to the user to decide.

I'm not sure that each solution makes a big difference. It's perfectly
possible to set some variables only if they are not set yet with
${param:-val} and such.

So, it's maybe better to let the user settings override everything at
the end. The only difficulty is that QUILT_PATCHES where the
configuration file will live can be changed by the user configuration,
somehow. That is why I decided to do it the way I did.

Not sure, yet.
Mt.

-- 
Each language has its purpose, however humble.  
Each language expresses the Yin and Yang of Software.
Each language has its place within the Tao.
But do not program in PHP if you can avoid it.
            -- The Tao of Programming

signature.asc
Description: Digital signature