All of lore.kernel.org
 help / color / mirror / Atom feed
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.

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