reducing line crossings in gitk

reducing line crossings in gitk

[Paul Mackerras]

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.

Re: reducing line crossings in gitk

[Junio C Hamano]

>>>>> "PM" == Paul Mackerras <paulus@samba.org> writes:

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.

Re: reducing line crossings in gitk

[Matthias Urlichs]

Hi, Paul Mackerras wrote:

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

Yes.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
All interesting actions are overdetermined. -- Arthur D. Hlavaty

Re: reducing line crossings in gitk

[Paul Mackerras]

Junio C Hamano writes:

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

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

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

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

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

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

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

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.

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

I could make it beep - how about that?

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

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

>  - In addition to "Find" which looks at the commit message, can I
>    have one that uses pickaxe to find changes?
> 
>  - Can I have an option to use diffcore options to tweak the
>    diff that is shown in the lower-left pane?

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

Regards,
Paul.

Re: reducing line crossings in gitk

[Jon Seymour]

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.

Re: reducing line crossings in gitk

[Paul Mackerras]

Jon Seymour writes:

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

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.

Re: reducing line crossings in gitk

[Jon Seymour]

On 6/16/05, Paul Mackerras <paulus@samba.org> wrote:
> Jon Seymour writes:
> 
> > 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.
> 
> 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.
> 

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.
-- 
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/