Re: [Quilt-dev] misc. questions

[Jean Delvare]

Hi Andreas, John,

> > 4. I often add features to quilt because I need to use them then and
> > there, and then months later on forget what additional patches I have
> > installed on that box.  Timestamps and version numbers are useless;
> > the only way I can deduce what it can do is to know the list of
> > patches that were applied.  does this sound like a reasonable addition
> > to development versions of quilt?
> 
> I don't understand what you mean here.

I think John is suggesting something along these lines:

$ quilt --version
quilt 0.44
Additional patches:
osx-blabla-1
osx-blabla-2
cygwin-fix-foo
cygwin-fix-bar
$

I.e. the ability to store which additional patches the installed
version of quilt has.

I do not think such a feature would make much sense in upstream quilt,
as by definition upstream quilt doesn't have additional patches. As for
versions of quilt shipped by distributors, you can typically check the
applied patches from the source package. I'd suggest that John simply
keeps a document file up-to-date in /usr/local/share/quilt or a similar
location, where the stack of applied patches would be listed.

Or he may have a generated meta-patch, built automatically from all the other
patches, which would modify quilt's version command. This promises to be fun
to implement, although I'm not sure the effort is worth the gain compared to
a simple document file. Also note that modifying the output format of
"quilt --version" may break the compatibility with some tools (e.g. gquilt or
my not-yet-released quian).

> > 5. I also forget where I was up to with a workpit, and come back to it
> > wondering whether if I need to do a fork/refresh and diff the two
> > patches. I would like to add a status.in to tell me what the current
> > state of play is.  My thoughts were that it should display:

Try "quilt diff -z", it answers your question as far as I can see.

> > Patch: $(quilt top)
> > Status: (up-to-date|stale|missing)
> >
> > $(quilt header)
> >
> > The missing option would appear whenever there are changes against
> > .pc, but no saved patch.
> >
> > It may also be useful for the status command to list each file in the
> > patch with its own status.
> >
> > (btw, as you may have gathered, I have a brain like a sieve and a
> > tendency to leave half finished work lying around, so if anyone has
> > any other enhancement requests that assist the hypothetical user
> > coming back to an old workpit, I will happily implement it knowing
> > it's gonna save my arse one day)

This is a bad habit if you want my opinion, and no impovement to quilt
will be sufficient to compensate for it ;) "quilt diff -z" or "quilt
status" may tell you the pending changes to the top patch, but it won't
tell you what changes are left to do, why you were doing them, whether
these were experimental or meant to be pushed upstream, etc.

> I'm not sure which information such a status command should print.

I second Andreas' concerns here. I tend to prefer individual commands
like quilt has now over bundle commands like "quilt status" would be,
for the very reason that different users will probably want to see
different information in "quilt status". For example, I wouldn't want
to see the header there, as it might be quite large. OTOH I may enjoy
seeing the previous and next patches. Or even the first patch of the
series, which tends to be special in the environment *I* work in.

-- 
Jean Delvare