gitk feature request..

Hi, I was adviced on the IRC channel to send my feature requests here...

I have two feature requests:
1. a bugzilla to place feature requests.
2. All the stored "views" that can be created and placed under the 
"view" menu should be unique for each repository.

Currently I am starting to use git for a few projects, and I've found that my named view list is growing.. too much. I think that there should be a foluder in the .git directory that contains a list of the named views so that a person's menu isn't flooded with entries relating to different repositories..

Regards, Pierre

Pierre Marc Dumuid writes:

Best to cc me as well on gitk feature requests, since I don't always keep up with the git mailing list very well.

Good idea. Junio, is there a canonical place under .git where gitk should put such things?

Paul Mackerras <paulus@samba.org> writes:

Well, we do not design things in advance but tend to let things evolve, which probably is a bad habit but I am not sure how else we can avoid overdesigning before knowing the needs.

The existing state-keeping programs seem to keep their stuff immediately under $GIT_DIR. Examples are:

	.git/description (gitweb)
        .git/cvs-authors (cvsimport)
        .git/gitcvs.<branch>.sqlite (cvsserver)

So, .git/gitk-<foo> (or .git/gitk/<bar>) would be in line with others. We _might_ want to have a standard plan to keep Porcelains stepping on each other's toes, and probably migrating everybody to .git/aux/{common,gitcvs,gitk,...}/<foo> would be a sane thing to do. description and cvs-authors could probably be shared across Porcelains, so I do not think we mind leaving them in the current place or throw them in .git/aux/common/

Having said that, is the gitk view supposed to be shared across users of a single repository?

If you imagine yourself logging into kernel.org (perhaps X forwarded over ssh to your local machine) and browsing /pub/scm/git/git.git/, the repository itself would not be writable by you. Even if it were, I do not think you would want me to reuse the view you used from there next time I did the same on the same repository.

It might make sense to give --state=dir/ parameter to gitk and tell it to use that directory to keep persistent data. Also I seem to recall you already have one file under $HOME/ to make window geometry or something persistent.

I've mainly been thinking about users at a home who clone / update a remote repository and work in that repository for themselves. The idea of sshing into another machine seems to me not how git is designed to be used..

Also when one clones, I thought it cloned only the git repository, and not the files for the porcelaines. (an example being the branches directory)

I use gitk a lot, and I'd rather not have to specify a command line option all the time, but an override from using the settings in the another directory would be fine..

begin:vcard fn:Pierre Dumuid n:Dumuid;Pierre org:The University of Adelaide;Mechanical Engineering adr:;;;Adelaide;South Australia;5005;Australia email;internet:pierre.dumuid@adelaide.edu.au title:Postgraduate Student tel;work:8303 3847 tel;home:8388 5727 tel;cell:0407570263 note:CRICOS Provider Number 00123M x-mozilla-html:TRUE url:http://www.adelaide.edu.au version:2.1 end:vcard

On 11/7/06, Junio C Hamano <junkio@cox.net> wrote:

Perhaps I misunderstand, but aren't gitk views a command line arguments set for git-rev-list?

Couldn't be defined as aliases and stored in .git/config? so to be used also with other git commands, as example git log...and of course other GUI tools ;-).

If I understand correctly the git documentation, aliases store both the git command and the argument list. Perhaps for views the command could be git-rev-parse.

Regarding the local / private views problem, perhaps we could use a local, i.e. out of .git directory, config file that _extends_ and _overrides_ the repository config file.

What I mean is that an alias, or also, in general, a config variable could be searched by git, first in the local file, then if not found in the .git/config file.

Of course the problem of per-repository _and_ private views stay open (we could use sub-sections identified by repo path in private .config file???) but I think this is a more general and porcelain agnostic approach and could be better reused and extended.

Marco Costalba wrote:

~/.gitconfig ? Since quite a bit of time, undocumented.

On Tue, Nov 07, 2006 at 11:34:59PM CET, Junio C Hamano wrote:

I think the porcelains tend to use pretty specific names for their stuff and a risk of conflict is pretty small, so I don't think it's worth the compatibility problems. Also, over time it's bound that qgit will something like start to peek and poke at some gitk stuff and learn about CVS imports so it'll peek at gitcvs as well, etc., so I'm not sure if the net benefit would really be that large or rather give the porcelains a false illusion of safety and privacy.

Except for cg-merge which is quite a pig when it comes to its state and .git files; I guess it should use a .git/cg-merge-state/ directory instead. And the hooks space where cg sort of hoped that git would reuse its hooks names but it didn't play out.