{"thread":{"id":"26488","subject":"[PATCH] git-gui: document the gui.maxfilesdisplayed variable","startedAt":"2011-02-13T12:53:24Z","lastAt":"2011-02-14T22:46:47Z","messageCount":5,"participants":["Heiko Voigt","Junio C Hamano","Jonathan Nieder","Jens Lehmann"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"160999","messageId":"20110213125324.GA31986@book.hvoigt.net","threadId":"26488","inReplyTo":null,"subject":"[PATCH] git-gui: document the gui.maxfilesdisplayed variable","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-02-13T12:53:24Z","receivedAt":"2011-02-13T12:53:24Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"This removes a TODO item in the git-gui source.\n\nSigned-off-by: Heiko Voigt <hvoigt@hvoigt.net>\n---\nI am not sure how we should go about this patch. Should I split it in\ntwo since it removes the TODO line in git-gui and adds the\ndocumentation in git?\n\nCheers Heiko\n\n Documentation/config.txt |    5 +++++\n git-gui/git-gui.sh       |    1 -\n 2 files changed, 5 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 722e00a..d8edeeb 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1122,6 +1122,11 @@ gui.matchtrackingbranch::\n \tdefault to tracking remote branches with matching names or\n \tnot. Default: \"false\".\n \n+gui.maxfilesdisplayed::\n+\tConfigures the amount of changed files after which git gui will\n+\tissue a warning that there are more changes than can be\n+\tdisplayed.\n+\n gui.newbranchtemplate::\n \tIs used as suggested name when creating new branches using the\n \tlinkgit:git-gui[1].\ndiff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh\nindex e03eda0..db09f00 100755\n--- a/git-gui/git-gui.sh\n+++ b/git-gui/git-gui.sh\n@@ -838,7 +838,6 @@ set default_config(gui.newbranchtemplate) {}\n set default_config(gui.spellingdictionary) {}\n set default_config(gui.fontui) [font configure font_ui]\n set default_config(gui.fontdiff) [font configure font_diff]\n-# TODO: this option should be added to the git-config documentation\n set default_config(gui.maxfilesdisplayed) 5000\n set default_config(gui.usettk) 1\n set default_config(gui.warndetachedcommit) 1\n-- \n1.7.4.rc3.4.g155c4\n"},{"id":"161031","messageId":"7v39nruk9j.fsf@alter.siamese.dyndns.org","threadId":"26488","inReplyTo":"20110213125324.GA31986@book.hvoigt.net","subject":"Re: [PATCH] git-gui: document the gui.maxfilesdisplayed variable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-14T07:51:04Z","receivedAt":"2011-02-14T07:51:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt <hvoigt@hvoigt.net> writes:\n\n> I am not sure how we should go about this patch. Should I split it in\n> two since it removes the TODO line in git-gui and adds the\n> documentation in git?\n\nTwo opposing thoughts.\n\n 1. We can keep git-gui and git proper separate projects, move git-gui\n    documentation out of git to git-gui, and with clever Makefile trick\n    include and build git-gui related documentation conditionally only\n    when git-gui appears part of the git project tree (this anticipates a\n    future where git-gui is bound to git not with the subtree merge\n    strategy as we currently do, but as a submodule).\n\n 2. Just like the Linux kernel project, we can make each subsystem with\n    separate maintainers just different repositories of the same git\n    project with their own focus.  We already do this for git-svn (which I\n    delegate to Eric Wong by pulling from him) and some parts of contrib/\n    tree; we have already been halfway there for gitweb/ (which I don't\n    regularly \"pull from\", but I mainly act as a patch monkey without\n    actively managing that part myself).  I don't see why we cannot extend\n    that model to git-gui and gitk.\n"},{"id":"161117","messageId":"20110214220318.GD50815@book.hvoigt.net","threadId":"26488","inReplyTo":"7v39nruk9j.fsf@alter.siamese.dyndns.org","subject":"future of git-gui as subsytem or submodule, WAS: [PATCH] git-gui: document the gui.maxfilesdisplayed variable","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-02-14T22:03:18Z","receivedAt":"2011-02-14T22:03:18Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Sun, Feb 13, 2011 at 11:51:04PM -0800, Junio C Hamano wrote:\n> Two opposing thoughts.\n> \n>  1. We can keep git-gui and git proper separate projects, move git-gui\n>     documentation out of git to git-gui, and with clever Makefile trick\n>     include and build git-gui related documentation conditionally only\n>     when git-gui appears part of the git project tree (this anticipates a\n>     future where git-gui is bound to git not with the subtree merge\n>     strategy as we currently do, but as a submodule).\n> \n>  2. Just like the Linux kernel project, we can make each subsystem with\n>     separate maintainers just different repositories of the same git\n>     project with their own focus.  We already do this for git-svn (which I\n>     delegate to Eric Wong by pulling from him) and some parts of contrib/\n>     tree; we have already been halfway there for gitweb/ (which I don't\n>     regularly \"pull from\", but I mainly act as a patch monkey without\n>     actively managing that part myself).  I don't see why we cannot extend\n>     that model to git-gui and gitk.\n\nI would vote for 2. Not because I think submodules will not become as easy to\nuse so they are ready for that but I think there are mainly two reasons\nfor using a submodule\n\n  A. The submodule contains shared code which is used by multiple projects\n\n  B. A submodule is used to keep large collection of files seperate from\n     a project because most times they are not needed and would\n     interfere with the project.\n\nThere are maybe more but these two do not apply to git-gui and I like\nthe way it is currently integrated in one repository with git. It also\nunderlines the fact that git-gui is AFAICS the standard and best\ndeveloped gui for git.\n\nAnother plus, if we extend that model to gitk, is that both could start\nsharing code between each other (maybe relocate to the same directory).\n\nAlthough 1. would be a good choice for getting more people involved in\nenhancing submodule support, from a philosophical standpoint, I think 2.\nis the more natural choice.\n\nWhat do others think?\n\nCheers Heiko\n"},{"id":"161120","messageId":"20110214221738.GA24265@elie","threadId":"26488","inReplyTo":"20110214220318.GD50815@book.hvoigt.net","subject":"Re: future of git-gui as subsytem or submodule","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-14T22:17:38Z","receivedAt":"2011-02-14T22:17:38Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nTwo quick thoughts.\n\nHeiko Voigt wrote:\n> On Sun, Feb 13, 2011 at 11:51:04PM -0800, Junio C Hamano wrote:\n\n>>  2. Just like the Linux kernel project, we can make each subsystem with\n>>     separate maintainers just different repositories of the same git\n>>     project with their own focus.  We already do this for git-svn (which I\n[...]\n> Another plus, if we extend that model to gitk, is that both could start\n> sharing code between each other (maybe relocate to the same directory).\n\nI think historically Paul has tried to maintain compatibility with\nolder git versions in gitk, to allow it to be used as a separate\nproject.\n\nA dream would be for gitk and hgk to share code, but I'm not sure\nanyone has even tried a proof-of-concept for that.\n"},{"id":"161125","messageId":"4D59B0D7.5000107@web.de","threadId":"26488","inReplyTo":"20110214220318.GD50815@book.hvoigt.net","subject":"Re: future of git-gui as subsytem or submodule, WAS: [PATCH] git-gui: document the gui.maxfilesdisplayed variable","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-02-14T22:46:47Z","receivedAt":"2011-02-14T22:46:47Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 14.02.2011 23:03, schrieb Heiko Voigt:\n> On Sun, Feb 13, 2011 at 11:51:04PM -0800, Junio C Hamano wrote:\n>> Two opposing thoughts.\n>>\n>>  1. We can keep git-gui and git proper separate projects, move git-gui\n>>     documentation out of git to git-gui, and with clever Makefile trick\n>>     include and build git-gui related documentation conditionally only\n>>     when git-gui appears part of the git project tree (this anticipates a\n>>     future where git-gui is bound to git not with the subtree merge\n>>     strategy as we currently do, but as a submodule).\n>>\n>>  2. Just like the Linux kernel project, we can make each subsystem with\n>>     separate maintainers just different repositories of the same git\n>>     project with their own focus.  We already do this for git-svn (which I\n>>     delegate to Eric Wong by pulling from him) and some parts of contrib/\n>>     tree; we have already been halfway there for gitweb/ (which I don't\n>>     regularly \"pull from\", but I mainly act as a patch monkey without\n>>     actively managing that part myself).  I don't see why we cannot extend\n>>     that model to git-gui and gitk.\n> \n> I would vote for 2. Not because I think submodules will not become as easy to\n> use so they are ready for that but I think there are mainly two reasons\n> for using a submodule\n> \n>   A. The submodule contains shared code which is used by multiple projects\n> \n>   B. A submodule is used to keep large collection of files seperate from\n>      a project because most times they are not needed and would\n>      interfere with the project.\n\nC. The subproject is developed by someone else, is not under the\n   administrative control of the superproject, and follows a different\n   release cycle. (as seen on the Git Wiki ;-)\n\nI don't have strong feelings about this choice, but because of the way\ngit-gui and gitk are developed at the moment 1) seems more appropriate\nright now. But this is Pat's and Paul's call, as they have to agree with\nthe choice taken and choosing 2) might tie those guis more to a specific\ngit version than they might be comfortable with. But I'm just guessing\nhere ...\n\n> There are maybe more but these two do not apply to git-gui and I like\n> the way it is currently integrated in one repository with git. It also\n> underlines the fact that git-gui is AFAICS the standard and best\n> developed gui for git.\n> \n> Another plus, if we extend that model to gitk, is that both could start\n> sharing code between each other (maybe relocate to the same directory).\n\nThat is an advantage of approach 2).\n\n> Although 1. would be a good choice for getting more people involved in\n> enhancing submodule support, from a philosophical standpoint, I think 2.\n> is the more natural choice.\n\nI don't think \"getting more people involved in enhancing submodule\nsupport\" is a strong argument here. We should choose that policy\nwhich supports the development culture of the projects in question.\n"}]}