git rebase -i --exec and changing directory

git rebase -i --exec and changing directory

[Ondrej Mosnáček]

Hello,

I am trying to run a script to edit multiple commits using 'git rebase
-i --exec ...' and I ran into a strange behavior when I run 'cd'
inside the --exec command and subsequently run a git command. For
example, if the command is 'cd src && git status', then git status
reports as if all files in the repository are deleted.

Example command sequence to reproduce the problem:

    # Setup:
    touch a
    mkdir dir
    touch dir/x

    git init .
    git add --all
    git commit -m commit1
    git tag base
    touch b
    git add --all
    git commit -m commit2

    # Here we go:
    git rebase -i --exec 'cd dir && git status' base

    # Spawning a sub-shell doesn't help:
    git rebase -i --exec '(cd dir && git status)' base

Is this expected behavior or did I found a bug? Is there any
workaround, other than cd'ing to the toplevel directory every time I
want to run a git command when I am inside a subdirectory?

$ git --version
git version 2.17.0

Thanks,

Ondrej Mosnacek

Re: git rebase -i --exec and changing directory

[Ondrej Mosnáček]

Bump? Has anyone had time to look at this?

Thanks,

Ondrej Mosnacek

2018-05-19 18:38 GMT+02:00 Ondrej Mosnáček <omosnacek@gmail.com>:
> Hello,
>
> I am trying to run a script to edit multiple commits using 'git rebase
> -i --exec ...' and I ran into a strange behavior when I run 'cd'
> inside the --exec command and subsequently run a git command. For
> example, if the command is 'cd src && git status', then git status
> reports as if all files in the repository are deleted.
>
> Example command sequence to reproduce the problem:
>
>     # Setup:
>     touch a
>     mkdir dir
>     touch dir/x
>
>     git init .
>     git add --all
>     git commit -m commit1
>     git tag base
>     touch b
>     git add --all
>     git commit -m commit2
>
>     # Here we go:
>     git rebase -i --exec 'cd dir && git status' base
>
>     # Spawning a sub-shell doesn't help:
>     git rebase -i --exec '(cd dir && git status)' base
>
> Is this expected behavior or did I found a bug? Is there any
> workaround, other than cd'ing to the toplevel directory every time I
> want to run a git command when I am inside a subdirectory?
>
> $ git --version
> git version 2.17.0
>
> Thanks,
>
> Ondrej Mosnacek

Re: git rebase -i --exec and changing directory

[Philip Oakley]

You may need to give a bit more background of things that seem obvious to 
you.
So where is the src directory you are cd'ing to relative to the 
directory/repository you are creating?
What is [the name of] the directory you are currently in, etc. ?

Philip
--

From: "Ondrej Mosnáček" <omosnacek@gmail.com>
Bump? Has anyone had time to look at this?

2018-05-19 18:38 GMT+02:00 Ondrej Mosnáček <omosnacek@gmail.com>:
> Hello,
>
> I am trying to run a script to edit multiple commits using 'git rebase
> -i --exec ...' and I ran into a strange behavior when I run 'cd'
> inside the --exec command and subsequently run a git command. For
> example, if the command is 'cd src && git status', then git status
> reports as if all files in the repository are deleted.
>
> Example command sequence to reproduce the problem:
>
>     # Setup:
>     touch a
>     mkdir dir
>     touch dir/x
>
>     git init .
>     git add --all
>     git commit -m commit1
>     git tag base
>     touch b
>     git add --all
>     git commit -m commit2
>
>     # Here we go:
>     git rebase -i --exec 'cd dir && git status' base
>
>     # Spawning a sub-shell doesn't help:
>     git rebase -i --exec '(cd dir && git status)' base
>
> Is this expected behavior or did I found a bug? Is there any
> workaround, other than cd'ing to the toplevel directory every time I
> want to run a git command when I am inside a subdirectory?
>
> $ git --version
> git version 2.17.0
>
> Thanks,
>
> Ondrej Mosnacek

