Hi Martin, Frank, Le Monday 05 May 2014 à 00:04 +0200, Martin Quinson a écrit : > On Mon, Mar 31, 2014 at 10:27:35AM -0400, Frank Bormann wrote: > > I am new to quilt and just finished to read through the documentation. > > > > I was wondering if quilt has any concept of accepting quiltrc configuration > > linked to a particular project/source code tree/patch series. > > > > I know that there is ~/.quiltrc which binds to a particular individual and > > /etc/quilt.quiltrc that binds to a particular system. I was wondering if > > there is a similar concept where configuration binds to a project/source > > tree/patch series, that I may be missing. Ideally in such way that any > > project configuration may be overridden by the system-wide and individual > > user config files. > > > > The idea is to track changes to a patch series in a version control system > > and implement branches by having QUILT_SERIES set to different series files > > for each individual branch.
If that's all you need, I don't think this requires support of project-specific configuration files. Just set QUILT_SERIES in the environment before calling quilt the first time, and it will remember the setting (since quilt version 0.50.) If you need to switch branches later, just pop all the patches and delete .pc/, and start over. That being said, I admit I'm not complete sure I fully understand what you are trying to achieve. If I am way off track, please give a more concrete example, with your current and desired work flows explained step-by-step. Regardless of your actual needs, project-specific configuration files may be useful to others, so we can still discuss and implement that. > As far as I know, the ability to configure quilt for a given > repository is actually *very* limited. Only the patch directory and > the series file (respectively equivalent to QUILT_PATCHES and > QUILT_SERIES) are saved in the .pc/ directory (in .pc/.quilt_patches > and .pc/.quilt_series). Correct. > Actually, I'm not sure I'd advise you to mess with these files > manually. I never temper with the content of .pc myself. As a general rule you are indeed not supposed to. > 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 legitimate name for a patch. It might be better to use something even less likely to collide, such as ".quiltrc" or "quilt.quiltrc". In all cases, it would be good to prevent a patch under than name from being created or imported. BTW I just noticed that we currently don't have such a protection for the series file, so "quilt new series" is accepted and from there you can joyfully corrupt or even delete your series file :( This should be fixed too. 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. -- Jean Delvare SUSE L3 Support _______________________________________________ Quilt-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/quilt-dev
