On Jan 10, 2019 at 10:26, Junio C Hamano wrote:
Samir Benmendil <me@xxxxxx> writes:It is impossible to run git commands affecting a different repo from within a `git rebase --exec` because in that environment the `GIT_DIR` and `GIT_WORK_TREE` variables are set and inherited by any commands run as part of `git rebase --exec`.If the user wants to work in a different repository, the environments that tells Git about the original repository can be unset to do so, which is a very much deliberately designed behaviour, primarily to help those who run "git rebase" from a subdirectory of the project.
When run in a directory that does not have ".git" repository directory, Git tries to find such a directory in the parent directories to find the top of the working tree.
That should be the case as well for `git rebase`, is it not?Rummaging through release notes to find out when this was added, I found the following in `RelNotes/2.19.0.txt`.
* "git rebase" started exporting GIT_DIR environment variable and exposing it to hook scripts when part of it got rewritten in C. Instead of matching the old scripted Porcelains' behaviour, compensate by also exporting GIT_WORK_TREE environment as well to lessen the damage. This can harm existing hooks that want to operate on different repository, but the current behaviour is already broken for them anyway. (merge ab5e67d751 bc/sequencer-export-work-tree-as-well later to maint).To me it seems to be more of a regression introduced by porting rebase to C that was deemed to be acceptable at the time (only a few months ago).
I would argue that it is not.The behaviour is also inconsistent with running these --exec commands from the command line while doing an interactive rebase, i.e. when changing one of the lines to "edit" and being dropped into the terminal for the edit, these env variables are not set.
Attachment:
signature.asc
Description: PGP signature
