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 already a quite
     expensive operation.

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


On Oct 8, 2007, at 1:30 AM, Shawn O. Pearce wrote:

quoted text
> Steffen Prohaska <prohaska@zib.de> wrote:
>
>> +	label $w_body.space
>> +	label $w_body.recentlabel \
>> +		-anchor w \
>> +		-text "Select Recent Repository:"
>
> This string needs to be i18n'd with [mc ...].

changed in first patch.

quoted text
>> +	listbox $w_body.recentlist \
>
> 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
> that the widget resides at, such as to alter the layout.

changed in first patch.


quoted text
>> +proc _append_recentrepos {path} {
>> +	set recent [get_config gui.recentrepos]
>> +	if {[lsearch $recent $path] < 0} {
>> +		lappend recent $path
>> +	}
>> +	if {[llength $recent] > 10} {
>> +		set recent [lrange $recent 1 end]
>> +	}
>> +	regsub -all "\[{}\]" $recent {"} recent
>> +	git config --global gui.recentrepos $recent
>> +}
>
> 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 don't think " is allowed. I wasn't able to create a file containing
" in its path. Neither from the explorer nor on the command line.


quoted text
> 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.
>

The second patch actually runs git config several times to first
remote all multi-value entries and then create them one by one. This
is worse performance than before.

This could be avoided by selectively removing only a single entry.
'git config' could be asked to only remove the entry that was removed
from the tcl list. But 'git config' only accepts regular expression
to do so.

I don't know how to escape a simple string to a corresponding
regular expression that matches only the string but nothing else.

For my problem it would be much easier if 'git config' accepted just
a plain string that must be matched exactly and not a regular  
expression.

I see two solutions:
1) Someone explains me how to convert a string to a regular expression
matching only the input string.

2) "git config" is modified to accept a simple string as its second  
argument.
Maybe we can use implementation in the second patch for now and wait
until "git config" is modified. Note, I'll not start to work on this  
right
away because I want to stay focused on the basic functionality on  
Windows and,
for now, do not care about performance too much.

	Steffen