Re: More precise tag following

["Shawn O. Pearce" <spearce@spearce.org>]

Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> 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.