gitk feature request

gitk feature request

[H. Peter Anvin]

It would be really nice to be able to select a set of commits in gitk 
and write out a patch from one to the other -- just a wrapper arount 
git-diff.

	-hpa

gitk feature request..

[Pierre Marc Dumuid]

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

Re: gitk feature request..

[Paul Mackerras]

Pierre Marc Dumuid writes:

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

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

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

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

Re: gitk feature request..

[Junio C Hamano]

Paul Mackerras <paulus@samba.org> writes:

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

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.

Re: gitk feature request..

[Pierre Dumuid]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]


> 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.
>   
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)
> 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 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..


[-- Attachment #2: pierre.dumuid.vcf --]
[-- Type: text/x-vcard, Size: 385 bytes --]

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

Re: gitk feature request..

[Marco Costalba]

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

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

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.

Re: gitk feature request..

[Jakub Narebski]

Marco Costalba wrote:

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

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

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: gitk feature request..

[Petr Baudis]

On Tue, Nov 07, 2006 at 11:34:59PM CET, Junio C Hamano wrote:
> Paul Mackerras <paulus@samba.org> writes:
> 
> > Good idea.  Junio, is there a canonical place under .git where gitk
> > should put such things?
> 
> 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/

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.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1