What's new in git-gui.git

What's new in git-gui.git

[Shawn O. Pearce]

I got around to working on git-gui this week.  Yay me.  Updates for
both the stable (0.7.x) series and the new development series
(0.8.x), and some roadmap items.  See below...

--- Stable ---

The following changes since gitgui-0.7.1
  Shawn O. Pearce (1):
        git-gui: Gracefully handle bad TCL_PATH at compile time

are available in the git repository at:

  repo.or.cz:/srv/git/git-gui.git maint

Shawn O. Pearce (3):
      git-gui: Tighten internal pattern match for lib/ directory
      Correct key bindings to Control-<foo>
      git-gui: Guess our share/git-gui/lib path at runtime if possible

 Makefile   |   12 ++++++++++--
 git-gui.sh |   17 +++++++++--------
 2 files changed, 19 insertions(+), 10 deletions(-)

The final commit in this series has been tagged as gitgui-0.7.2
and should be packaged as part of the next maintenance release of
git 1.5.2.  All are trivial fixes for minor issues raised since
0.7.1 was released.

--- Development ---

The following changes since gitgui-0.7.2
  Shawn O. Pearce (1):
        git-gui: Guess our share/git-gui/lib path at runtime if possible

are available in the git repository at:

  repo.or.cz:/srv/git/git-gui.git master

Shawn O. Pearce (9):
      git gui 0.8.0
      git-gui: GUI support for running 'git remote prune <name>'
      git-gui: Show the git-gui library path in 'About git-gui'
      git-gui: Enable verbose Tcl loading earlier
      git-gui: Provide fatal error if library is unavailable
      git-gui: Disable tearoff menus on Windows, Mac OS X
      git-gui: Allow users to rename branches through 'branch -m'
      git-gui: Allow users to delete remote branches
      git-gui: Expose the merge.diffstat configuration option

 GIT-VERSION-GEN              |    2 +-
 git-gui.sh                   |   87 +++++++----
 lib/branch_rename.tcl        |  137 +++++++++++++++++
 lib/option.tcl               |   17 ++-
 lib/remote.tcl               |   11 ++
 lib/remote_branch_delete.tcl |  348 ++++++++++++++++++++++++++++++++++++++++++
 lib/transport.tcl            |   16 ++-
 7 files changed, 586 insertions(+), 32 deletions(-)
 create mode 100644 lib/branch_rename.tcl
 create mode 100644 lib/remote_branch_delete.tcl

This is actually the start of the 0.8.0 development cycle.  It is
stable enough for git.git's master branch.  I don't anticipate this
version of git-gui being packaged with any git earlier than 1.5.3.

Some major new features have been added:

 - Rename an existing branch (git-brach -m).
 - Delete an existing remote branch.
 - Prune expired tracking branches.
 - Automatically prune expired tracking branches during fetch.

I'm hoping to do a lot more before 0.8.0 goes final.  Which is part
of the reason why I don't expect this to be packaged with anything
earlier than 1.5.3.

--- Roadmap ---

Looking ahead, I'd like to see some improvement in the following
areas.  It would be nice if some Tcl/Tk-minded individuals were
willing to dive and help.  ;-)

 - Initial repository creation
 - Initial repository cloning
 - Select an existing repository from an OS native file dialog

   These are mostly about better supporting the MinGW environment
   (or a Cygwin environment) where some users are not used to
   performing operations through a command line terminal window.
   Sometimes being able to start an application through an icon
   and have it prompt you for initial configuration is exactly what
   the user wants.

   At the same time we probably should support running against a
   bare repository, at least for the cases of the "browser" and
   "blame" subcommands.

 - Blame viewer coloring should be less horrid
 - Blame viewer should support digging into the prior version
 - Jump to line in blame viewer (use vi's :nnn syntax?)
 - Find substring in blame viewer (use vi's / syntax?)

   These have been discussed before.  The current blame viewer is
   useful, but not fun to look at.  It also doesn't let you dig
   back into history further than the revision it was started on.

   Now that the blame viewer is cleaned up and uses git-gui's
   "class/field/method" system this is probably a lot easier to
   get done (pre-0.7.0 that code was just a disaster).

 - Fetch+merge from arbitrary URL and branch(es)

   Aka "git pull", but in a GUI.  Pulling from random URLs is not
   uncommon in the Git user community and we should support it as
   a first-class operation in git-gui.

   The UI I just put in for deleting remote branches may offer a
   good starting point for this, as it does an async ls-remote to
   get the available branch heads.

 - Preserve author during amend
 - Set commit author line

   These sort of go hand-in-hand.  Currently there is no way to enter
   an author; the authorship of a commit is always the current user.
   But I know a few people using git-gui who really should be doing
   `git commit --author=$someoneelse` every once in a while, as
   they are committing files for $someoneelse.

   I'm also getting bit by the amend bug myself when I apply
   patches from other people and then go back and try to tweak
   something minor.

-- 
Shawn.

Re: What's new in git-gui.git

[Shawn O. Pearce]

"Shawn O. Pearce" <spearce@spearce.org> wrote:
> --- Roadmap ---
> 
> Looking ahead, I'd like to see some improvement in the following
> areas.  It would be nice if some Tcl/Tk-minded individuals were
> willing to dive and help.  ;-)

I also want to get file change notification integrated into git-gui.
Basic idea is, if you edit a file in your editor of choice, git-gui
should notice it right away, without waiting for you to press the
damn Rescan button.

On Windows the only thing that actually works there (aside from
drawing lots and lots of blue pixels) is a fancy little file
monitoring API.  That actually works quite well.  Nothing else on
that OS works of course, but it will tell you when a file changes.
NT 4.0 and later only... ;-)