Re: git rebase -i --exec and changing directory

[Ondrej Mosnáček]

Hi Philip,

2018-05-27 14:28 GMT+02:00 Philip Oakley <philipoakley@iee.org>:
> You may need to give a bit more background of things that seem obvious to
> you.
> So where is the src directory you are cd'ing to relative to the
> directory/repository you are creating?

It is located in the top-level directory of the working tree (in the
same directory that .git is in).

From git-rebase(1):

    The "exec" command launches the command in a shell (the one
    specified in $SHELL, or the default shell if $SHELL is not set), so
    you can use shell features (like "cd", ">", ";" ...). The command is
    run from the root of the working tree.

So I need to run 'cd src' if I want to run a command in there
(regardless of the working directory of the git rebase command
itself).

> What is [the name of] the directory you are currently in, etc. ?

I don't think that is relevant here. FWIW, when verifying the problem
I ran the reproducer from my original message in a directory whose
path did not contain any spaces or special characters.

Did you try to run the reproducing commands I posted? Did you get a
different result? You should see the following in the output of 'cd
dir && git status':

[...]
Changes not staged for commit:
 (use "git add/rm <file>..." to update what will be committed)
 (use "git checkout -- <file>..." to discard changes in working directory)

       deleted:    a
       deleted:    b
       deleted:    dir/x
       deleted:    reproduce.sh

Untracked files:
 (use "git add <file>..." to include in what will be committed)

       x
[...]

When I drop the 'cd dir && ' from before 'git status', the output is
as expected:

You are currently editing a commit while rebasing branch 'master' on '19765db'.
 (use "git commit --amend" to amend the current commit)
 (use "git rebase --continue" once you are satisfied with your changes)

nothing to commit, working tree clean

>
> Philip
> --
>
> From: "Ondrej Mosnáček" <omosnacek@gmail.com>
> Bump? Has anyone had time to look at this?
>
> 2018-05-19 18:38 GMT+02:00 Ondrej Mosnáček <omosnacek@gmail.com>:
>>
>> Hello,
>>
>> I am trying to run a script to edit multiple commits using 'git rebase
>> -i --exec ...' and I ran into a strange behavior when I run 'cd'
>> inside the --exec command and subsequently run a git command. For
>> example, if the command is 'cd src && git status', then git status
>> reports as if all files in the repository are deleted.
>>
>> Example command sequence to reproduce the problem:
>>
>>     # Setup:
>>     touch a
>>     mkdir dir
>>     touch dir/x
>>
>>     git init .
>>     git add --all
>>     git commit -m commit1
>>     git tag base
>>     touch b
>>     git add --all
>>     git commit -m commit2
>>
>>     # Here we go:
>>     git rebase -i --exec 'cd dir && git status' base
>>
>>     # Spawning a sub-shell doesn't help:
>>     git rebase -i --exec '(cd dir && git status)' base
>>
>> Is this expected behavior or did I found a bug? Is there any
>> workaround, other than cd'ing to the toplevel directory every time I
>> want to run a git command when I am inside a subdirectory?
>>
>> $ git --version
>> git version 2.17.0
>>
>> Thanks,
>>
>> Ondrej Mosnacek
>
>

Re: git rebase -i --exec and changing directory

[Phillip Wood]

Hi Ondrej

On 27/05/18 13:53, Ondrej Mosnáček wrote:
> 
> Hi Philip,
> 
> 2018-05-27 14:28 GMT+02:00 Philip Oakley <philipoakley@iee.org>:
>> You may need to give a bit more background of things that seem obvious to
>> you.
>> So where is the src directory you are cd'ing to relative to the
>> directory/repository you are creating?
> 
> It is located in the top-level directory of the working tree (in the
> same directory that .git is in).
> 
>  From git-rebase(1):
> 
>      The "exec" command launches the command in a shell (the one
>      specified in $SHELL, or the default shell if $SHELL is not set), so
>      you can use shell features (like "cd", ">", ";" ...). The command is
>      run from the root of the working tree.
> 
> So I need to run 'cd src' if I want to run a command in there
> (regardless of the working directory of the git rebase command
> itself).
> 
>> What is [the name of] the directory you are currently in, etc. ?
> 
> I don't think that is relevant here. FWIW, when verifying the problem
> I ran the reproducer from my original message in a directory whose
> path did not contain any spaces or special characters.
> 
> Did you try to run the reproducing commands I posted? Did you get a
> different result? You should see the following in the output of 'cd
> dir && git status':

