git rebase -i --exec and changing directory

git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed

* git rebase -i --exec and changing directory
@ 2018-05-19 16:38 Ondrej Mosnáček
  2018-05-27 10:59 ` Ondrej Mosnáček
  0 siblings, 1 reply; 8+ messages in thread
From: Ondrej Mosnáček @ 2018-05-19 16:38 UTC (permalink / raw)
  To: git

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: git rebase -i --exec and changing directory
  2018-05-19 16:38 git rebase -i --exec and changing directory Ondrej Mosnáček
@ 2018-05-27 10:59 ` Ondrej Mosnáček
  2018-05-27 12:28   ` Philip Oakley
  0 siblings, 1 reply; 8+ messages in thread
From: Ondrej Mosnáček @ 2018-05-27 10:59 UTC (permalink / raw)
  To: git

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: git rebase -i --exec and changing directory
  2018-05-27 10:59 ` Ondrej Mosnáček
@ 2018-05-27 12:28   ` Philip Oakley
  2018-05-27 12:53     ` Ondrej Mosnáček
  0 siblings, 1 reply; 8+ messages in thread
From: Philip Oakley @ 2018-05-27 12:28 UTC (permalink / raw)
  To: Ondrej Mosnáček, git

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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: git rebase -i --exec and changing directory
  2018-05-27 12:28   ` Philip Oakley
@ 2018-05-27 12:53     ` Ondrej Mosnáček
  2018-05-27 16:07       ` Phillip Wood
  0 siblings, 1 reply; 8+ messages in thread
From: Ondrej Mosnáček @ 2018-05-27 12:53 UTC (permalink / raw)
  To: Philip Oakley; +Cc: git

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
>
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: git rebase -i --exec and changing directory
  2018-05-27 12:53     ` Ondrej Mosnáček
@ 2018-05-27 16:07       ` Phillip Wood
  2018-05-27 17:25         ` Philip Oakley
                           ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Phillip Wood @ 2018-05-27 16:07 UTC (permalink / raw)
  To: Ondrej Mosnáček, Philip Oakley; +Cc: git

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
>>
>>


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: git rebase -i --exec and changing directory
  2018-05-27 16:07       ` Phillip Wood
@ 2018-05-27 17:25         ` Philip Oakley
  2018-05-27 17:25         ` Philip Oakley
  2018-05-28  2:45         ` Junio C Hamano
  2 siblings, 0 replies; 8+ messages in thread
From: Philip Oakley @ 2018-05-27 17:25 UTC (permalink / raw)
  To: phillip.wood, Ondrej Mosnáček; +Cc: git

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 


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: git rebase -i --exec and changing directory
  2018-05-27 16:07       ` Phillip Wood
  2018-05-27 17:25         ` Philip Oakley
@ 2018-05-27 17:25         ` Philip Oakley
  2018-05-28  2:45         ` Junio C Hamano
  2 siblings, 0 replies; 8+ messages in thread
From: Philip Oakley @ 2018-05-27 17:25 UTC (permalink / raw)
  To: phillip.wood, Ondrej Mosnáček; +Cc: git

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 


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: git rebase -i --exec and changing directory
  2018-05-27 16:07       ` Phillip Wood
  2018-05-27 17:25         ` Philip Oakley
  2018-05-27 17:25         ` Philip Oakley
@ 2018-05-28  2:45         ` Junio C Hamano
  2 siblings, 0 replies; 8+ messages in thread
From: Junio C Hamano @ 2018-05-28  2:45 UTC (permalink / raw)
  To: Phillip Wood; +Cc: Ondrej Mosnáček, Philip Oakley, git

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2018-05-28  2:48 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-19 16:38 git rebase -i --exec and changing directory Ondrej Mosnáček
2018-05-27 10:59 ` Ondrej Mosnáček
2018-05-27 12:28   ` Philip Oakley
2018-05-27 12:53     ` Ondrej Mosnáček
2018-05-27 16:07       ` Phillip Wood
2018-05-27 17:25         ` Philip Oakley
2018-05-27 17:25         ` Philip Oakley
2018-05-28  2:45         ` Junio C Hamano

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).