new gitk feature

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.

On Wed, 2006-04-26 20:59:29 +1000, Paul Mackerras <paulus@samba.org> wrote:

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

MfG, JBG

On Wed, 26 Apr 2006, Paul Mackerras wrote:

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

Linus Torvalds writes:

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.

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.

On Fri, 28 Apr 2006, Paul Mackerras wrote:

Bold sounds good to me.

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