I tried your recipe and got the same result as you. However I think it 
could be a problem with 'git status' rather than 'git rebase --exec'. If 
I run your recipe in /tmp/a and do

cd dir
GIT_DIR=/tmp/a/.git git status

I get the same result as when running 'git status' from 'git rebase 
--exec' So I think the problem might have something to do with GIT_DIR 
being set in the environment when 'git status' is run

Best Wishes

Phillip

> 
> [...]
> Changes not staged for commit:
>   (use "git add/rm <file>..." to update what will be committed)
>   (use "git checkout -- <file>..." to discard changes in working directory)
> 
>         deleted:    a
>         deleted:    b
>         deleted:    dir/x
>         deleted:    reproduce.sh
> 
> Untracked files:
>   (use "git add <file>..." to include in what will be committed)
> 
>         x
> [...]
> 
> When I drop the 'cd dir && ' from before 'git status', the output is
> as expected:
> 
> You are currently editing a commit while rebasing branch 'master' on '19765db'.
>   (use "git commit --amend" to amend the current commit)
>   (use "git rebase --continue" once you are satisfied with your changes)
> 
> nothing to commit, working tree clean
> 
>>
>> Philip
>> --
>>
>> From: "Ondrej Mosnáček" <omosnacek@gmail.com>
>> Bump? Has anyone had time to look at this?
>>
>> 2018-05-19 18:38 GMT+02:00 Ondrej Mosnáček <omosnacek@gmail.com>:
>>>
>>> Hello,
>>>
>>> I am trying to run a script to edit multiple commits using 'git rebase
>>> -i --exec ...' and I ran into a strange behavior when I run 'cd'
>>> inside the --exec command and subsequently run a git command. For
>>> example, if the command is 'cd src && git status', then git status
>>> reports as if all files in the repository are deleted.
>>>
>>> Example command sequence to reproduce the problem:
>>>
>>>      # Setup:
>>>      touch a
>>>      mkdir dir
>>>      touch dir/x
>>>
>>>      git init .
>>>      git add --all
>>>      git commit -m commit1
>>>      git tag base
>>>      touch b
>>>      git add --all
>>>      git commit -m commit2
>>>
>>>      # Here we go:
>>>      git rebase -i --exec 'cd dir && git status' base
>>>
>>>      # Spawning a sub-shell doesn't help:
>>>      git rebase -i --exec '(cd dir && git status)' base
>>>
>>> Is this expected behavior or did I found a bug? Is there any
>>> workaround, other than cd'ing to the toplevel directory every time I
>>> want to run a git command when I am inside a subdirectory?
>>>
>>> $ git --version
>>> git version 2.17.0
>>>
>>> Thanks,
>>>
>>> Ondrej Mosnacek
>>
>>

Re: git rebase -i --exec and changing directory

[Philip Oakley]

Hi Ondrej, Phillip,

