A new way to get a sha1?

A new way to get a sha1?

[Thomas Badie]

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 

Re: A new way to get a sha1?

[Jan Engelhardt]

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

Re: A new way to get a sha1?

[Junio C Hamano]

Jan Engelhardt <jengelh@inai.de> writes:

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

Also,

	git show -s ':/^t1100-.*: Fix an interm'

would work well.  It your log messages are not descriptive enough,
however, that may not, but that is easily fixable by training you
and your colleages to give a more descriptive title to each commit,
which will make your project better.

Re: A new way to get a sha1?

[Thomas Badie]

2012/7/30 Junio C Hamano <gitster@pobox.com>:
> Jan Engelhardt <jengelh@inai.de> writes:
>
>> 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.
>
> Also,
>
>         git show -s ':/^t1100-.*: Fix an interm'
>
> would work well.  It your log messages are not descriptive enough,
> however, that may not, but that is easily fixable by training you
> and your colleages to give a more descriptive title to each commit,
> which will make your project better.

Another aim of this module would be to avoid writing the beginning of
the commit message.

Thanks for your proposition. I didn't know this solution.

-- 
Thomas "Enki" Badie

Re: A new way to get a sha1?

[Martin Langhoff]

On Mon, Jul 30, 2012 at 11:45 AM, Junio C Hamano <gitster@pobox.com> wrote:
>         git show -s ':/^t1100-.*: Fix an interm'

That doesn't work for me (git 1.7.10.4 as per Fedora 18 rpms) in
git.git. But the idea is sound -- git can give you the sha1 trivially.
You don't need additional glue.

But any ref definition can be turned into a sha1 with this snippet:

    git show --pretty=format:%H HEAD

If you want to get the last 10 sha1s, use the same "pretty" with git log

   git log --pretty=format:%H HEAD | head

This is all predicated on passing the info to something else. For git
commands, you can always use the rich ref notation git supports.

cheers,


m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

Re: A new way to get a sha1?

[Junio C Hamano]

Martin Langhoff <martin.langhoff@gmail.com> writes:

> On Mon, Jul 30, 2012 at 11:45 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>         git show -s ':/^t1100-.*: Fix an interm'
>
> That doesn't work for me (git 1.7.10.4 as per Fedora 18 rpms) in
> git.git. But the idea is sound -- git can give you the sha1 trivially.
> You don't need additional glue.

The idea was that you do not have to give abbreviated SHA-1 to Git
in the first place.

What doesn't work?  My copy of v1.7.10.1 seems to grok the above
just fine.

Re: A new way to get a sha1?

[Martin Langhoff]

On Mon, Jul 30, 2012 at 2:29 PM, Junio C Hamano <gitster@pobox.com> wrote:
> The idea was that you do not have to give abbreviated SHA-1 to Git
> in the first place.

Ah, sorry, I didn't get _that_ point. I thought you were trying to
demo a way to get a sha1.

> What doesn't work?  My copy of v1.7.10.1 seems to grok the above
> just fine.

Gaah, it barfed at first, works now. My apologies. I may have
mishandled the copy to the terminal -- dropped or corrupted the
single-quotes.

cheers,


m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

Re: A new way to get a sha1?

[Andreas Schwab]

Martin Langhoff <martin.langhoff@gmail.com> writes:

> But any ref definition can be turned into a sha1 with this snippet:
>
>     git show --pretty=format:%H HEAD

      git rev-parse HEAD

> If you want to get the last 10 sha1s, use the same "pretty" with git log
>
>    git log --pretty=format:%H HEAD | head

     git rev-list -n 10 HEAD

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: A new way to get a sha1?

[Thomas Badie]

2012/7/30 Jan Engelhardt <jengelh@inai.de>:
> 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

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

Re: A new way to get a sha1?

[Jeff King]

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

Re: A new way to get a sha1?

[Thomas Badie]

2012/7/30 Jeff King <peff@peff.net>:
> 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.

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

Re: A new way to get a sha1?

[Andreas Schwab]

Thomas Badie <thomas.badie@gmail.com> writes:

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

If you use emacs anyway you could run the shell inside it, giving you
all the power of cut-and-paste.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: A new way to get a sha1?

[Sitaram Chamarty]

On Mon, Jul 30, 2012 at 5:41 PM, Thomas Badie <thomas.badie@gmail.com> 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.

Re: A new way to get a sha1?

[Thomas Badie]

2012/7/30 Sitaram Chamarty <sitaramc@gmail.com>:
> On Mon, Jul 30, 2012 at 5:41 PM, Thomas Badie <thomas.badie@gmail.com> 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.

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

