From: Petr Baudis <pasky@suse.cz>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: gitster@pobox.com, git@vger.kernel.org, yves.orton@booking.com
Subject: Re: [PATCH] git rev-parse: Fix --show-cdup inside symlinked directory
Date: Tue, 15 Jul 2008 17:40:36 +0200 [thread overview]
Message-ID: <20080715154036.GR10151@machine.or.cz> (raw)
In-Reply-To: <alpine.DEB.1.00.0807151614510.8950@racer>
Hi,
On Tue, Jul 15, 2008 at 04:19:30PM +0100, Johannes Schindelin wrote:
> On Tue, 15 Jul 2008, Petr Baudis wrote:
>
> > Consider the scenario when someone makes a symlink into a working tree
> > subdirectory at an unrelated place, then attempts to work inside the
> > symlinked directory. The scenario is a bit unwieldly, but most of
> > the Git will handle it fine - except git rev-parse --show-cdup. That
> > will output a sequence of ../ which will work wrong inside the symlink
> > using shell cd builtin.
>
> Short version: do not use symlinks in the working directory, if you do not
> want to track the _symlink_.
>
> Long version: there are a lot of problems with that, and --show-cdup is
> the least of the problems. A checkout, for example, is able to kill the
> symlink and check out a fresh copy of the subdirectory.
>
> AFAICT this is a concious decision: If you want to track a symlink, track
> a symlink, but if you want to track a subdirectory, you will have to track
> a subdirectory, and it cannot be a symlink.
no, no, this is for the scenario other way around: you have a normal
subdirectory in the working tree, and point a symlink _at_ it from
$somewhere_else. Then you try to work in $somewhere_else/symlink.
> > This patch changes --show-cdup to always show absolute workdir path
> > instead. I think this should hopefully cause no compatibility problems;
> > the testsuite is passing fine, at least.
>
> See the thread where I proposed a change like this, back with the infamous
> worktree desaster, and Junio NACKed; or the thread where Linus rightfully
> insists that git_dir should be relative if possible, for performance
> reasons.
I see, <7vk5sly3h9.fsf@assigned-by-dhcp.cox.net>. But noone was aware
of this possible user case. Performance reasons sound reasonable, though
I'm not really sure if for cdup in particular this ever matters.
P.S.: Either way, there is a possible workaround to tell git about the
working directory manually using git --work-tree=... that I missed to
mention on IRC, Yves.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
next prev parent reply other threads:[~2008-07-15 15:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-15 14:13 git-rev-parse --show-cdup returns a relative path instead of absolute (problem with git pull --rebase not finding the git dir) Yves Orton
2008-07-15 14:59 ` [PATCH] git rev-parse: Fix --show-cdup inside symlinked directory Petr Baudis
2008-07-15 15:19 ` Johannes Schindelin
2008-07-15 15:40 ` Petr Baudis [this message]
2008-07-15 16:41 ` Yves Orton
2008-07-15 16:58 ` Yves Orton
2008-07-15 19:08 ` Rogan Dawes
2008-07-15 20:26 ` Yves Orton
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=20080715154036.GR10151@machine.or.cz \
--to=pasky@suse.cz \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=yves.orton@booking.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.
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.