From: "Phillip Wood" <phillip.wood@talktalk.net>
> Hi Ondrej
>
> On 27/05/18 13:53, Ondrej Mosnáček wrote:
>>
>> Hi Philip,
>>
>> 2018-05-27 14:28 GMT+02:00 Philip Oakley <philipoakley@iee.org>:
>>> You may need to give a bit more background of things that seem obvious 
>>> to
>>> you.
>>> So where is the src directory you are cd'ing to relative to the
>>> directory/repository you are creating?
>>
>> It is located in the top-level directory of the working tree (in the
>> same directory that .git is in).
>>
>>  From git-rebase(1):
>>
>>      The "exec" command launches the command in a shell (the one
>>      specified in $SHELL, or the default shell if $SHELL is not set), so
>>      you can use shell features (like "cd", ">", ";" ...). The command is
>>      run from the root of the working tree.
>>
>> So I need to run 'cd src' if I want to run a command in there
>> (regardless of the working directory of the git rebase command
>> itself).
>>
>>> What is [the name of] the directory you are currently in, etc. ?
>>
>> I don't think that is relevant here. FWIW, when verifying the problem
>> I ran the reproducer from my original message in a directory whose
>> path did not contain any spaces or special characters.
>>
>> Did you try to run the reproducing commands I posted? Did you get a
>> different result? You should see the following in the output of 'cd
>> dir && git status':

At the time, I hadn't run the command. I was more interested in 
understanding the problem setup, as understanding often brings 
enlightenment.

I was jsut starting to do my own setup and swaw Phillip had responsed which 
prompted me to think it could be that there was no tty attached to the exec, 
so output wasn't being seen (or something like that).

>
> I tried your recipe and got the same result as you. However I think it 
> could be a problem with 'git status' rather than 'git rebase --exec'. If I 
> run your recipe in /tmp/a and do
>
> cd dir
> GIT_DIR=/tmp/a/.git git status
>
> I get the same result as when running 'git status' from 'git 
> rebase --exec' So I think the problem might have something to do with 
> GIT_DIR being set in the environment when 'git status' is run
>

I too got the same same results.
I also tried duplicating the exec line and placing it before the pick line, 
just to check it wasn't an issue about termination. Same result.

> Best Wishes
>
> Phillip
>
>>
>> [...]
>> Changes not staged for commit:
>>   (use "git add/rm <file>..." to update what will be committed)
>>   (use "git checkout -- <file>..." to discard changes in working 
>> directory)
>>
>>         deleted:    a
>>         deleted:    b
>>         deleted:    dir/x
>>         deleted:    reproduce.sh
>>
>> Untracked files:
>>   (use "git add <file>..." to include in what will be committed)
>>
>>         x
>> [...]
>>
>> When I drop the 'cd dir && ' from before 'git status', the output is
>> as expected:
>>
>> You are currently editing a commit while rebasing branch 'master' on 
>> '19765db'.
>>   (use "git commit --amend" to amend the current commit)
>>   (use "git rebase --continue" once you are satisfied with your changes)
>>
>> nothing to commit, working tree clean

So I extended the command to be exec'd to `cd dir && ls && git status`, 
again with duplication of the exec, which then gives a bit more..

finally I extended the status to pipe it's output to a file, again 
duplicated.
--
Philip@PhilipOakley MINGW32 /usr/src/mosnacek (master)

$ git rebase -i --exec 'cd dir && ls && git status >stat.txt' base

Executing: cd dir && ls && git status >stat0.txt

x

Executing: cd dir && ls && git status >stat.txt

stat0.txt x

Successfully rebased and updated refs/heads/master.

--
the stat0, stat files can then be investigated.

Summary: status is, I think, being clever and dropping the verbiage when not 
directly attached to the terminal. (or it is being intelligent and adding a 
lot more status details just because it _is_ within the rebase..)

>>
>>>
>>> Philip
>>> --
>>>
>>> From: "Ondrej Mosnáček" <omosnacek@gmail.com>
>>> Bump? Has anyone had time to look at this?
>>>
>>> 2018-05-19 18:38 GMT+02:00 Ondrej Mosnáček <omosnacek@gmail.com>:
>>>>
>>>> Hello,
>>>>
>>>> I am trying to run a script to edit multiple commits using 'git rebase
>>>> -i --exec ...' and I ran into a strange behavior when I run 'cd'
>>>> inside the --exec command and subsequently run a git command. For
>>>> example, if the command is 'cd src && git status', then git status
>>>> reports as if all files in the repository are deleted.

What does that particular report look like? I see no special report of 
deletions, or additions.


>>>>
>>>> Example command sequence to reproduce the problem:
>>>>
>>>>      # Setup:
>>>>      touch a
>>>>      mkdir dir
>>>>      touch dir/x
>>>>
>>>>      git init .
>>>>      git add --all
>>>>      git commit -m commit1
>>>>      git tag base
>>>>      touch b
>>>>      git add --all
>>>>      git commit -m commit2
>>>>
>>>>      # Here we go:
>>>>      git rebase -i --exec 'cd dir && git status' base
>>>>
>>>>      # Spawning a sub-shell doesn't help:
>>>>      git rebase -i --exec '(cd dir && git status)' base
>>>>
>>>> Is this expected behavior or did I found a bug? Is there any
>>>> workaround, other than cd'ing to the toplevel directory every time I
>>>> want to run a git command when I am inside a subdirectory?

Normally the exec capability is used to run compilation tests and then 
explicitly report errors, rather than be another user interaction. Use 'e' 
edit for that.

>>>>
>>>> $ git --version
>>>> git version 2.17.0
>>>>
--
Philip 

Re: git rebase -i --exec and changing directory

[Philip Oakley]

Hi Ondrej, Phillip,

From: "Phillip Wood" <phillip.wood@talktalk.net>
> Hi Ondrej
>
> On 27/05/18 13:53, Ondrej Mosnáček wrote:
>>
>> Hi Philip,
>>
>> 2018-05-27 14:28 GMT+02:00 Philip Oakley <philipoakley@iee.org>:
>>> You may need to give a bit more background of things that seem obvious 
>>> to
>>> you.
>>> So where is the src directory you are cd'ing to relative to the
>>> directory/repository you are creating?
>>
>> It is located in the top-level directory of the working tree (in the
>> same directory that .git is in).
>>
>>  From git-rebase(1):
>>
>>      The "exec" command launches the command in a shell (the one
>>      specified in $SHELL, or the default shell if $SHELL is not set), so
>>      you can use shell features (like "cd", ">", ";" ...). The command is
>>      run from the root of the working tree.
>>
>> So I need to run 'cd src' if I want to run a command in there
>> (regardless of the working directory of the git rebase command
>> itself).
>>
>>> What is [the name of] the directory you are currently in, etc. ?
>>
>> I don't think that is relevant here. FWIW, when verifying the problem
>> I ran the reproducer from my original message in a directory whose
>> path did not contain any spaces or special characters.
>>
>> Did you try to run the reproducing commands I posted? Did you get a
>> different result? You should see the following in the output of 'cd
>> dir && git status':

At the time, I hadn't run the command. I was more interested in 
understanding the problem setup, as understanding often brings 
enlightenment.

I was jsut starting to do my own setup and swaw Phillip had responsed which 
prompted me to think it could be that there was no tty attached to the exec, 
so output wasn't being seen (or something like that).

>
> I tried your recipe and got the same result as you. However I think it 
> could be a problem with 'git status' rather than 'git rebase --exec'. If I 
> run your recipe in /tmp/a and do
>
> cd dir
> GIT_DIR=/tmp/a/.git git status
>
> I get the same result as when running 'git status' from 'git 
> rebase --exec' So I think the problem might have something to do with 
> GIT_DIR being set in the environment when 'git status' is run
>

I too got the same same results.
I also tried duplicating the exec line and placing it before the pick line, 
just to check it wasn't an issue about termination. Same result.

> Best Wishes
>
> Phillip
>
>>
>> [...]
>> Changes not staged for commit:
>>   (use "git add/rm <file>..." to update what will be committed)
>>   (use "git checkout -- <file>..." to discard changes in working 
>> directory)
>>
>>         deleted:    a
>>         deleted:    b
>>         deleted:    dir/x
>>         deleted:    reproduce.sh
>>
>> Untracked files:
>>   (use "git add <file>..." to include in what will be committed)
>>
>>         x
>> [...]
>>
>> When I drop the 'cd dir && ' from before 'git status', the output is
>> as expected:
>>
>> You are currently editing a commit while rebasing branch 'master' on 
>> '19765db'.
>>   (use "git commit --amend" to amend the current commit)
>>   (use "git rebase --continue" once you are satisfied with your changes)
>>
>> nothing to commit, working tree clean

So I extended the command to be exec'd to `cd dir && ls && git status`, 
again with duplication of the exec, which then gives a bit more..

finally I extended the status to pipe it's output to a file, again 
duplicated.
--
Philip@PhilipOakley MINGW32 /usr/src/mosnacek (master)

$ git rebase -i --exec 'cd dir && ls && git status >stat.txt' base

Executing: cd dir && ls && git status >stat0.txt

x

Executing: cd dir && ls && git status >stat.txt

stat0.txt x

Successfully rebased and updated refs/heads/master.

--
the stat0, stat files can then be investigated.

Summary: status is, I think, being clever and dropping the verbiage when not 
directly attached to the terminal. (or it is being intelligent and adding a 
lot more status details just because it _is_ within the rebase..)

>>
>>>
>>> Philip
>>> --
>>>
>>> From: "Ondrej Mosnáček" <omosnacek@gmail.com>
>>> Bump? Has anyone had time to look at this?
>>>
>>> 2018-05-19 18:38 GMT+02:00 Ondrej Mosnáček <omosnacek@gmail.com>:
>>>>
>>>> Hello,
>>>>
>>>> I am trying to run a script to edit multiple commits using 'git rebase
>>>> -i --exec ...' and I ran into a strange behavior when I run 'cd'
>>>> inside the --exec command and subsequently run a git command. For
>>>> example, if the command is 'cd src && git status', then git status
>>>> reports as if all files in the repository are deleted.

What does that particular report look like? I see no special report of 
deletions, or additions.


>>>>
>>>> Example command sequence to reproduce the problem:
>>>>
>>>>      # Setup:
>>>>      touch a
>>>>      mkdir dir
>>>>      touch dir/x
>>>>
>>>>      git init .
>>>>      git add --all
>>>>      git commit -m commit1
>>>>      git tag base
>>>>      touch b
>>>>      git add --all
>>>>      git commit -m commit2
>>>>
>>>>      # Here we go:
>>>>      git rebase -i --exec 'cd dir && git status' base
>>>>
>>>>      # Spawning a sub-shell doesn't help:
>>>>      git rebase -i --exec '(cd dir && git status)' base
>>>>
>>>> Is this expected behavior or did I found a bug? Is there any
>>>> workaround, other than cd'ing to the toplevel directory every time I
>>>> want to run a git command when I am inside a subdirectory?

Normally the exec capability is used to run compilation tests and then 
explicitly report errors, rather than be another user interaction. Use 'e' 
edit for that.

>>>>
>>>> $ git --version
>>>> git version 2.17.0
>>>>
--
Philip 

Re: git rebase -i --exec and changing directory

[Junio C Hamano]

Phillip Wood <phillip.wood@talktalk.net> writes:

> I tried your recipe and got the same result as you. However I think it
> could be a problem with 'git status' rather than 'git rebase
> --exec'. If I run your recipe in /tmp/a and do
>
> cd dir
> GIT_DIR=/tmp/a/.git git status
>
> I get the same result as when running 'git status' from 'git rebase
> --exec' So I think the problem might have something to do with GIT_DIR
> being set in the environment when 'git status' is run

Yup.  

When GIT_DIR environment variable appears without GIT_WORKING_TREE,
"git" assumes that you are starting it at the root level of the
working tree.  In your example, if there is README at the top-level
but dir/README is not there, "status" would report that you removed
it.  You can unset GIT_DIR in your --exec script if you know that
Git would find the right repository when run from your script.