Re: [PATCH 6/9] vcs_info quilt: fix unapplied detection on sub-directory

[Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx>]

Marc Finet wrote:
> On Thu, Oct 09, 2014 at 06:03:44PM +0200, Frank Terbeck wrote:
[...]
>> I am unsure about what's going on precisely. Could you do this:
>> 
>>     functions -t vcs_info
>> 
>> And retry your test cases? That will produce long traces of what's going
>> on, and might give ideas as to what's amiss.
> You'll find the trace attached. By the way, how do you deactivate
> tracing ? functions -T vcs_info removes a lot of traces (the VCS_INFO*) but
> keeps traces from vcs_info().

Thanks. I'll take a look as soon as I can.

To disable tracing you'd do this:

    functions +t vcs_info

-T is a slightly different form of tracing. It's disabled via +T.

>> I think $QUILT_PATCHES needs to be set to the correct directory
>> including "patches/". Without, it only works, because the directory is
>> searched recursively.
>> 
>> I don't know why the patches are reported as applied and unapplied off
>> hand. :-/
>> 
>> The applied patches are read from .pc/applied-patches, the list of
>> unapplied patches is retrieved by calling "quilt unapplied".
> This is where the problem occurs, applied uses relative path, while
> unapplied lists absolute path, because QUILT_PATCHES is set to an
> absolute path. e.g.
>     ~/src/from-debian/gmrun-0.9.2# QUILT_PATCHES=$(pwd)/debian/patches quilt applied
>     /home/marc/src/from-debian/gmrun-0.9.2/debian/patches/10-escaping.patch
>     ...
>     /home/marc/src/from-debian/gmrun-0.9.2/debian/patches/80-selectoption.pat
>     ~/src/from-debian/gmrun-0.9.2# quilt applied
>     debian/patches/10-escaping.patch
>     debian/patches/20-includes.patch
>     debian/patches/30-fix-gcc-4.3-build.patch
>     debian/patches/40-history_string.patch
>     debian/patches/50-empty-history.patch
>     debian/patches/60-fix_gtkcompletionline.patch
>
> So applied and unapplied lists are considered differents. The
> .pc/applied-patches file contains only relative paths.

I see. That could be fixed, I guess. Either by making the unapplied list
absolute, or by trimming off the "repository's" root-directory from the
absolute paths before comparing.

>> > So I do not understand the role of quilt-patch-dir as for me it takes
>> > the role of QUILT_PATCHES except the missing '/patches'. Moreover changing
>> > to sub-directory in cases 1, 3 and 5 makes applied patch detection failing
>> > because:
>> 
>> The ‘quilt-patch-dir’ style *sets* QUILT_PATCHES if set. The system
>> also sets QUILT_PATCHES to an absolute path-name, which should make it
>> work in subdirectories as well.
> I do not see where the QUILT_PATCHES variable is set (I mean exported to
> the shell for further quilt commands using this 'detected' value). Maybe
> your hook sets it according to the documentation: "Note: you can use
> vcs_info to keep the value of $QUILT_PATCHES correct all the time via the
> post-quilt hook"

Quilt is only called directly once in vcs_info's quilt code, if I'm not
mistaken. And that's here:

[...]
zstyle -s "${context}" quiltcommand quiltcommand || quiltcommand='quilt'
unapplied=( ${(f)"$(QUILT_PATCHES=$patches $quiltcommand --quiltrc /dev/null unapplied 2> /dev/null)"} )
[...]

I don't have any hooks for quilt behaviour set anymore. But given, that
the hook is called like this:

VCS_INFO_hook 'post-quilt' ${mode} ${patches} ${pc:-\\-nopc-}

You could likely set such a hook like this:

function +vi-quilt-patches() {
    if [[ -n $2 ]]; then
        typeset -gx "QUILT_PATCHES=$2"
    fi
}

zstyle ':vcs_info:*+post-quilt:*:*' hooks quilt-patches

To have $QUILT_PATCHES match vcs_info's idea of the patch directory.


Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925