git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 4/4] git gui: allow for a long recentrepo list

From
Philip Oakley <philipoakley@iee.org>
Date
Dec 17, 2015, 19:32 UTC
Message-ID
<1CAD7B4439DF4AE19EE8CD56CB47F399@PhilipOakley>
In-Reply-To
<xmqqsi30c1lk.fsf@gitster.mtv.corp.google.com>
From: "Junio C Hamano" <gitster@pobox.com>, December 17, 2015 7:32 PM
Show 18 quoted lines
> Philip Oakley <philipoakley@iee.org> writes:
>
>> The gui.recentrepo list may be longer than the maxrecent setting.
>> Allow extra space to show any extra entries.
>>
>> In an ideal world, the git gui would limit the number of entries
>> to the maxrecent setting, however the recentrepo config list may
>> have been extended outside of the gui, or the maxrecent setting changed
>> to a reduced value. Further, when testing the gui's recentrepo
>> logic it is useful to show these extra, but valid, entries.
>
> I do not have a strong objection either way, but the magic number 5
> smells like an indication that this is solving a wrong problem or
> solving a problem in a wrong approach.  What happens to the entries
> beyond $maxrecent-th in the recent list with the current code?  The
> list effectively truncated and not shown?  Wouldn't the same thing
> happen to the entries beyond ($maxrecent+5)-th in the recent list
> with your patch?

True, it was a magic number selected as being a moderate overspill allowance. I tried 3 and 5 as possible values, and 5 didn't look ungainly, even on my small netbook, and covered all my test hacking cases.

The issue was that the prior code assumed that the fault could never happen and limited the display, which is sorted, to the max value, so in a fault condition the most recent repo could fall off the bottom.

As a bit of 'monkey patching' I wasn't sure how the dialog creation could know in advance how long the list would be, so I simply added on a small margin.

Show 5 quoted lines
>
> Truncating the list at $maxrecent-th to match the display
> (i.e. declare that "$maxrecent" is really the max number of entries
> we would keep track of), or allowing the UI to scroll so that
> entries beyond $maxrecent-th one can be shown, perhaps?

This would certainly be a reasonable approach, but I don't know enough of the tcl to know how to make it happen. If anyone has suggestions...

Show 29 quoted lines
>
>>
>> Signed-off-by: Philip Oakley <philipoakley@iee.org>
>> ---
>> word usage corrected.
>> Eric's comments $gmane/282432
>> ---
>>  git-gui/lib/choose_repository.tcl | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/git-gui/lib/choose_repository.tcl 
>> b/git-gui/lib/choose_repository.tcl
>> index ad7a888..a08ed4f 100644
>> --- a/git-gui/lib/choose_repository.tcl
>> +++ b/git-gui/lib/choose_repository.tcl
>> @@ -153,7 +153,7 @@ constructor pick {} {
>>  -background [get_bg_color $w_body.recentlabel] \
>>  -wrap none \
>>  -width 50 \
>> - -height $maxrecent
>> + -height [expr {$maxrecent + 5}]
>>  $w_recentlist tag conf link \
>>  -foreground blue \
>>  -underline 1
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
Previous: Junio C HamanoNext: Philip Oakley
Message 7 of 11 in “Fix git-gui when recentrepo list has duplicates”
  1. 0/4 Fix git-gui when recentrepo list has duplicatesPhilip Oakley, Dec 16, 2015
  2. 1/4 git-gui: de-dup entries from gui.recentrepoPhilip Oakley, Dec 16, 2015
  3. 2/4 git gui: cope with duplicates in _get_recentrepoPhilip Oakley, Dec 16, 2015
  4. 3/4 git gui: de-dup selected repo from recentrepo historyPhilip Oakley, Dec 16, 2015
  5. 4/4 git gui: allow for a long recentrepo listPhilip Oakley, Dec 16, 2015
  6. Junio C HamanoDec 17, 2015
  7. Philip OakleyDec 17, 2015
  8. Philip OakleyDec 17, 2015
  9. 4/4 git gui: allow for a long recentrepo listPhilip Oakley, Dec 17, 2015
  10. Junio C HamanoDec 17, 2015
  11. Philip OakleyDec 17, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.