A new way to get a sha1?

Hi all,

When I should fixup or squash a commit, I nearly never
remember how to get the sha1 of the commit I want to fixup.
Because sometimes HEAD~n is not enough, I make `git log`,
copy the sha1 of the right commit and paste it in my git
fixup command. So I wrote a perl script to avoid the usage
of the mouse. And after discussion with some of my friends,
this can be generalized as a generic command line interface
tool to get a sha1.

The idea is to have a perl module which run through
the log history and print 10 shortlog associated with a number
from 0 to 9, and a message below "Select commit [| 0, 9 |] or
next row ?" or this kind of message with several options.

So I ask to the community if this module is interesting for git.
It can be integrated everywhere a sha1 is requested (git rebase,
git reset, ...). IMHO, it can be an enhancement.

So, what is your opinion? Should I make this script a perl module
and integrate it in git, or should I just keep it in my own script
toolbox?

Thanks for reading and answering,

-- 
Thomas "Enki" Badie 

On Monday 2012-07-30 14:11, Thomas Badie wrote:

Hi all,

When I should fixup or squash a commit, I nearly never
remember how to get the sha1 of the commit I want to fixup.
Because sometimes HEAD~n is not enough, I make `git log`,
copy the sha1 of the right commit and paste it in my git
fixup command. So I wrote a perl script to avoid the usage
of the mouse.

