git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Marcel M. Cary" <marcel@oak.homeunix.org>
To: Jakub Narebski <jnareb@gmail.com>
Cc: gitster@pobox.com, git@vger.kernel.org
Subject: Re: [PATCH] rev-parse: Fix shell scripts whose cwd is a symlink into a git work-dir
Date: Mon, 24 Nov 2008 21:17:24 -0800	[thread overview]
Message-ID: <492B8A64.7070309@oak.homeunix.org> (raw)
In-Reply-To: <m31vx3l94x.fsf@localhost.localdomain>

> But that is contrary to the _name_ of option. It is --show-cdup, as
> in "show cd up". And I think your change will break a few scripts.
> 
> I think you should use "git rev-parse --work-tree" for full path
> to working directory:
> 
>     --show-cdup
>         When the command is invoked from a subdirectory, show the path
>         of the top-level directory relative to the current directory
>         (typically a sequence of "../", or an empty string).

Jakub,

Yes, I agree, there is a risk in breaking scripts that rely on the "../"
format.  That's the "substantial change" I was alluding.  Here's how I
arrived at that choice.  I considered these fixes:

(a) add some shell code to cd_to_toplevel to find the canonical pwd and
    interpret --show-cdup output from there

(b) make a new option (--work-tree would be a good name) to print the
    canonical work tree path, and leave --show-cdup as it is.  Then
    change cd_to_toplevel and/or git pull to use the new option

(c) change --show-cdup to print the canonical work tree path, even
    though it's not entirely consistent with the name of the option

The main reason I avoided (a), even though that "cd" is what violated my
expecations, is because I didn't want to have to re-implement code to
check whether each path component is a symlink.  (Now I see that "cd
`/bin/pwd` might be a more concise fix.)

The reason I avoided (b) is because, to make all of git work for me, I
expected to have to change several calling scripts.  (Now that I look, I
see only three calls to --show-cdup in the git codebase to change.)
Even so, third-party scripts that I might want to use in the future
would not immediately be changed.

Option (c) keeps the change small and isolated and makes it effective
everywhere.  The documentation, while perhaps in need of update given my
patch, doesn't promise to always return zero or more "../".  Also,
there's a branch branch of the --show-cdup code (that I can't seem to
exercise) that the result of get_git_work_tree(), which might not be
zero or more "../".


Would you suggest pursuing option (a)?  I wonder whether there are
languages other than shell that might suffer from the same problem of
keeping an internal PWD variable of some sort, or perhaps there are
shell scripts out there that call --show-cdup directly instead of
calling cd_to_toplevel.

Do you think it would be less likely to break existing scripts if I
restrict the (c) behavior to when getenv("PWD") doesn't match the
starting getcwd()?  (I'm not sure yet whether that's a reliable way to
detect the symlink scenario, but it seems to work with bash.)

Marcel

  parent reply	other threads:[~2008-11-25  5:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-15 15:11 [RFC PATCH 0/2] fixing git pull from symlinked directory Marcel M. Cary
2008-11-15 15:11 ` [RFC PATCH 1/2] Add failing test for "git pull" in " Marcel M. Cary
2008-11-15 15:11   ` [RFC PATCH 2/2] Support shell scripts that run from symlinks into a git working dir Marcel M. Cary
2008-11-22 21:33 ` [PATCH] rev-parse: Fix shell scripts whose cwd is a symlink into a git work-dir Marcel M. Cary
2008-11-22 21:54   ` Jakub Narebski
2008-11-23  7:10     ` Andreas Ericsson
2008-11-25  5:54       ` Marcel M. Cary
2008-11-25  6:50         ` Andreas Ericsson
2008-11-25  5:17     ` Marcel M. Cary [this message]
2008-11-25  7:30   ` Johannes Sixt
2008-11-25 16:16     ` Marcel M. Cary
2008-11-25 16:30       ` Johannes Sixt
2008-11-25 18:17       ` Junio C Hamano
2008-12-03  5:27         ` [PATCH] git-sh-setup: Fix scripts whose PWD " Marcel M. Cary
2008-12-03  7:20           ` Junio C Hamano
2008-12-10 15:04             ` [PATCH v2] " Marcel M. Cary
2008-12-10 20:18               ` Junio C Hamano
2008-12-13 20:47                 ` [PATCH v3] " Marcel M. Cary
2008-12-14  3:54                   ` Junio C Hamano
2008-12-15 17:34                     ` Marcel M. Cary
2008-12-15 17:38                       ` [PATCH v3] <-- really v4 Marcel M. Cary
2009-02-07  3:24             ` [RFC PATCH] git-sh-setup: Use "cd" option, not /bin/pwd, for symlinked work tree Marcel M. Cary
2009-02-07 12:25               ` Johannes Schindelin
2009-02-08 18:11                 ` Marcel M. Cary
2009-02-08 20:56                   ` Johannes Schindelin
2009-02-11 14:44                     ` Marcel M. Cary
2009-02-11 18:16                       ` 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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=492B8A64.7070309@oak.homeunix.org \
    --to=marcel@oak.homeunix.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jnareb@gmail.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 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 NNTP newsgroup(s).