Junio C Hamano <junkio@xxxxxxx> wrote: > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > > If you are curious its been pushed to repo.or.cz: > > > > git://repo.or.cz/git-gui.git > > I think it is not a big deal for git-gui which is for active > developers and not primarily for archaeologists, but it does not > seem to like to be invoked inside a bare repository. Yes. git-gui does some bad things. On Mac OS X and Windows it lets you setup a "shortcut". This bastard thing is a batch file/script which basically sets the GIT_DIR environment variable, then starts git-gui. So it assumes that the GIT_DIR its getting is somehow connected to a working directory of sorts. I actually have plans to cleanup some of git-gui's internals so that its easier to specify what it can do, and cannot do, during startup, then configure the UI from that. For example, one should not be allowed to commit in a bare repository, or merge, but fetch and push are still OK. So is browsing, creating and deleting branches. Or editing options (.git/config). I think the cleanup is easier than it sounds; a lot of the UI is already parameterized based on [appname], which is 'git-gui' or 'git-citool', depending on the name it was invoked as. This just needs to carry through a little bit more. > Also it becomes very tempting to somehow have this "file > browser" selection UI as "tree browser" that can wander around > to view an arbitrary tree in the commit history. The boundary > between git-gui and gitk would start to blurrrrrr..... Indeed. The main entrypoint is "new_browser $committish". I don't care what $committish is, just so long as git-blame would understand it. It could actually be a treeish, but blame would obviously choke when you open a file and we won't get annotation data. I just need to hook up some smarter UI to let you select the committish in question. Then comes things like wanting to extract any given file to the local filesystem (e.g. "git show b:file >c"), etc. As for the line blurring between git-gui and gitk, yea, its heading there. Originally I set out to say "git-gui is for making changes and transport, gitk is for history browsing". With this addition of a tree browser and incremental blame viewer, I'm finding it hard to not add some sort of commit viewer when you double click a commit in the blame output. I *really* do not want to redo what gitk does. Paul, et.al. have done an excellent job with gitk[*1*]. Its currently 6,324 lines. git-gui is another 5,654 lines. I don't think we want them redoing each other's work. It would be better if Paul and I could find a way to meld the two into a single process. -- 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