git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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 --]

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