From: "Tor Arne Vestbø" <tor.arne.vestbo@nokia.com>
To: ext Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, trast@student.ethz.ch
Subject: Re: [PATCH] require_work_tree: Look for top-level instead of is-inside-work-tree
Date: Fri, 30 Jul 2010 13:04:30 +0200 [thread overview]
Message-ID: <4C52B1BE.8020804@nokia.com> (raw)
In-Reply-To: <7v4ofjw6t6.fsf@alter.siamese.dyndns.org>
Hey, and thanks for your feedback Junio!
On 29.07.10 01.00, ext Junio C Hamano wrote:
> Tor Arne Vestbø <tor.arne.vestbo@nokia.com> writes:
>
> > The documentation describes require_work_tree as guarding against
> > bare repositories, and that's also the way it's used from porcelain
> > such as git-rebase. When implemented using --is-inside-work-tree
> > the samantics change, causing git-rebase to fail if run from outside
> > GIT_WORK_TREE, even if GIT_WORK_TREE is valid.
> >
> > Signed-off-by: Tor Arne Vestbø <tor.arne.vestbo@nokia.com>
> > ---
>
> The "requirement" is that we _have_ work tree somewhere that we can
> cd-to-toplevel to if we wanted to, not that we _are_ already in the work
> tree. I can buy that rationale.
Right. You put it much nicer than me :)
> However, I notice that "git bisect", "git mergetool" and "git submodule"
> do not seem to do cd_to_topleve immediately after require_work_tree. The
> last one has cd_to_toplevel in later parts of the codepath, presumably so
> that it can collect paths relative to the subdirectory in the work tree.
> I wonder if all of them actually need to be run from inside a work tree?
> Don't they need a separate "git rev-parse --is-inside-work-tree || die"
> check after require_work_tree (or perhaps cd_to_toplevel) if we apply this
> patch?
I think if we have a work tree somewhere, we can at least do "git
rev-parse --is-inside-work-tree || cd_to_toplevel" instead of dying,
unless there's some danger to that (the user running a command from
outside GIT_WORK_TREE but expecting GIT_WORK_TREE to not be touched).
For "git bisect" and "git submodule" running them in a sub-directory of
the work tree complains about needing to be run from the top-level, so I
assume we can do an unconditional cd_to_toplevel after the
require_work_tree?
For "git mergetool" we should probably do it conditionally only if the
user is not inside a work tree already, so that the behavior of running
the tool in a sub-directory is not changed.
Tor Arne
next prev parent reply other threads:[~2010-07-30 11:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-28 16:47 [PATCH] require_work_tree: Look for top-level instead of is-inside-work-tree Tor Arne Vestbø
2010-07-28 23:00 ` Junio C Hamano
2010-07-30 11:04 ` Tor Arne Vestbø [this message]
2010-08-02 14:37 ` Michael J Gruber
2010-08-02 17:46 ` Junio C Hamano
2010-08-03 7:57 ` Michael J Gruber
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C52B1BE.8020804@nokia.com \
--to=tor.arne.vestbo@nokia.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=trast@student.ethz.ch \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.