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

Michael J Gruber· May 8, 2008, 14:41 UTC · lore

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

Shawn O. Pearce· May 8, 2008, 23:30 UTC · re: Michael J Gruber · lore

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

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

...

Show 8 quoted lines

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