reducing line crossings in gitk

At the moment, the commit graph that gitk draws always displays the parents of a merge in left-to-right order as they are listed in the commit (provided that none of the parents already has a line, i.e., is the parent of an previously drawn commit). That means that for the typical merge, the branch coming out to the right is the stuff that was pulled in by the merge.

That can lead to a later line crossing if an ancestor of the stuff being pulled in already has a line that is to the left of the merge. For an example of what I mean, look at the kernel repository with gitk at around commit 5ea6f2c33f0c8b126136dbf1776ffbc444772cd7 (Automatic merge of /spare/repo/netdev-2.6 branch natsemi).

I could add a heuristic to look for this case and reverse the order of the parents, which would reduce the line crossings and make the graph look neater. Would this be worth the slight loss of information (in that the stuff pulled in would no longer always be to the right)?

Paul.

PM> I could add a heuristic to look for this case and reverse the order of PM> the parents, which would reduce the line crossings and make the graph PM> look neater. Would this be worth the slight loss of information (in PM> that the stuff pulled in would no longer always be to the right)?

Personally I find the current "crossing lines" display makes what happened more visually obvious than "reverse order of the parents", so I'd be happier if you keep things as they are.

Thanks for a wonderful tool. May I ask for more? Some are minor UI enhancements, some are feature ideas.

 - The first time I tried it from somewhere random without
   having GIT_DIR environment, it just gave error and exited.
   Which is correct but could have been nicer.

   Adding a "Browse Repo" in the "File" menu to let the user
   switch which repository to browse (and when chosen start
   afresh, of course) would be nicer, while keeping the default
   of showing the current ${GIT_DIR:=.git} upon start-up.

 - What support from the core GIT side would you need if you
   wanted to let users browse a remote repo?  A way to inspect
   what is under ".git/refs/" hierarchy on the remote side?
   Anything else?

 - Pasting into the SHA1 field to "Go To" was a nuisance when
   the field already had a string in it.  Clearing the SHA1
   field when focus gets in would be one way to solve it, but
   then you would lose the way to pasting out of that field, so
   I do not know what to suggest offhand.

 - How do I "Find" backwards?  Not being able to find a way to
   do this was the most annoying thing for me.

 - After typing something in "Find" and hitting <ENTER>, if the
   focus stays in it and lets me hit <ENTER> again to go to the
   next one would be nicer.  Somehow hitting <ENTER> again would
   not do this for me right now.

 - Indicaing "Find" wrapping around without annoying the user
   too much (i.e. I do _not_ want you to add "Find reached the
   beginning of time, wrapping around and continuing from the
   top" pop-up window) would be nicer.  Currently I can tell by
   looking at the scrollbar on the history pane jumping back, so
   this is not a big issue, though.

 - Can I have a way to "Find" next commit that touches a given
   pathname?

    $ git-rev-list | git-diff-tree -s -r --stdin '<that pathname>'

   which would give you a sequence of lines that look like:
       "commit-SHA1 (from parent-commit-SHA1)"

   you would pick the commit-SHA1 from the output and jump to it.

 - In addition to "Find" which looks at the commit message, can I
   have one that uses pickaxe to find changes?

   Add a new choice "In Patch" to the list of choices ("All
   fields", etc); sorry, but currently pickaxe can only do exact
   matches.  When you are operating in that mode, run

    $ git-rev-list | git-diff-tree -s -r --stdin -S'<that string>'

   which would give you a sequence of lines that look like:
       "commit-SHA1 (from parent-commit-SHA1)"

   you would pick the commit-SHA1 from the output and jump to it.

 - Can I have an option to use diffcore options to tweak the
   diff that is shown in the lower-left pane?

   Add "Diff" menu next to "File" menu, and have the following
   options: "Find Renames", "Find Copies", "Find Rewrites".

   The first two are mutually exclusive so you can have (1) both
   off, (2) Renames, or (3) Copies.  "Rewrites" is independent,
   so you end up with 6 combinations.  Give "-M", "-C", and "-B"
   option to git-diff-tree you run on the commit when these
   "Find foo" options are in effect, respectively.

   A good test case in GIT repository itself to try these are:

    418aaf847a8b3ffffb4f777a2dd5262ca5ce0ef7 (for -M)
	This renames rpull.c to ssh-pull.c etc.  Four renames in
	total.

    7ef76925d9c19ef74874e1735e2436e56d0c4897 (for -C)
	This creates git-fetch-script out of git-pull-script
        by copying.

    6af1f0192ff8740fe77db7cf02c739ccfbdf119c (for -B)
	This rewrites ls-tree.c

This list is based on gitk-1.1 (I downloaded this morning) so you may already have unpublished solutions.

Junio C Hamano writes:

I would need git-rev-list, git-cat-file, and git-diff-tree to be able to operate on the remote repository.

I could rebind the middle mouse button to replace the contents of the sha1 field with the selection instead of inserting it.

The "?" key is bound to find backwards (i.e. select previous match) and the "/" key is bound to find forwards (select next match). I don't have a button for find backwards (and I'd rather not clutter it up by adding one, but maybe I could add a menu item for it).

Hmmm, if the focus stays in the find field then you can't use "?", up, down, etc. I could make <enter> do find-next if you like.

I could make it beep - how about that?

Interesting idea... I could add a "Path" entry to the find type menu.

Also interesting ideas, I'll see what I can do.

Regards, Paul.

Paul,

Another feature that would be handy is the ability to be able to create tags by pointing to an item and selecting a "create-tag" action. The effect would be to write the SHA1 id into GIT_DIR/refs/tags in the expected way.

Regards, 

jon.

Jon Seymour writes:

Hmmm, that would create a "direct" tag, not a normal tag, which is an object of type "tag" that contains a reference to a commit along with some other stuff.

In general I'd like to keep gitk as purely a viewer. Ultimately I'll probably do a graphical tool for checking stuff in and other operations that modify the repository as well, but I think that should be a separate tool.

Regards, Paul.

On 6/16/05, Paul Mackerras <paulus@samba.org> wrote:

Fair enough... the reason I suggested it is that I use gitk to help me decide how to merge stuff with the mainline. Currently I have to cut and paste the ids of the "interesting" commits into the command line. It would be nice to be able to point directly to an interesting commit and tag it so that I can later get to it from a command line using a name I can remember.

Still, I can quite accept that I have an idiosyncratic way of interacting with git and gitk.

jon.

Hi, Paul Mackerras wrote:

Yes.