If you use screen(1), you can use the keyboard as well; it offers ^A [ 
and ^A ] for copy, and then paste. tmux and all those screen clones 
probably have something similar. Maybe ratpoison-like WMs do as well.
Or, you can use `git log --oneline`, look for the commit and then
type the (usually) 6-char part of the hash manually, which may be faster 
than ^A[, moving the cursor to the copy position, marking it, etc.

So, what is your opinion?

IMO, I thus never needed an extra tool to find and specify the hash for 
`git re -i hash^`..

my ¥2

On Mon, Jul 30, 2012 at 5:41 PM, Thomas Badie [off-list ref] wrote:

Hi all,

When I should fixup or squash a commit, I nearly never
remember how to get the sha1 of the commit I want to fixup.
Because sometimes HEAD~n is not enough, I make `git log`,
copy the sha1 of the right commit and paste it in my git
fixup command. So I wrote a perl script to avoid the usage
of the mouse. And after discussion with some of my friends,
this can be generalized as a generic command line interface
tool to get a sha1.

The idea is to have a perl module which run through
the log history and print 10 shortlog associated with a number
from 0 to 9, and a message below "Select commit [| 0, 9 |] or
next row ?" or this kind of message with several options.

In general, I prefer nothing to be *interactive*, so I would vote an
emphatic no.

Also, try "tig" and see if you can customise it.  For example, in
order to create a new commit that is meant to be a fixup of some other
commit, I 'git add' what is needed (either command line or tig again)
then hit "m" to the main window, scroll down to the commit concerned,
and hit "=".

That "=" comes from this line in ~/.tigrc:

    bind    main            =   !git commit --fixup=%(commit)

Please use such methods to keep interactivity where it belongs, is my opinion.

2012/7/30 Jan Engelhardt [off-list ref]:

On Monday 2012-07-30 14:11, Thomas Badie wrote:

quoted

Hi all,

When I should fixup or squash a commit, I nearly never
remember how to get the sha1 of the commit I want to fixup.
Because sometimes HEAD~n is not enough, I make `git log`,
copy the sha1 of the right commit and paste it in my git
fixup command. So I wrote a perl script to avoid the usage
of the mouse.

If you use screen(1), you can use the keyboard as well; it offers ^A [
and ^A ] for copy, and then paste. tmux and all those screen clones
probably have something similar. Maybe ratpoison-like WMs do as well.
Or, you can use `git log --oneline`, look for the commit and then
type the (usually) 6-char part of the hash manually, which may be faster
than ^A[, moving the cursor to the copy position, marking it, etc.

quoted

So, what is your opinion?

IMO, I thus never needed an extra tool to find and specify the hash for
`git re -i hash^`..

my ¥2

I understand your opinion. My solution was a easier way to make your
proposition about `git log --oneline`, because I don't want to copy these
6 numbers by hand. I'd prefer select the right line simply.

My solution is intended for people who just use git, and whatever their
environment (Unix, Windows...) because all is contained in git.

But I clearly agree that there is a lot of other solutions by using external
tools.  But IMHO, it is preferable that I just have to add a `-i' to a command
to make this choice simply, and not having to use my WM for this kind of task.

My real proposal is to integrate this way of choice into git instead of having
to use external tools, or writting the part of the sha1 by hand.

Thanks for answering, your answer confirms that this kind of tools is really
not wanted by everyone.

I will take a look at screen, it can be useful for a lot of thing. Thanks for
your advice.

-- 
Thomas "Enki" Badie

2012/7/30 Sitaram Chamarty [off-list ref]:

On Mon, Jul 30, 2012 at 5:41 PM, Thomas Badie [off-list ref] wrote:

quoted

Hi all,

When I should fixup or squash a commit, I nearly never
remember how to get the sha1 of the commit I want to fixup.
Because sometimes HEAD~n is not enough, I make `git log`,
copy the sha1 of the right commit and paste it in my git
fixup command. So I wrote a perl script to avoid the usage
of the mouse. And after discussion with some of my friends,
this can be generalized as a generic command line interface
tool to get a sha1.

The idea is to have a perl module which run through
the log history and print 10 shortlog associated with a number
from 0 to 9, and a message below "Select commit [| 0, 9 |] or
next row ?" or this kind of message with several options.

In general, I prefer nothing to be *interactive*, so I would vote an
emphatic no.

I can understand this. But maybe this is not the case of everyone. People
on this mailing-list are developers for several years I think, and this kind of
tools may not be helpful for them because they have their own habits. When
I decide to propose this, I mostly think about people who are not allergic to
interactive tools (this allergy is highly understandable, I just say
there is a lot
of taste in the world). So maybe it could be an enhancement for git, maybe not.

Also, try "tig" and see if you can customise it.  For example, in
order to create a new commit that is meant to be a fixup of some other
commit, I 'git add' what is needed (either command line or tig again)
then hit "m" to the main window, scroll down to the commit concerned,
and hit "=".

That "=" comes from this line in ~/.tigrc:

    bind    main            =   !git commit --fixup=%(commit)

Please use such methods to keep interactivity where it belongs, is my opinion.

I already heard about "tig" without trying it. I'll try it as soon as possible.
Thanks for your answer.

-- 
Thomas "Enki" Badie

On Mon, Jul 30, 2012 at 06:40:12PM +0200, Thomas Badie wrote:

I understand your opinion. My solution was a easier way to make your
proposition about `git log --oneline`, because I don't want to copy these
6 numbers by hand. I'd prefer select the right line simply.

My solution is intended for people who just use git, and whatever their
environment (Unix, Windows...) because all is contained in git.

But I clearly agree that there is a lot of other solutions by using external
tools.  But IMHO, it is preferable that I just have to add a `-i' to a command
to make this choice simply, and not having to use my WM for this kind of task.

I am pretty mouse-averse, and I find a nice solution to these sorts of
interactive-selection problems is to use your editor. In its most basic
form, something like:

  git log --oneline >tmp
  $EDITOR tmp ;# and delete everything you don't want
  git cherry-pick `cat tmp`

assuming you are proficient with your editor, finding the entry you want
and deleting all of the unwanted lines should be just a few keystrokes.
And you can simplify it with a script like this:

  $ cat `which vpipe`
  #!/bin/sh
  trap 'rm -f $tmp' 0
  tmp=`mktemp vpipe-XXXXXX` &&
  cat >$tmp &&
  ${EDITOR:-vi} $tmp </dev/tty >/dev/tty &&
  cat $tmp

which you can then use like:

  git cherry-pick `git log | vpipe`

I know that sort of thing is not for everyone (you have to really like
your editor), but I thought I'd share in case it is useful.

-Peff

2012/7/30 Jeff King [off-list ref]:

On Mon, Jul 30, 2012 at 06:40:12PM +0200, Thomas Badie wrote:

quoted

I understand your opinion. My solution was a easier way to make your
proposition about `git log --oneline`, because I don't want to copy these
6 numbers by hand. I'd prefer select the right line simply.

My solution is intended for people who just use git, and whatever their
environment (Unix, Windows...) because all is contained in git.

But I clearly agree that there is a lot of other solutions by using external
tools.  But IMHO, it is preferable that I just have to add a `-i' to a command
to make this choice simply, and not having to use my WM for this kind of task.

I am pretty mouse-averse, and I find a nice solution to these sorts of
interactive-selection problems is to use your editor. In its most basic
form, something like:

  git log --oneline >tmp
  $EDITOR tmp ;# and delete everything you don't want
  git cherry-pick `cat tmp`

assuming you are proficient with your editor, finding the entry you want
and deleting all of the unwanted lines should be just a few keystrokes.
And you can simplify it with a script like this:

  $ cat `which vpipe`
  #!/bin/sh
  trap 'rm -f $tmp' 0
  tmp=`mktemp vpipe-XXXXXX` &&
  cat >$tmp &&
  ${EDITOR:-vi} $tmp </dev/tty >/dev/tty &&
  cat $tmp

which you can then use like:

  git cherry-pick `git log | vpipe`

I know that sort of thing is not for everyone (you have to really like
your editor), but I thought I'd share in case it is useful.

For this case, I don't think I'll use it, but it shows how to use the editor
in a replacement of an interactive tool, and it is interesting. I'd change
vi for emacs but this is religious. I never though using my editor this way,
and maybe one day it will be useful.

Thanks for your answer.

-- 
Thomas Badie