Re: [Quilt-dev] [PATCH] Enhanced decoration for "series -v" command

[Peter Williams]

Andreas Gruenbacher wrote:
> On Wednesday 15 June 2005 04:45, Peter Williams wrote:
>
> > I've been looking at a method to tell whether just one file in a patch
> > needs refreshing (to use as the last check in files_may_have_changed)
> > and would like to use one of the commands (filterdiff) from patchutils
> >
> > <http://freshmeat.net/projects/patchutils/>
> >
> > to extract the patch for the file in question from the patch file so
> > that it can be used to modify a copy of the file for comparison with the
> > next version of the file above it in the series.  This would have the
> > consequence of making quilt dependent on patchutils.  Would this be
> > acceptable?
>
>
> No. filterdiff, interdiff etc. don't work for arbitrary patches; they use 
> heuristics that fail once in a while. I don't want quilt to fail like that, 
> particularly because it can do better.

Fair enough.

> The pop cpmmand already has code to 
> check whether a patch can be savely removed: it that creates a temporary copy 
> of the files in the patch, applies the patch, and compares the result. That's 
> not something you want to do when querying the patch status though.

It was where I got the idea. I.e. similar strategy but just do it one 
file at a time.  I was thinking that if doing this in 
files_may_have_changed may enable it to become files_have_changed and 
this would eliminate the need  for the extra checking in pop.  Whether 
this would actually be more efficient is not clear but I think it 
probably would be if per file patches can be extracted easily.

One way to do this without the need to use something like filterdiff to 
extract the patches for a particular file from the combined patch file 
would be to keep the patch files separated and cat them together along 
with the header when needed.

BTW It seemed to me when I read it that parse_patches was intended to do 
something similar to filterdiff but has been abandoned.  The only place 
that I could find it referenced was in the make file.

> The only 
> clean solution I can imagine is remembering the timestamps of all modified 
> files, but that would require a number of changes here and there.

An advantage of this approach is that it may allow better data about 
unapplied patches to be provided.  E.g. at the moment if you use "quilt 
files" for an unapplied patch you get diddly squat back which is a 
little on the not very helpful side.

Peter
--
Peter Williams                                   address@hidden

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce