Re: Gitk: shortcut to jump to the current HEAD (yellow spot)?

Dirk Süsserott [off-list ref] writes:

Hi!

Does anybody know about a shortcut in gitk to "jump to the yellow spot"?

I often use cmdline and gitk at the same time, switch branches, stash,
rebase and so on from bash. When hitting [Ctrl-]F5 in gitk, the last
highlighted commit is focused again and my HEAD is far off the screen.

Is there a way to jump to the HEAD (the yellow bubble in gitk) with a
fingertip?

TIA
   Dirk

Hit the Home key. The binding for that takes you to the first commit.
End to the last (oldest) commit.
-- 
Pat Thoyts                            http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD

Am 22.12.2011 19:26 schrieb Pat Thoyts:

Dirk Süsserott [off-list ref] writes:

quoted

Hi!

Does anybody know about a shortcut in gitk to "jump to the yellow spot"?

I often use cmdline and gitk at the same time, switch branches, stash,
rebase and so on from bash. When hitting [Ctrl-]F5 in gitk, the last
highlighted commit is focused again and my HEAD is far off the screen.

Is there a way to jump to the HEAD (the yellow bubble in gitk) with a
fingertip?

TIA
   Dirk

Hit the Home key. The binding for that takes you to the first commit.
End to the last (oldest) commit.

Hi Pat,

thank you, but I almost always run gitk with the '--all' parameter.
Actually, I have a function in my .bashrc for this:

  # calls gitk from the top-level directory:
  function gkup()
  {
      (cd "./$(git rev-parse --show-cdup)"; gitk --all "$@" &)
  }

That's because gitk behaves odd (at least to me) when not run from the
top-level directory. E.g. the "touching paths" box won't find files in
the top dir if you don't prefix them with a slash. It's all relative to
the directory gitk was started in. To get predictable behavior, I wrote
this function and garnished it with '--all'.

Thus, my current HEAD is not always on the top of the history but
somewhere in between. However, typing "HEAD" (or "head" in the SHA1
field works for me.

Cheers
    Dirk

2011/12/23 Dirk Süsserott [off-list ref]:

That's because gitk behaves odd (at least to me) when not run from the
top-level directory. E.g. the "touching paths" box won't find files in
the top dir if you don't prefix them with a slash.

This should be fixed in c332f44 (gitk: Fix file highlight when run in
subdirectory, 2011-04-04), which is in the current master and thus, I
believe, to be released in Git 1.7.9.

Martin

Am 24.12.2011 05:22 schrieb Martin von Zweigbergk:

2011/12/23 Dirk Süsserott [off-list ref]:

quoted

That's because gitk behaves odd (at least to me) when not run from the
top-level directory. E.g. the "touching paths" box won't find files in
the top dir if you don't prefix them with a slash.

This should be fixed in c332f44 (gitk: Fix file highlight when run in
subdirectory, 2011-04-04), which is in the current master and thus, I
believe, to be released in Git 1.7.9.

Martin

Ahh, cool. I wouldn't have noticed because I'm so used to my "cd $TOP &&
gitk". I thought it was by intention because it just behaves like "git
log": When run from subdirs it doesn't know about topdir files: Assume
README.txt is in the topdir and current dir is some subdir:

$ git log -- README.txt    # fails
$ git log -- ../README.txt # works

My alias (or function) was just a helper to avoid remembering where I
started gitk from.

Cheers,
    Dirk

BTW, Merry X-Mas to you and all others on the list :-)