Apparently the Linux folks have this new fangled inotify thing
that is also good at telling applications about changed files.
It seems the hg folks are using it to speed up "hg status" by
having a background daemon keep track of which files are dirty,
and which aren't.

So I'm likely to want to try to implement something like this for
core Git and for git-gui, but my primary development system is Mac
OS X, where the BSD gods have only given us kqueue() and all its
warts... (it is basically useless for this task of monitoring a
"huge" tree like git.git, Mozilla.git need not apply).

-- 
Shawn.

Re: What's new in git-gui.git

[Johannes Sixt]

"Shawn O. Pearce" wrote:
>  - Preserve author during amend

... and author date - at least if no additional changes were staged.
(Quite often I just want to tweak the commit message, mostly after
dissecting a topic branch.)

-- Hannes

Re: What's new in git-gui.git

[Alex Riesen]

On 5/29/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Apparently the Linux folks have this new fangled inotify thing

... since july 2005

Re: What's new in git-gui.git

[Johannes Schindelin]

Hi,

On Tue, 29 May 2007, Shawn O. Pearce wrote:

> Apparently the Linux folks have this new fangled inotify thing that is 
> also good at telling applications about changed files. It seems the hg 
> folks are using it to speed up "hg status" by having a background daemon 
> keep track of which files are dirty, and which aren't.

An SCM which runs a background process? Please, no.

Next thing is, you have a daemon running which permanently scans your 
source code for copynotsoright violations.

Ciao,
Dscho

Re: What's new in git-gui.git

[Petr Baudis]

On Tue, May 29, 2007 at 06:11:08AM CEST, Shawn O. Pearce wrote:
> Apparently the Linux folks have this new fangled inotify thing
> that is also good at telling applications about changed files.
> It seems the hg folks are using it to speed up "hg status" by
> having a background daemon keep track of which files are dirty,
> and which aren't.

How well does this play with NFS? I'm working at two places and at both
have my ~ on NFS and sometimes touch the working tree from various
machines. Would the inotify-based approach silently fail here? Or does
inotify just refuse to work on NFS? Quick google search suggests the
former, which is more than ok for informative purposes but big problem
if you actually _rely_ on the inotify to keep your index up-to-date.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett

Re: What's new in git-gui.git

[Shawn O. Pearce]

Petr Baudis <pasky@suse.cz> wrote:
> On Tue, May 29, 2007 at 06:11:08AM CEST, Shawn O. Pearce wrote:
> > Apparently the Linux folks have this new fangled inotify thing
> > that is also good at telling applications about changed files.
> > It seems the hg folks are using it to speed up "hg status" by
> > having a background daemon keep track of which files are dirty,
> > and which aren't.
> 
> How well does this play with NFS? I'm working at two places and at both
> have my ~ on NFS and sometimes touch the working tree from various
> machines. Would the inotify-based approach silently fail here? Or does
> inotify just refuse to work on NFS? Quick google search suggests the
> former, which is more than ok for informative purposes but big problem
> if you actually _rely_ on the inotify to keep your index up-to-date.

>From what I've read on it thus far (which isn't much) inotify
doesn't work over NFS.

I would *never* suggest relying on inotify for everything.
But making it an option for folks who can use it may be nice.
A lot of us do work on a local filesystem.  Being able to get
faster status output in those cases could be nice, especially on
a big tree and slow VFS systems like Windows.

-- 
Shawn.

Re: What's new in git-gui.git

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 
> On Tue, 29 May 2007, Shawn O. Pearce wrote:
> 
> > Apparently the Linux folks have this new fangled inotify thing that is 
> > also good at telling applications about changed files. It seems the hg 
> > folks are using it to speed up "hg status" by having a background daemon 
> > keep track of which files are dirty, and which aren't.
> 
> An SCM which runs a background process? Please, no.

Well, not required.  Making it required to make things work is
clearly insane.  But letting a user optionally start a background
process to monitor their working directory and cache dirty
flags for files may be faster for some users on some systems
and some workflows.  And it could make git-gui more responsive.
If git-gui starts/stops the "background process" along with its
window opening/closing, who cares that its running?  Especially if
it can be enabled/disabled by a little checkbox thingy?

> Next thing is, you have a daemon running which permanently scans your 
> source code for copynotsoright violations.

I won't.  Maybe a future employer of yours might...  ;-)

-- 
Shawn.