[PATCH] git-filter-branch.txt: mention absolute path for scripts in --tree-filter

[PATCH] git-filter-branch.txt: mention absolute path for scripts in --tree-filter

[Jari Aalto]

Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
 Documentation/git-filter-branch.txt |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 020028c..01bd0ad 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -91,6 +91,9 @@ OPTIONS
 	is then used as-is (new files are auto-added, disappeared files
 	are auto-removed - neither .gitignore files nor any other ignore
 	rules *HAVE ANY EFFECT*!).
++
+In case the <command> is a shell script, provide an absolute path.
+An example: --tree-filter 'sh /path/to/filter.sh'
 
 --index-filter <command>::
 	This is the filter for rewriting the index.  It is similar to the
-- 
1.7.0

Re: [PATCH] git-filter-branch.txt: mention absolute path for scripts in --tree-filter

[Johannes Sixt]

Jari Aalto schrieb:
> Signed-off-by: Jari Aalto <jari.aalto@cante.net>
> ---
>  Documentation/git-filter-branch.txt |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
> index 020028c..01bd0ad 100644
> --- a/Documentation/git-filter-branch.txt
> +++ b/Documentation/git-filter-branch.txt
> @@ -91,6 +91,9 @@ OPTIONS
>  	is then used as-is (new files are auto-added, disappeared files
>  	are auto-removed - neither .gitignore files nor any other ignore
>  	rules *HAVE ANY EFFECT*!).
> ++
> +In case the <command> is a shell script, provide an absolute path.
> +An example: --tree-filter 'sh /path/to/filter.sh'

Your choice of words is ambiguous: The --tree-filter is not the name of a
shell script, but rather the shell script itself; the example you gave is
just a shell script that happens to run only a shell on a file whose name
must be specified as an absolute path.

But doesn't the recommendation to use absolute paths apply not only to
--tree-filters, but

- to all filters;

- to all references to external files that the filters make.

I'm saying "recommendation" because git-filter-branch does not switch
directory ad lib., so theoretically, it would be possible to use relative
paths, even though the base of the relative paths would be non-obvious
because it is from inside a temporary directory named ".git-rewrite/t"
that is allocated next to .git.

-- Hannes

Re: [PATCH] git-filter-branch.txt: mention absolute path for scripts in --tree-filter

[Jari Aalto]

Johannes Sixt <j.sixt@viscovery.net> writes:

> Jari Aalto schrieb:
>
>> Signed-off-by: Jari Aalto <jari.aalto@cante.net>
>> ---
>>  Documentation/git-filter-branch.txt |    3 +++
>>  1 files changed, 3 insertions(+), 0 deletions(-)
>> 
>> diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
>> index 020028c..01bd0ad 100644
>> --- a/Documentation/git-filter-branch.txt
>> +++ b/Documentation/git-filter-branch.txt
>> @@ -91,6 +91,9 @@ OPTIONS
>>  	is then used as-is (new files are auto-added, disappeared files
>>  	are auto-removed - neither .gitignore files nor any other ignore
>>  	rules *HAVE ANY EFFECT*!).
>> ++
>> +In case the <command> is a shell script, provide an absolute path.
>> +An example: --tree-filter 'sh /path/to/filter.sh'
>
> Your choice of words is ambiguous: The --tree-filter is not the name of a
> shell script, but rather the shell script itself; the example you gave is
> just a shell script that happens to run only a shell on a file whose name
> must be specified as an absolute path.

Full context was:

    --tree-filter <command>::
            This is the filter for rewriting the tree and its contents.
            The argument is evaluated in shell with the working
            directory set to the root of the checked out tree.  The new tree
            is then used as-is (new files are auto-added, disappeared files
            are auto-removed - neither .gitignore files nor any other ignore
            rules *HAVE ANY EFFECT*!).
    +
    In case the <command> is a shell script, provide an absolute path.
    An example: --tree-filter 'sh /path/to/filter.sh'


