{"thread":{"id":"8345","subject":"What's new in git-gui.git","startedAt":"2007-05-28T22:49:49Z","lastAt":"2007-05-30T02:39:33Z","messageCount":8,"participants":["Shawn O. Pearce","Johannes Sixt","Alex Riesen","Johannes Schindelin","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"43525","messageId":"20070528224949.GC7044@spearce.org","threadId":"8345","inReplyTo":null,"subject":"What's new in git-gui.git","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-28T22:49:49Z","receivedAt":"2007-05-28T22:49:49Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"I got around to working on git-gui this week. Yay me. Updates for\nboth the stable (0.7.x) series and the new development series\n(0.8.x), and some roadmap items. See below...\n\n--- Stable ---\n\nThe following changes since gitgui-0.7.1\n Shawn O. Pearce (1):\n git-gui: Gracefully handle bad TCL_PATH at compile time\n\nare available in the git repository at:\n\n repo.or.cz:/srv/git/git-gui.git maint\n\nShawn O. Pearce (3):\n git-gui: Tighten internal pattern match for lib/ directory\n Correct key bindings to Control-\n git-gui: Guess our share/git-gui/lib path at runtime if possible\n\n Makefile | 12 ++++++++++--\n git-gui.sh | 17 +++++++++--------\n 2 files changed, 19 insertions(+), 10 deletions(-)\n\nThe final commit in this series has been tagged as gitgui-0.7.2\nand should be packaged as part of the next maintenance release of\ngit 1.5.2. All are trivial fixes for minor issues raised since\n0.7.1 was released.\n\n--- Development ---\n\nThe following changes since gitgui-0.7.2\n Shawn O. Pearce (1):\n git-gui: Guess our share/git-gui/lib path at runtime if possible\n\nare available in the git repository at:\n\n repo.or.cz:/srv/git/git-gui.git master\n\nShawn O. Pearce (9):\n git gui 0.8.0\n git-gui: GUI support for running 'git remote prune '\n git-gui: Show the git-gui library path in 'About git-gui'\n git-gui: Enable verbose Tcl loading earlier\n git-gui: Provide fatal error if library is unavailable\n git-gui: Disable tearoff menus on Windows, Mac OS X\n git-gui: Allow users to rename branches through 'branch -m'\n git-gui: Allow users to delete remote branches\n git-gui: Expose the merge.diffstat configuration option\n\n GIT-VERSION-GEN | 2 +-\n git-gui.sh | 87 +++++++----\n lib/branch_rename.tcl | 137 +++++++++++++++++\n lib/option.tcl | 17 ++-\n lib/remote.tcl | 11 ++\n lib/remote_branch_delete.tcl | 348 ++++++++++++++++++++++++++++++++++++++++++\n lib/transport.tcl | 16 ++-\n 7 files changed, 586 insertions(+), 32 deletions(-)\n create mode 100644 lib/branch_rename.tcl\n create mode 100644 lib/remote_branch_delete.tcl\n\nThis is actually the start of the 0.8.0 development cycle. It is\nstable enough for git.git's master branch. I don't anticipate this\nversion of git-gui being packaged with any git earlier than 1.5.3.\n\nSome major new features have been added:\n\n - Rename an existing branch (git-brach -m).\n - Delete an existing remote branch.\n - Prune expired tracking branches.\n - Automatically prune expired tracking branches during fetch.\n\nI'm hoping to do a lot more before 0.8.0 goes final. Which is part\nof the reason why I don't expect this to be packaged with anything\nearlier than 1.5.3.\n\n--- Roadmap ---\n\nLooking ahead, I'd like to see some improvement in the following\nareas. It would be nice if some Tcl/Tk-minded individuals were\nwilling to dive and help. ;-)\n\n - Initial repository creation\n - Initial repository cloning\n - Select an existing repository from an OS native file dialog\n\n These are mostly about better supporting the MinGW environment\n (or a Cygwin environment) where some users are not used to\n performing operations through a command line terminal window.\n Sometimes being able to start an application through an icon\n and have it prompt you for initial configuration is exactly what\n the user wants.\n\n At the same time we probably should support running against a\n bare repository, at least for the cases of the \"browser\" and\n \"blame\" subcommands.\n\n - Blame viewer coloring should be less horrid\n - Blame viewer should support digging into the prior version\n - Jump to line in blame viewer (use vi's :nnn syntax?)\n - Find substring in blame viewer (use vi's / syntax?)\n\n These have been discussed before. The current blame viewer is\n useful, but not fun to look at. It also doesn't let you dig\n back into history further than the revision it was started on.\n\n Now that the blame viewer is cleaned up and uses git-gui's\n \"class/field/method\" system this is probably a lot easier to\n get done (pre-0.7.0 that code was just a disaster).\n\n - Fetch+merge from arbitrary URL and branch(es)\n\n Aka \"git pull\", but in a GUI. Pulling from random URLs is not\n uncommon in the Git user community and we should support it as\n a first-class operation in git-gui.\n\n The UI I just put in for deleting remote branches may offer a\n good starting point for this, as it does an async ls-remote to\n get the available branch heads.\n\n - Preserve author during amend\n - Set commit author line\n\n These sort of go hand-in-hand. Currently there is no way to enter\n an author; the authorship of a commit is always the current user.\n But I know a few people using git-gui who really should be doing\n `git commit --author=$someoneelse` every once in a while, as\n they are committing files for $someoneelse.\n\n I'm also getting bit by the amend bug myself when I apply\n patches from other people and then go back and try to tweak\n something minor.\n\n-- \nShawn.\n"},{"id":"43541","messageId":"20070529041108.GG7044@spearce.org","threadId":"8345","inReplyTo":"20070528224949.GC7044@spearce.org","subject":"Re: What's new in git-gui.git","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-29T04:11:08Z","receivedAt":"2007-05-29T04:11:08Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Shawn O. Pearce\" wrote:\n> --- Roadmap ---\n> \n> Looking ahead, I'd like to see some improvement in the following\n> areas. It would be nice if some Tcl/Tk-minded individuals were\n> willing to dive and help. ;-)\n\nI also want to get file change notification integrated into git-gui.\nBasic idea is, if you edit a file in your editor of choice, git-gui\nshould notice it right away, without waiting for you to press the\ndamn Rescan button.\n\nOn Windows the only thing that actually works there (aside from\ndrawing lots and lots of blue pixels) is a fancy little file\nmonitoring API. That actually works quite well. Nothing else on\nthat OS works of course, but it will tell you when a file changes.\nNT 4.0 and later only... ;-)\n\nApparently the Linux folks have this new fangled inotify thing\nthat is also good at telling applications about changed files.\nIt seems the hg folks are using it to speed up \"hg status\" by\nhaving a background daemon keep track of which files are dirty,\nand which aren't.\n\nSo I'm likely to want to try to implement something like this for\ncore Git and for git-gui, but my primary development system is Mac\nOS X, where the BSD gods have only given us kqueue() and all its\nwarts... (it is basically useless for this task of monitoring a\n\"huge\" tree like git.git, Mozilla.git need not apply).\n\n-- \nShawn.\n"},{"id":"43546","messageId":"465BDA6E.C56EC2EB@eudaptics.com","threadId":"8345","inReplyTo":"20070528224949.GC7044@spearce.org","subject":"Re: What's new in git-gui.git","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-05-29T07:46:54Z","receivedAt":"2007-05-29T07:46:54Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"\"Shawn O. Pearce\" wrote:\n> - Preserve author during amend\n\n... and author date - at least if no additional changes were staged.\n(Quite often I just want to tweak the commit message, mostly after\ndissecting a topic branch.)\n\n-- Hannes\n"},{"id":"43547","messageId":"81b0412b0705290112r3596c7bdm5c59bb2488cda48e@mail.gmail.com","threadId":"8345","inReplyTo":"20070529041108.GG7044@spearce.org","subject":"Re: What's new in git-gui.git","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-29T08:12:59Z","receivedAt":"2007-05-29T08:12:59Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 5/29/07, Shawn O. Pearce wrote:\n> Apparently the Linux folks have this new fangled inotify thing\n\n... since july 2005\n"},{"id":"43556","messageId":"Pine.LNX.4.64.0705291157540.4648@racer.site","threadId":"8345","inReplyTo":"20070529041108.GG7044@spearce.org","subject":"Re: What's new in git-gui.git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-29T10:59:14Z","receivedAt":"2007-05-29T10:59:14Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 29 May 2007, Shawn O. Pearce wrote:\n\n> Apparently the Linux folks have this new fangled inotify thing that is \n> also good at telling applications about changed files. It seems the hg \n> folks are using it to speed up \"hg status\" by having a background daemon \n> keep track of which files are dirty, and which aren't.\n\nAn SCM which runs a background process? Please, no.\n\nNext thing is, you have a daemon running which permanently scans your \nsource code for copynotsoright violations.\n\nCiao,\nDscho\n"},{"id":"43559","messageId":"20070529111836.GW4489@pasky.or.cz","threadId":"8345","inReplyTo":"20070529041108.GG7044@spearce.org","subject":"Re: What's new in git-gui.git","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-29T11:18:36Z","receivedAt":"2007-05-29T11:18:36Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, May 29, 2007 at 06:11:08AM CEST, Shawn O. Pearce wrote:\n> Apparently the Linux folks have this new fangled inotify thing\n> that is also good at telling applications about changed files.\n> It seems the hg folks are using it to speed up \"hg status\" by\n> having a background daemon keep track of which files are dirty,\n> and which aren't.\n\nHow well does this play with NFS? I'm working at two places and at both\nhave my ~ on NFS and sometimes touch the working tree from various\nmachines. Would the inotify-based approach silently fail here? Or does\ninotify just refuse to work on NFS? Quick google search suggests the\nformer, which is more than ok for informative purposes but big problem\nif you actually _rely_ on the inotify to keep your index up-to-date.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"43598","messageId":"20070530023419.GK7044@spearce.org","threadId":"8345","inReplyTo":"20070529111836.GW4489@pasky.or.cz","subject":"Re: What's new in git-gui.git","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-30T02:34:19Z","receivedAt":"2007-05-30T02:34:19Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Petr Baudis wrote:\n> On Tue, May 29, 2007 at 06:11:08AM CEST, Shawn O. Pearce wrote:\n> > Apparently the Linux folks have this new fangled inotify thing\n> > that is also good at telling applications about changed files.\n> > It seems the hg folks are using it to speed up \"hg status\" by\n> > having a background daemon keep track of which files are dirty,\n> > and which aren't.\n> \n> How well does this play with NFS? I'm working at two places and at both\n> have my ~ on NFS and sometimes touch the working tree from various\n> machines. Would the inotify-based approach silently fail here? Or does\n> inotify just refuse to work on NFS? Quick google search suggests the\n> former, which is more than ok for informative purposes but big problem\n> if you actually _rely_ on the inotify to keep your index up-to-date.\n\n>From what I've read on it thus far (which isn't much) inotify\ndoesn't work over NFS.\n\nI would *never* suggest relying on inotify for everything.\nBut making it an option for folks who can use it may be nice.\nA lot of us do work on a local filesystem. Being able to get\nfaster status output in those cases could be nice, especially on\na big tree and slow VFS systems like Windows.\n\n-- \nShawn.\n"},{"id":"43599","messageId":"20070530023933.GL7044@spearce.org","threadId":"8345","inReplyTo":"Pine.LNX.4.64.0705291157540.4648@racer.site","subject":"Re: What's new in git-gui.git","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-30T02:39:33Z","receivedAt":"2007-05-30T02:39:33Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> \n> On Tue, 29 May 2007, Shawn O. Pearce wrote:\n> \n> > Apparently the Linux folks have this new fangled inotify thing that is \n> > also good at telling applications about changed files. It seems the hg \n> > folks are using it to speed up \"hg status\" by having a background daemon \n> > keep track of which files are dirty, and which aren't.\n> \n> An SCM which runs a background process? Please, no.\n\nWell, not required. Making it required to make things work is\nclearly insane. But letting a user optionally start a background\nprocess to monitor their working directory and cache dirty\nflags for files may be faster for some users on some systems\nand some workflows. And it could make git-gui more responsive.\nIf git-gui starts/stops the \"background process\" along with its\nwindow opening/closing, who cares that its running? Especially if\nit can be enabled/disabled by a little checkbox thingy?\n\n> Next thing is, you have a daemon running which permanently scans your \n> source code for copynotsoright violations.\n\nI won't. Maybe a future employer of yours might... ;-)\n\n-- \nShawn.\n"}]}