Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

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

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"

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

Messages sorted by: Reverse Date, Date, Thread, Author