gitk and git-gui with --git-dir and GIT_DIR

gitk and git-gui with --git-dir and GIT_DIR

[Michael J Gruber]

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

I know how to make most of git happy with that structure (even diff). 
Notable exceptions are gitk and git-gui:

gitk::
It requires GIT_DIR to be set and is happy. Only downside is that gitk 
does not fit inside the git-command scheme. Therefore, any aliasing I do 
for git commands does not apply to gitk. Having gitk as git-view or such 
would help.

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.

Michael

Re: gitk and git-gui with --git-dir and GIT_DIR

[Shawn O. Pearce]

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.