From: "Shawn O. Pearce" <spearce@spearce.org>
To: Michael J Gruber <michaeljgruber+gmane@fastmail.fm>
Cc: git@vger.kernel.org
Subject: Re: gitk and git-gui with --git-dir and GIT_DIR
Date: Thu, 8 May 2008 19:30:54 -0400 [thread overview]
Message-ID: <20080508233054.GY29038@spearce.org> (raw)
In-Reply-To: <fvv3e4$i00$1@ger.gmane.org>
Michael J Gruber <michaeljgruber+gmane@fastmail.fm> wrote:
> I want to track a tree where I should not store a ".git" dir. (You may
> as well assume I don't have direct write access.) So, the ".git" dir is
> somewhere else in the filesystem, actually named something like "repo.git".
...
> git-gui::
> For non-bare repos it expects git-dirs of the form "path/.git" and bails
> out otherwise. Even when I rename my git dir to such a path things do
> not work: all tracked files are reported missing. This happens even when
> I call git-gui from the actual work tree, i.e. when git diff would work!
> It seems as if git-gui is CDing to "path" when git-dir is "path/.git",
> no matter what $PWD, core.worktree or GIT_WORK_TREE say. I don't see why
> this should be desired behaviour.
Oops.
git-gui assumes the working directory is at $GIT_DIR/.. because
earlier versions of git-gui created these "shortcut" things on
Windows that were actually just MS-DOS batch scripts to execute
git-gui in a specific directory. It did that by basically doing
this:
set GIT_DIR=/path/to/tree/.git
git-gui
and when a user double-clicked the file in Windows Explorer the
directory we wanted to move to was taken from $GIT_DIR/.. and
that was that.
Another reason we had this oddity of the work tree being the parent
of the repository was due to a setting of GIT_DIR environment
variable in Tcl/Tk not carring down into a git Cygwin binary
on Windows. It may just have been a bug in the Tcl/Tk or in the
Cygwin library at one point, I'm not sure, but I don't think we
are seeing it anymore.
Now apparently that poorly implemented feature is killing us in
this other case where we want to run with a GIT_DIR in one place
and a worktree in another.
There's actually a bunch of code in git-gui.sh to enforce this
stupid rule. Maybe we can just delete it. Hmm, no. In the
current Windows shortcut code (which actually creates a proper
Windows shortcut file with an icon) we assume the directory we
want to start in is $GIT_DIR/.. again. *sigh*
So its fixable, but its some level of effort to correct these
bad assumptions and/or stupid rules.
--
Shawn.
prev parent reply other threads:[~2008-05-08 23:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-08 14:41 gitk and git-gui with --git-dir and GIT_DIR Michael J Gruber
2008-05-08 23:30 ` Shawn O. Pearce [this message]
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=20080508233054.GY29038@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=michaeljgruber+gmane@fastmail.fm \
/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).