If git-gui is started outside a work tree the repository
chooser will offer a list of recently opend repositories.
Clicking on an entry directly opens the repository.

The list of recently opened repositories is stored in the
config as gui.recentrepos. If the list grows beyond 10
entries it will be truncated.

Note, only repositories that are opened through the
repository chooser will get added to the recent list.
Repositories opened from the shell will not yet be added.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 git-gui/lib/choose_repository.tcl |   47 +++++++++++++++++++++++++++++++++++++
 1 files changed, 47 insertions(+), 0 deletions(-)


The commit is also available on branch
steffen/git-gui-openrecent in 4msysgit.


Shawn,
I'd suggest to reduce the number of clicks needed to open or
clone an existing directory that is not in the list of
recent repositories. First choosing from the radiobuttons
and then clicking next is one click to much. There are no
options to combine. Choosing from the list should
immediately trigger the action.

We could either put 'Create/Clone/Open New Repository' into
the Repository menu and only present the recent repository
list. Or we could offer push buttons for the other actions.

	Steffen


diff --git a/git-gui/lib/choose_repository.tcl b/git-gui/lib/choose_repository.tcl
index 16bf67c..bfc8780 100644
--- a/git-gui/lib/choose_repository.tcl
+++ b/git-gui/lib/choose_repository.tcl
@@ -116,9 +116,26 @@ constructor pick {} {
 		-text [mc "Open Existing Repository"] \
 		-variable @action \
 		-value open
+	label $w_body.space
+	label $w_body.recentlabel \
+		-anchor w \
+		-text "Select Recent Repository:"
+	listbox $w_body.recentlist \
+		-relief flat \
+		-width 50 \
+		-height 10 \
+		-exportselection false \
+		-selectmode select
+	foreach p [_get_recentrepos] {
+		$w_body.recentlist insert end $p
+	}
+	bind $w_body.recentlist <<ListboxSelect>> [cb _open_recent]
 	pack $w_body.new -anchor w -fill x
 ...
[ message continues ]

I think that all makes a lot of sense.  Three comments below about

I agree entirely.  That "Next" button is stupid stupid stupid.
What was I smoking that day?  :-)

I'm concerned about putting them into the Repository menu only
as then the main window is competely void and users are sort of
wondering what they should do next.  I think we should actually


Please make a field in this class called say "w_recentlist"
so you can use that field name instead of $w_body.recentlist.
This simplifies the code if we ever have to change the actual path

Why treat this as a Tcl list in a single value?  Why not make it
a true multi-value configuration entry in ~/.gitconfig, like how
remote.$name.fetch is a multi-value entry?  Does Windows allow
you to put " in a path name?  Because the above regex will make
a list of paths that contains " in one of the entries invalid.

I think you also want to have this function return back immediately
if [lsearch $recent $path] >= 0 as then you don't invoke git-config
to perform a no-op change in the configuration file.  As you well
know forking on Windows is a major cost.  We shouldn't run git-config
just because the user opened a recent repository.

-- 
Shawn.
-

[ message continues ]

Shawn,
I attached two patches. They should eventually be both squashed into  
one.
You can also cherry pick them from work/setup-preview in 4msysgit.
I'm not yet fully convinced of the performance of the second patch.
It is far from optimal, although it might be sufficient.

If you're satisfied with the current implementation you can squash them
into a single commit; or ask me to do that.

More comments below, after the summary.


commit a483fdd562d6c44d68a998224e0bbb17933b624a
Author: Steffen Prohaska <prohaska@zib.de>
Date:   Mon Oct 8 08:25:47 2007 +0200

     git-gui: offer a list of recent repositories on startup

     If git-gui is started outside a work tree the repository
     chooser will offer a list of recently opend repositories.
     Clicking on an entry directly opens the repository.

     The list of recently opened repositories is stored in the
     config as gui.recentrepos. If the list grows beyond 10
     entries it will be truncated.

     Note, only repositories that are opened through the
     repository chooser will get added to the recent list.
     Repositories opened from the shell will not yet be added.

     Signed-off-by: Steffen Prohaska <prohaska@zib.de>

commit a9f083e83717eef91ba8842ece4a3ec0824126af
Author: Steffen Prohaska <prohaska@zib.de>
Date:   Mon Oct 8 08:14:34 2007 +0200

     git-gui: handle list of recent repos as multi config gui.recentrepo

     Instead of encoding the list of recently opened repositories
     in a single config line, this commit uses multiple lines of
     gui.recentrepo.

     An advantage is that the solution makes the list explicit
     on the git config level. This may be easier to understand
     if the user wants to look at the configuration.

     A disadvantage (of the current implementation) is that it
     requires more git config calls to manage the list. This could
     be optimized. But maybe not required because the list is only
     updated on opening a new repository, which is ...
[ message continues ]

Hi,


May I suggest not putting this list into ~/.gitconfig, but rather 
~/.gitguirc?  It is not really a user-specific git configuration...

Besides, the call to "git-config --global --unset-all gui.recentrepo" 
fails, as far as I can tell because there is not yet such an entry.

Ciao,
Dscho

-

[ message continues ]

git-gui already stores other options as global variables gui.*.
(see git-gui/lib/option.tcl). I just added gui.recentrepo. The
list of recent repos should go to wherever git-gui stores its options.

Right now this is in ~/.gitconfig, if I understand correctly. Shawn?

	Steffen
-

[ message continues ]

Yes, that's correct.

An item on my todo list (see todo branch in git-gui.git) is to move
this into a ~/.gitguiconfig or something like that, but I was going
to keep it as a git-config style file so git-config can be used to
process its contents.

Until that task is complete I'd rather keep all of the "gui" options
in ~/.gitconfig (global) or .git/config (per-repository).  When I
split stuff out to git-gui specific files I'll have to migrate the
entire "gui" section at once.

-- 
Shawn.
-

[ message continues ]

Hi,


FWIW I was only concerned about the recent repos, since strictly speaking, 
they are not options to git-gui...  But I do not care deeply.

Ciao,
Dscho

-

[ message continues ]

Thanks.  I'm applying the patch below over both of yours, and
then squashing them all together and keeping you as the author.

I did not like how the listbox looked (or worked!) on Mac OS X.
Clicking on the item was at first a very non-obvious action, and
then when I did do it I was very shocked to see the repository open
immediately.  My brain knew the action was wired to the selection
event (I obviously read the two patches before applying them),
but it didn't expect that behavior.  Clearly the wrong UI model.

The patch below uses a text widget instead and renders each of
the repositories as a blue underlined link.  Users will generally
assume that clicking on such links will take them immediately to
that repository (much as it would take them to another webpage if
this was a web browser).

The "Open Recent Repositories" is not even shown in the UI if there
aren't any to offer to the user.  Showing them this area just looks
silly if they haven't opened or cloned anything yet.

We now add freshly created or cloned repositories to the list of
recently opened repositories.  These are just as fair game for
being recently accessed as any others.  Perhaps even more so as
users may wonder where they cloned that repository to the last time
they started git-gui.

We always store the absolute path of a repository into the config.
This avoids the mess of opening a repository twice using say a
relative path entered into the text entry field and then opening
it later via a file browser, only to find out you now have the same
repository in the recent list twice.

I fixed the --unset-all bug and also avoided the --unset-all/--add
loop you were using.  We convert the value into a "safe" expression
and then try to match on it.

---

diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index 4deb1ec..bdfdbae 100644
--- a/lib/choose_repository.tcl
+++ b/lib/choose_repository.tcl
@@ -80,27 +80,35 @@ constructor pick {} {
 		-text [mc "Open Existing Repository"] \
 ...
[ message continues ]

Shawn,


This is similar to what I had in mind, but was lacking tk knowledge

That all sound very reasonable to me.

I haven't applied your patch but only read through it. Looks good to me.

Thanks,
Steffen



-

[ message continues ]

Heh.  Tk makes some things easy, assuming you know what you are
doing.  It makes some other things damn near impossible, even if
you do know all of Tk and its internals too.  Anyway, your patches
were a really good start on this and it saved me a lot of time to
just tweak what you already had.  So I really appreciate you taking

The combined result is now in my `pu` branch on repo.or.cz.
Remember that I freely rebase that branch and any topic in it,
so I might wind up rebasing this topic before I finally merge it
to master.

I have given the change some light testing tonight but want to
beat on it more and also fix the radio button issue you pointed
out before I merge this series of improvements into master.

-- 
Shawn.
-

[ message continues ]