Michael J Gruber <michaeljgruber+gmane@xxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
