From: Samir Benmendil <me@rmz.io>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: Git rebase --exec cannot run git commands affecting other repos
Date: Thu, 10 Jan 2019 21:48:42 +0000 [thread overview]
Message-ID: <20190110214842.dfisujzv7psx2jqe@hactar.rmz.io> (raw)
In-Reply-To: <xmqqlg3s2wu8.fsf@gitster-ct.c.googlers.com>
[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]
On Jan 10, 2019 at 10:26, Junio C Hamano wrote:
> Samir Benmendil <me@rmz.io> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-01-10 21:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-10 16:19 Git rebase --exec cannot run git commands affecting other repos Samir Benmendil
2019-01-10 18:26 ` Junio C Hamano
2019-01-10 21:48 ` Samir Benmendil [this message]
2019-01-11 16:04 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190110214842.dfisujzv7psx2jqe@hactar.rmz.io \
--to=me@rmz.io \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).