{"thread":{"id":"5861","subject":"gitk feature request..","startedAt":"2006-10-09T11:52:27Z","lastAt":"2006-11-11T17:42:42Z","messageCount":7,"participants":["Pierre Marc Dumuid","Marco Costalba","Pierre Dumuid","Junio C Hamano","Paul Mackerras","Petr Baudis","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"28453","messageId":"452A37FB.60507@adelaide.edu.au","threadId":"5861","inReplyTo":null,"subject":"gitk feature request..","fromName":"Pierre Marc Dumuid","fromEmail":"pierre.dumuid@adelaide.edu.au","sentAt":"2006-10-09T11:52:27Z","receivedAt":"2006-10-09T11:52:27Z","isPatch":false,"sender":{"key":"pierre.dumuid@adelaide.edu.au","avatar":null},"body":"Hi,\nI was adviced on the IRC channel to send my feature requests here...\n\nI have two feature requests:\n1. a bugzilla to place feature requests.\n2. All the stored \"views\" that can be created and placed under the \n\"view\" menu should be unique for each repository.\n\nCurrently I am starting to use git for a few projects, and I've found \nthat my named view list is growing.. too much. I think that there \nshould be a foluder in the .git directory that contains a list of the \nnamed views so that a person's menu isn't flooded with entries relating \nto different repositories..\n\nRegards,\nPierre\n"},{"id":"297028","messageId":"17745.1213.22769.420355@cargo.ozlabs.ibm.com","threadId":"5861","inReplyTo":"452A37FB.60507@adelaide.edu.au","subject":"Re: gitk feature request..","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2006-11-07T22:12:13Z","receivedAt":"2006-11-07T22:12:13Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Pierre Marc Dumuid writes:\n\n> I was adviced on the IRC channel to send my feature requests here...\n\nBest to cc me as well on gitk feature requests, since I don't always\nkeep up with the git mailing list very well.\n\n> I have two feature requests:\n> 1. a bugzilla to place feature requests.\n> 2. All the stored \"views\" that can be created and placed under the \n> \"view\" menu should be unique for each repository.\n\nGood idea. Junio, is there a canonical place under .git where gitk\nshould put such things?\n\n"},{"id":"295807","messageId":"7vslgu28do.fsf@assigned-by-dhcp.cox.net","threadId":"5861","inReplyTo":"17745.1213.22769.420355@cargo.ozlabs.ibm.com","subject":"Re: gitk feature request..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-07T22:34:59Z","receivedAt":"2006-11-07T22:34:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Mackerras writes:\n\n> Good idea. Junio, is there a canonical place under .git where gitk\n> should put such things?\n\nWell, we do not design things in advance but tend to let things\nevolve, which probably is a bad habit but I am not sure how else\nwe can avoid overdesigning before knowing the needs.\n\nThe existing state-keeping programs seem to keep their stuff\nimmediately under $GIT_DIR. Examples are:\n\n\t.git/description (gitweb)\n .git/cvs-authors (cvsimport)\n .git/gitcvs..sqlite (cvsserver)\n\nSo, .git/gitk- (or .git/gitk/) would be in line with\nothers. We _might_ want to have a standard plan to keep\nPorcelains stepping on each other's toes, and probably migrating\neverybody to .git/aux/{common,gitcvs,gitk,...}/ would be a\nsane thing to do. description and cvs-authors could probably be\nshared across Porcelains, so I do not think we mind leaving them\nin the current place or throw them in .git/aux/common/\n\nHaving said that, is the gitk view supposed to be shared across\nusers of a single repository?\n\nIf you imagine yourself logging into kernel.org (perhaps X\nforwarded over ssh to your local machine) and browsing\n/pub/scm/git/git.git/, the repository itself would not be\nwritable by you. Even if it were, I do not think you would want\nme to reuse the view you used from there next time I did the\nsame on the same repository.\n\nIt might make sense to give --state=dir/ parameter to gitk and\ntell it to use that directory to keep persistent data. Also I\nseem to recall you already have one file under $HOME/ to make\nwindow geometry or something persistent.\n\n\n\n"},{"id":"295481","messageId":"45511F8C.1060705@adelaide.edu.au","threadId":"5861","inReplyTo":"7vslgu28do.fsf@assigned-by-dhcp.cox.net","subject":"Re: gitk feature request..","fromName":"Pierre Dumuid","fromEmail":"pierre.dumuid@adelaide.edu.au","sentAt":"2006-11-08T00:06:36Z","receivedAt":"2006-11-08T00:06:36Z","isPatch":false,"sender":{"key":"pierre.dumuid@adelaide.edu.au","avatar":null},"body":"\n> Having said that, is the gitk view supposed to be shared across\n> users of a single repository?\n> \n\n> If you imagine yourself logging into kernel.org (perhaps X\n> forwarded over ssh to your local machine) and browsing\n> /pub/scm/git/git.git/, the repository itself would not be\n> writable by you. Even if it were, I do not think you would want\n> me to reuse the view you used from there next time I did the\n> same on the same repository.\n> \nI've mainly been thinking about users at a home who clone / update a \nremote repository and work in that repository for themselves. The idea \nof sshing into another machine seems to me not how git is designed to be \nused..\n\nAlso when one clones, I thought it cloned only the git repository, and \nnot the files for the porcelaines. (an example being the branches directory)\n> It might make sense to give --state=dir/ parameter to gitk and\n> tell it to use that directory to keep persistent data. Also I\n> seem to recall you already have one file under $HOME/ to make\n> window geometry or something persistent.\n> \nI use gitk a lot, and I'd rather not have to specify a command line \noption all the time, but an override from using the settings in the \nanother directory would be fine..\n\n\n\nbegin:vcard\nfn:Pierre Dumuid\nn:Dumuid;Pierre\norg:The University of Adelaide;Mechanical Engineering\nadr:;;;Adelaide;South Australia;5005;Australia\nemail;internet:pierre.dumuid@adelaide.edu.au\ntitle:Postgraduate Student\ntel;work:8303 3847\ntel;home:8388 5727\ntel;cell:0407570263\nnote:CRICOS Provider Number 00123M\nx-mozilla-html:TRUE\nurl:http://www.adelaide.edu.au\nversion:2.1\nend:vcard\n\n"},{"id":"294697","messageId":"e5bfff550611110708r1ad9559ewf35b8abaceb21cc4@mail.gmail.com","threadId":"5861","inReplyTo":"7vslgu28do.fsf@assigned-by-dhcp.cox.net","subject":"Re: gitk feature request..","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-11-11T15:08:22Z","receivedAt":"2006-11-11T15:08:22Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 11/7/06, Junio C Hamano wrote:\n\n>\n> Having said that, is the gitk view supposed to be shared across\n> users of a single repository?\n>\n\nPerhaps I misunderstand, but aren't gitk views a command line\narguments set for git-rev-list?\n\nCouldn't be defined as aliases and stored in .git/config? so to be\nused also with other git commands, as example git log...and of course\nother GUI tools ;-).\n\nIf I understand correctly the git documentation, aliases store both\nthe git command and the argument list. Perhaps for views the command\ncould be git-rev-parse.\n\nRegarding the local / private views problem, perhaps we could use a\nlocal, i.e. out of .git directory, config file that _extends_ and\n_overrides_ the repository config file.\n\nWhat I mean is that an alias, or also, in general, a config variable\ncould be searched by git, first in the local file, then if not found\nin the .git/config file.\n\nOf course the problem of per-repository _and_ private views stay open\n(we could use sub-sections identified by repo path in private .config\nfile???) but I think this is a more general and porcelain agnostic\napproach and could be better reused and extended.\n\n"},{"id":"298342","messageId":"ej4pll$vo9$1@sea.gmane.org","threadId":"5861","inReplyTo":"e5bfff550611110708r1ad9559ewf35b8abaceb21cc4@mail.gmail.com","subject":"Re: gitk feature request..","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-11T15:20:22Z","receivedAt":"2006-11-11T15:20:22Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Marco Costalba wrote:\n\n> Regarding the local / private views problem, perhaps we could use a\n> local, i.e. out of .git directory, config file that _extends_ and\n> _overrides_ the repository config file.\n\n~/.gitconfig ? Since quite a bit of time, undocumented.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"298014","messageId":"20061111174242.GB7201@pasky.or.cz","threadId":"5861","inReplyTo":"7vslgu28do.fsf@assigned-by-dhcp.cox.net","subject":"Re: gitk feature request..","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-11T17:42:42Z","receivedAt":"2006-11-11T17:42:42Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Nov 07, 2006 at 11:34:59PM CET, Junio C Hamano wrote:\n> Paul Mackerras writes:\n> \n> > Good idea. Junio, is there a canonical place under .git where gitk\n> > should put such things?\n> \n> Well, we do not design things in advance but tend to let things\n> evolve, which probably is a bad habit but I am not sure how else\n> we can avoid overdesigning before knowing the needs.\n> \n> The existing state-keeping programs seem to keep their stuff\n> immediately under $GIT_DIR. Examples are:\n> \n> \t.git/description (gitweb)\n> .git/cvs-authors (cvsimport)\n> .git/gitcvs..sqlite (cvsserver)\n> \n> So, .git/gitk- (or .git/gitk/) would be in line with\n> others. We _might_ want to have a standard plan to keep\n> Porcelains stepping on each other's toes, and probably migrating\n> everybody to .git/aux/{common,gitcvs,gitk,...}/ would be a\n> sane thing to do. description and cvs-authors could probably be\n> shared across Porcelains, so I do not think we mind leaving them\n> in the current place or throw them in .git/aux/common/\n\nI think the porcelains tend to use pretty specific names for their stuff\nand a risk of conflict is pretty small, so I don't think it's worth the\ncompatibility problems. Also, over time it's bound that qgit will\nsomething like start to peek and poke at some gitk stuff and learn about\nCVS imports so it'll peek at gitcvs as well, etc., so I'm not sure if\nthe net benefit would really be that large or rather give the porcelains\na false illusion of safety and privacy.\n\nExcept for cg-merge which is quite a pig when it comes to its state and\n.git files; I guess it should use a .git/cg-merge-state/ directory\ninstead. And the hooks space where cg sort of hoped that git would reuse\nits hooks names but it didn't play out.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i