{"thread":{"id":"13434","subject":"gitk and git-gui with --git-dir and GIT_DIR","startedAt":"2008-05-08T14:41:06Z","lastAt":"2008-05-08T23:30:54Z","messageCount":2,"participants":["Michael J Gruber","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"76375","messageId":"fvv3e4$i00$1@ger.gmane.org","threadId":"13434","inReplyTo":null,"subject":"gitk and git-gui with --git-dir and GIT_DIR","fromName":"Michael J Gruber","fromEmail":"michaeljgruber+gmane@fastmail.fm","sentAt":"2008-05-08T14:41:06Z","receivedAt":"2008-05-08T14:41:06Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"I want to track a tree where I should not store a \".git\" dir. (You may \nas well assume I don't have direct write access.) So, the \".git\" dir is \nsomewhere else in the filesystem, actually named something like \"repo.git\".\n\nI know how to make most of git happy with that structure (even diff). \nNotable exceptions are gitk and git-gui:\n\ngitk::\nIt requires GIT_DIR to be set and is happy. Only downside is that gitk \ndoes not fit inside the git-command scheme. Therefore, any aliasing I do \nfor git commands does not apply to gitk. Having gitk as git-view or such \nwould help.\n\ngit-gui::\nFor non-bare repos it expects git-dirs of the form \"path/.git\" and bails \nout otherwise. Even when I rename my git dir to such a path things do \nnot work: all tracked files are reported missing. This happens even when \nI call git-gui from the actual work tree, i.e. when git diff would work!\nIt seems as if git-gui is CDing to \"path\" when git-dir is \"path/.git\", \nno matter what $PWD, core.worktree or GIT_WORK_TREE say. I don't see why \nthis should be desired behaviour.\n\nMichael\n"},{"id":"76420","messageId":"20080508233054.GY29038@spearce.org","threadId":"13434","inReplyTo":"fvv3e4$i00$1@ger.gmane.org","subject":"Re: gitk and git-gui with --git-dir and GIT_DIR","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-05-08T23:30:54Z","receivedAt":"2008-05-08T23:30:54Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Michael J Gruber <michaeljgruber+gmane@fastmail.fm> wrote:\n> I want to track a tree where I should not store a \".git\" dir. (You may \n> as well assume I don't have direct write access.) So, the \".git\" dir is \n> somewhere else in the filesystem, actually named something like \"repo.git\".\n...\n> git-gui::\n> For non-bare repos it expects git-dirs of the form \"path/.git\" and bails \n> out otherwise. Even when I rename my git dir to such a path things do \n> not work: all tracked files are reported missing. This happens even when \n> I call git-gui from the actual work tree, i.e. when git diff would work!\n> It seems as if git-gui is CDing to \"path\" when git-dir is \"path/.git\", \n> no matter what $PWD, core.worktree or GIT_WORK_TREE say. I don't see why \n> this should be desired behaviour.\n\nOops.\n\ngit-gui assumes the working directory is at $GIT_DIR/.. because\nearlier versions of git-gui created these \"shortcut\" things on\nWindows that were actually just MS-DOS batch scripts to execute\ngit-gui in a specific directory.  It did that by basically doing\nthis:\n\n  set GIT_DIR=/path/to/tree/.git\n  git-gui\n\nand when a user double-clicked the file in Windows Explorer the\ndirectory we wanted to move to was taken from $GIT_DIR/.. and\nthat was that.\n\nAnother reason we had this oddity of the work tree being the parent\nof the repository was due to a setting of GIT_DIR environment\nvariable in Tcl/Tk not carring down into a git Cygwin binary\non Windows.  It may just have been a bug in the Tcl/Tk or in the\nCygwin library at one point, I'm not sure, but I don't think we\nare seeing it anymore.\n\nNow apparently that poorly implemented feature is killing us in\nthis other case where we want to run with a GIT_DIR in one place\nand a worktree in another.\n\nThere's actually a bunch of code in git-gui.sh to enforce this\nstupid rule.  Maybe we can just delete it.  Hmm, no.  In the\ncurrent Windows shortcut code (which actually creates a proper\nWindows shortcut file with an icon) we assume the directory we\nwant to start in is $GIT_DIR/.. again.  *sigh*\n\nSo its fixable, but its some level of effort to correct these\nbad assumptions and/or stupid rules.\n\n\n-- \nShawn.\n"}]}