Re: A new way to get a sha1?

[Thomas Rast]

Thomas Badie <thomas.badie@gmail.com> writes:

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

I think this is too specific.  If you want full interactivity, use a
real interactive tool like tig.

However, your post and some quick searching gave me another idea.  Bash
actually has features to let you edit the current command line from
within key bindings.  So if only we had some clever utility, let's call
it lineselect for lack of a better name, that let us do

  git log --oneline <args> | lineselect

then we could paste the selected SHA1 into the command line.  That would
be really neat, wouldn't it?

I haven't found such a utility, so below is my first shot at making
something useful.  It has:

* a few keybinds that should make most people happy
* color rendering (yay), but because of issues with the default
  rendering, it sets white-on-black by default
* an optional regex arg to select only parts of the lines

Things that notably _don't_ work yet:

* cursor keys (I have no idea why it doesn't match KEY_UP etc.)
* ANSI attributes (colors work, of sorts)
* Searching the next occurrence of a search string

But you can probably guess that those aren't a huge problem for me.

I made a little repo too, for all your forking needs:

  https://github.com/trast/lineselect.git
  git://github.com/trast/lineselect.git

Thanks for the idea :-)


------ 8< ------
#!/usr/bin/perl

use warnings;
use strict;
use Curses;

my @lines;

open my $input, "<&STDIN" or die "Can't dup STDIN: $!";
open my $output, ">&STDOUT" or die "Can't dup STDOUT: $!";
open STDIN, "<", "/dev/tty" or die "Can't open TTY (in): $!";
open STDOUT, ">", "/dev/tty" or die "Can't open TTY (out): $!";

my $eof = -1;

sub read_more {
	my $n = $_[0];
	if ($eof > 0) {
		return;
	}
	while ($n >= scalar @lines) {
		my $read = <$input>;
		if (!defined $read) {
			$eof = scalar @lines;
			return;
		}
		push @lines, $read;
	}
}

my $pat;
my ($rows, $cols);
my $sel = 0;

my $top = 0;

my $cmdline = ":";

my $fg = 7;
my $bg = 0;
sub set_color {
	attron(COLOR_PAIR(1+$fg+8*$bg));
}