>
> But doesn't the recommendation to use absolute paths apply not only to
> --tree-filters, but
>
> - to all filters;
>
> - to all references to external files that the filters make.

I don't know.

> I'm saying "recommendation" because git-filter-branch does not switch
> directory ad lib., so theoretically, it would be possible to use relative
> paths, even though the base of the relative paths would be non-obvious
> because it is from inside a temporary directory named ".git-rewrite/t"
> that is allocated next to .git.

The problem was that I was trying to use a sell script for athe
manipulation:

    cd <gir repo>
    git filter-branch  --tree-filter "sh ../filter.sh" HEAD

Which didn't. It needed absolute path:

    cd <gir repo>
    git filter-branch  --tree-filter "sh $(pwd)/filter.sh" HEAD

And that didn't work quit either. Script was run, but paths weren't no
longer relative to the "working dir" I was cd'd to:

    rm  file \
        dir/file \
        dir/file \
        ..

So, someone please explain how the paths should be expressed in shell
script and we'll improve the docs.

Jari

Re: [PATCH] git-filter-branch.txt: mention absolute path for scripts in --tree-filter

[Johannes Sixt]

Jari Aalto schrieb:
> J6t:
>> Your choice of words is ambiguous: The --tree-filter is not the name of a
>> shell script, but rather the shell script itself; the example you gave is
>> just a shell script that happens to run only a shell on a file whose name
>> must be specified as an absolute path.
> 
> Full context was:
> 
>     --tree-filter <command>::
>             This is the filter for rewriting the tree and its contents.
>             The argument is evaluated in shell with the working
>             directory set to the root of the checked out tree.  The new tree
>             is then used as-is (new files are auto-added, disappeared files
>             are auto-removed - neither .gitignore files nor any other ignore
>             rules *HAVE ANY EFFECT*!).
>     +
>     In case the <command> is a shell script, provide an absolute path.
>     An example: --tree-filter 'sh /path/to/filter.sh'

I am complaining that you say "In case the <command> is a shell
script...".  There are no other cases; <command> is always a shell script.

What you meant to say is: "If you have your filter written down in a
separate shell script, you must invoke it using an absolute path, for
example, --tree-filter '/path/to/filter.sh'".

>> But doesn't the recommendation to use absolute paths apply not only to
>> --tree-filters, but
>>
>> - to all filters;
>>
>> - to all references to external files that the filters make.
> 
> I don't know.

It was a rethoric question. The hint about paths to files outside the
working directory should go to the general description of filters.

>     cd <gir repo>
>     git filter-branch  --tree-filter "sh $(pwd)/filter.sh" HEAD
> 
> And that didn't work quit either. Script was run, but paths weren't no
> longer relative to the "working dir" I was cd'd to:
> 
>     rm  file \
>         dir/file \
>         dir/file \
>         ..

I don't understand what you are trying to say, and I don't understand why
it helped to run

  git filter-branch  --tree-filter "sh /the/git/repo/filter.sh" HEAD

when the above did not work - from filter-branch's POV there is simply no
difference between the two invocations.

-- Hannes

PS: Please keep Cc list.

Re: [PATCH] git-filter-branch.txt: mention absolute path for scripts in --tree-filter

[Junio C Hamano]

Johannes Sixt <j.sixt@viscovery.net> writes:

> Jari Aalto schrieb:
>> J6t:
>>> But doesn't the recommendation to use absolute paths apply not only to
>>> --tree-filters, but
>>> ...
>> I don't know.
>
> It was a rethoric question. The hint about paths to files outside the
> working directory should go to the general description of filters.

It is a good point.

Do people involved in filter-branch feel the implementation/interface is
stable enough these days to allow us to add this to the first paragraph of
the "Filters" description in the documentation?  It currently talks about
the environment variables exported for the use of filter programs, and "In
which directory will my filter run? --- I need to know it when I want to
reference filesystem entities using relative paths in my filter." would
fit well.