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

[Peter Williams]

Peter Williams wrote:
> Peter Williams wrote:
>
> > Peter Williams wrote:
> >
> > > Andreas Gruenbacher wrote:
> > >
> > > > On Friday 10 June 2005 08:21, Peter Williams wrote:
> > > >
> > > > > I am the author of a PyGTK GUI wrapper ( see
> > > > > <http://freshmeat.net/projects/gquilt/>) for quilt and it has been
> > > > > suggested to me that the panel containing the display of the patch
> > > > > series could be enhanced by having it display (for applied patches)
> > > > > whether each patch needs refreshing or not.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Looks nice. It seems the Push and Pop icons point in the wrong 
> > > > direction wrt. the series file (which has its top at the bottom)?
> > >
> > >
> > >
> > >
> > > You're the second person to say that and I don't understand as the 
> > > push arrow pushes up onto the bottom of the series and the pop arrow 
> > > pops down off the bottom of the series (at least in the latest 
> > > versions). Older versions used stock icons with unpredictable results 
> > > depending on how they were represented on each system so I've gone to 
> > > gquilt specific icons for later versions.  Can you confirm that 
> > > you've got version 0.4?
> > >
> > > > > The attached patch modifies quilt's "series -v" command to add this
> > > > > information to the output.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > files_may_have_changed may return false positives, so the resulting 
> > > > status information isn't worth much. Also it doesn't take care of 
> > > > shadowed files, so modifying a file in a patch further down in the 
> > > > series file will mark all previous patches that include that file as 
> > > > modified.
> > >
> > >
> > >
> > >
> > > Yes, I've discovered that :-( and will try to come up with a fix in a 
> > > day or two.  Basically, when a file is newer than the patch's 
> > > timestamp I'll look at applied patches above the patch until I find 
> > > one that shares the same file and make the comparison with the 
> > > "cached" file for that patch.
> > >
> > > As for other false positives I'm not sure that they're worth hunting 
> > > down as they should only be caused (I think) by rare occurrences such 
> > > as a change being made to a file and then removed without a refresh 
> > > being done.  I'm reluctant to go to all the trouble of doing diffs to 
> > > confirm that there is indeed a difference in the file (due to the 
> > > overhead) but will do that if necessary.
> >
> >
> >
> > Attached is a patch (on top of my previous patch) that addresses the 
> > false positives issue.  It seems to work well with one of my 
> > playgrounds that has quite extensive overlapping of patches.
> >
> > The reason that I've provided this as a patch on top of my previous 
> > patch is to make it easier to see the changes involved.
> >
> > I'm fairly sure that this change won't have any adverse effects for 
> > the use of files_may_have_changed() within the "pop" command but would 
> > value the opinion of others.
>
>
> Well it doesn't seem to have any bad effects on "pop" but, 
> unfortunately, "pop" has a bad effect on files_may_have_changed() 
> causing it to have false positives for patches that it had previously 
> considered not in need of a refresh.  Calling refresh on these patches 
> gets rid of the false positives but (it should be noted) report that the 
> patches are unchanged.
>
> Perusal of pop.in doesn't reveal any obvious easy way that this problem 
> could be fixed.  Does anybody have any ideas?

Can backup-files be (easily) made to set the modification times on the 
restored files to the same as the cached file being restored?  I think 
that this would solve the problem.

Peter
--
Peter Williams                                   address@hidden

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