sub print_color_line {
	my $line = $_[0];
	my $remain = $cols;
	$fg = 7;
	$bg = 0;
	set_color;
	while ($line =~ m{^([^\e]*)\e\[([^m]*)m(.*)}) {
		printw($1);
		$remain -= length $1;
		$line = $3;
		if ($2 eq "") {
			$fg = 7;
			$bg = 0;
			set_color;
		} else {
			for my $c (split /;/, $2) {
				if (30 <= $c and $c < 38) {
					$fg = $c - 30;
				} elsif (40 <= $c and $c < 48) {
					$bg = $c - 30;
				}
			}
			set_color;
		}
	}
	printw($line);
	$remain -= length $line;
	if ($remain > 0) {
		printw(" "x$remain);
	}
}

sub redraw {
	read_more $top+$rows-1;
	clear;
	attron(COLOR_PAIR(8));
	for my $i (0..$rows-2) {
		if ($top+$i == $sel) {
			attron(A_STANDOUT);
		} else {
			attroff(A_STANDOUT);
		}
		move($i, 0);
		print_color_line($lines[$top+$i]);
	}
	move($rows-1, 0);
	attron(COLOR_PAIR(8));
	attron(A_STANDOUT);
	printw($cmdline);
	attroff(A_STANDOUT);
	refresh();
}

sub adjust_view {
	if ($sel < 0) {
		return;
	} elsif ($sel >= $top+$rows-1) {
		$top = $sel-$rows+2;
	} elsif ($sel < $top) {
		$top = $sel;
	}
}

sub forward;
sub backward {
	my $n = $_[0];
	$sel -= $n;
	while (defined $pat and $lines[$sel] !~ m{$pat}) {
		$sel--;
		read_more $sel;
		if ($sel < 0) {
			$sel = 0;
			forward 0;
			return;
		}
	}
	if ($sel < 0) {
		$sel = 0;
	}
	adjust_view;
}

sub forward {
	my $n = $_[0];
	$sel += $n;
	while (defined $pat and $lines[$sel] !~ m{$pat}) {
		$sel++;
		read_more $sel;
		if ($eof > 0 and $sel >= $eof) {
			$sel = $eof-1;
			backward 0;
			return;
		}
	}
	adjust_view;
}

sub search {
	my $start = $sel;
	my $search_str = "";
	while (1) {
		$sel = $start;
		my $case_sens = ($search_str ne lc $search_str);
		while (1) {
			if ($eof > 0 and $sel >= $eof) {
				$sel = -1;
				last;
			}
			if (defined $pat and $lines[$sel] !~ m{$pat}) {
				$sel++;
				read_more $sel;
				next;
			}
			if ($case_sens and $lines[$sel] =~ m{$search_str}) {
				last;
			}
			if (!$case_sens and $lines[$sel] =~ m{$search_str}i) {
				last;
			}
			$sel++;
			read_more $sel;
		}
		adjust_view;
		$cmdline = "/" . $search_str;
		$cmdline = "NO MATCH -- " . $cmdline if $sel < 0;
		redraw;
		my $c = getch();
		if ($c eq "\b" or $c eq "\x7f") {
			$search_str = substr $search_str, 0, length($search_str)-1;
		} elsif ($c eq "\n") {
			$sel = $start if $sel < 0;
			return;
		} elsif ($c eq "\033") {
			$sel = $start;
			return;
		} else {
			$search_str .= $c;
		}
	}
}

sub mainloop {
	while (1) {
		getmaxyx($rows, $cols);
		$cmdline = ":";
		redraw;
		my $c = getch();
		if ($c eq " ") {
			$sel += $rows-1;
			read_more $sel;
			$sel = $eof-1 if $eof > 0 and $sel > $eof;
			adjust_view;
		} elsif ($c eq "q") {
			return;
		} elsif ($c eq KEY_ENTER or $c eq "\n") {
			return $lines[$sel];
		} elsif ($c eq "n" or $c eq "j" or $c eq KEY_DOWN) {
			forward 1;
		} elsif ($c eq "p" or $c eq "k" or $c eq KEY_UP) {
			backward 1;
		} elsif ($c eq "/" or $c eq "f") {
			search;
		} elsif ($c eq "<" or $c eq KEY_HOME) {
			$sel = 0;
			adjust_view;
		} elsif ($c eq ">" or $c eq KEY_END) {
			while ($eof < 0) {
				$sel++;
				read_more $sel;
			}
			$sel = $eof-1;
			adjust_view;
		}
	}
}

if (0 < scalar @ARGV) {
	$pat = $ARGV[0];
}

initscr;
start_color;
for my $f (0..7) {
	for my $b (0..7) {
		init_pair(1+$f+8*$b,$f,$b);
	}
}
my $r = mainloop;
endwin;
if (defined $r) {
	$r =~ s{\e\[([^m]*)m}{}g;
	if (defined $pat) {
		$r =~ m/$pat/;
		$r = $1;
		die "BUG: should never get here" if (!defined $r);
	}
	print $output "$r";
} else {
	exit 1;
}

Re: A new way to get a sha1?

[Thomas Badie]

2012/7/30 Thomas Rast <trast@student.ethz.ch>:
> Thomas Badie <thomas.badie@gmail.com> writes:
>
>> 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.
>
> I think this is too specific.  If you want full interactivity, use a
> real interactive tool like tig.

Second suggestion for tig. I must definitely try it.

> However, your post and some quick searching gave me another idea.  Bash
> actually has features to let you edit the current command line from
> within key bindings.  So if only we had some clever utility, let's call
> it lineselect for lack of a better name, that let us do
>
>   git log --oneline <args> | lineselect
>
> then we could paste the selected SHA1 into the command line.  That would
> be really neat, wouldn't it?
>
> I haven't found such a utility, so below is my first shot at making
> something useful.  It has:
>
> * a few keybinds that should make most people happy
> * color rendering (yay), but because of issues with the default
>   rendering, it sets white-on-black by default
> * an optional regex arg to select only parts of the lines

Very interesting. I tried it and it is nice. I fix a little bug ("Use of
uninitialized...") on my fork. I will take a look on the things that
don't work yet ;) I'm pretty sure that there is a lot of possible
usage of this script.

> Things that notably _don't_ work yet:
>
> * cursor keys (I have no idea why it doesn't match KEY_UP etc.)
> * ANSI attributes (colors work, of sorts)
> * Searching the next occurrence of a search string
>
> But you can probably guess that those aren't a huge problem for me.
>
> I made a little repo too, for all your forking needs:
>
>   https://github.com/trast/lineselect.git
>   git://github.com/trast/lineselect.git

Thanks for sharing it!

> Thanks for the idea :-)

You're very welcome!

-- 
Thomas "Enki" Badie