new gitk feature

new gitk feature

[Paul Mackerras]

I just pushed some changes to gitk which add a new feature, the
ability to have multiple "views" of a repository.  Each view is a
subgraph of the full graph.  At the moment the only subgraph that you
can specify is the subgraph containing the commits that affect a
specified set of files or directories.  You can switch between views
quickly, and if the currently selected commit exists in the new view
when you switch views, it is selected in the new view.  There is one
view which always exists, the "All files" view.  If files or
directories are specified on the command line, a "Command line" view
is automatically created and selected at startup.

Thus, for the kernel repository I can have a "PPC" view which shows
changes to arch/powerpc, include/asm-powerpc etc.  When looking at a
commit in that view, I can switch to the "All files" view to see where
that commit fits in the overall history.

There is a "View" menu which contains the menu items for creating,
deleting, editing and selecting views.  If you check the "Remember
this view" box, gitk will write the definition of the view to your
~/.gitk file, and it will be automatically put in the list on startup.

I plan to add various other kinds of views, for example, a view that
shows only the commits that affect a selected file (or part of a file,
perhaps), and a view that shows just the current commit together with
all the commits that have tags.  (The latter will require some help
from git-rev-list. :)

Paul.

Re: new gitk feature

[Jan-Benedict Glaw]

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

On Wed, 2006-04-26 20:59:29 +1000, Paul Mackerras <paulus@samba.org> wrote:
> Thus, for the kernel repository I can have a "PPC" view which shows
> changes to arch/powerpc, include/asm-powerpc etc.  When looking at a
> commit in that view, I can switch to the "All files" view to see where
> that commit fits in the overall history.

Hmm.. Neat feature for arch maintainers. An easy way to see what's
happening in the i386 tree for example :)

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: new gitk feature

[Linus Torvalds]

On Wed, 26 Apr 2006, Paul Mackerras wrote:
>
> I just pushed some changes to gitk which add a new feature, the
> ability to have multiple "views" of a repository.  Each view is a
> subgraph of the full graph.  At the moment the only subgraph that you
> can specify is the subgraph containing the commits that affect a
> specified set of files or directories.  You can switch between views
> quickly, and if the currently selected commit exists in the new view
> when you switch views, it is selected in the new view.

This gets close to something I wanted, but at the same time falls very 
short of it because the views are always shown completely disjoint.

I've wanted for a long time to have a way to _highlight_ commits. That's 
actually very much a "view" thing, but it's a mode where you really see 
one view, but the commits that exist in another view have a different 
color (or have the commits that _don't_ exist in the other view be grayed 
out).

I hope that your new "view" thing would support this notion too: instead 
of having to totally switch between view, it would be wonderful if you 
could have one "master view" and then use another view to "highlight".

Also, I think revision information should be part of a view. For example, 
in the "highlight" case, I'd love to have the "main view" be the default 
"everything", and then have some way to _highlight_ the view that is 
defined by the revision pattern "v1.3.1.."

Any possibility of something light that? I'd _love_ to be able to see the 
whole tree, but with things that touch certain files or things that are 
newer highlighted.

(Btw, the "revision information" is also cool things like "--unpacked". I 
actually use "gitk --unpacked" every once in a while, just because it's 
such a cool way to say "show me everything I've added since I packed the 
repo last).

			Linus

Re: new gitk feature

[Paul Mackerras]

Linus Torvalds writes:

> Any possibility of something light that? I'd _love_ to be able to see the 
> whole tree, but with things that touch certain files or things that are 
> newer highlighted.

That should be quite doable.  How about I show the commits that are in
the highlight view in bold?  That won't conflict with the existing
yellow background for commits that match the find criteria.

> (Btw, the "revision information" is also cool things like "--unpacked". I 
> actually use "gitk --unpacked" every once in a while, just because it's 
> such a cool way to say "show me everything I've added since I packed the 
> repo last).

OK, I didn't know about --unpacked. :)  I plan to add stuff to the
view definition window to allow you to select commits to
include/exclude by reachability from given commits (by head/tag/ID)
and when I do I can add a way to say --unpacked too.

Paul.

Re: new gitk feature

[Linus Torvalds]

On Fri, 28 Apr 2006, Paul Mackerras wrote:
> Linus Torvalds writes:
> > Any possibility of something light that? I'd _love_ to be able to see the 
> > whole tree, but with things that touch certain files or things that are 
> > newer highlighted.
> 
> That should be quite doable.  How about I show the commits that are in
> the highlight view in bold?  That won't conflict with the existing
> yellow background for commits that match the find criteria.

Bold sounds good to me.

> > (Btw, the "revision information" is also cool things like "--unpacked". I 
> > actually use "gitk --unpacked" every once in a while, just because it's 
> > such a cool way to say "show me everything I've added since I packed the 
> > repo last).
> 
> OK, I didn't know about --unpacked. :)  I plan to add stuff to the
> view definition window to allow you to select commits to
> include/exclude by reachability from given commits (by head/tag/ID)
> and when I do I can add a way to say --unpacked too.

It's more of a gimmick, but I find myself using it occasionally just to 
decide whether it's time to repack. It falls out automatically - not 
because I thought I'd ever want it, but because the --unpacked semantics 
for git-rev-list are what incremental packing needed.

(Of course, sane people probably just do "git count-objects" to decide to 
repack).

		Linus