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

[Peter Williams]

Peter Williams wrote:
> 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.

I withdraw this question and consign the concept to the "bad idea" tray. 
 If implemented this would cause havoc with "make". :-(

Peter
--
Peter Williams                                   address@hidden

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