Hi Ondrej, Phillip,
From: "Phillip Wood" <phillip.wood@xxxxxxxxxxxx>
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@xxxxxxx>:
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@xxxxxxxxx>
Bump? Has anyone had time to look at this?
2018-05-19 18:38 GMT+02:00 Ondrej Mosnáček <omosnacek@xxxxxxxxx>:
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
