[PATCH 0/2] [GIT PULL] ktest: A couple of fixes

[PATCH 0/2] [GIT PULL] ktest: A couple of fixes

[Steven Rostedt]

Linus,

This includes two fixes, one of which seems to have fell under your
radar before:

 http://groups.google.com/group/linux.kernel/browse_thread/thread/b0a0880f3e0f415a/188f12ab40b7a6c9?show_docid=188f12ab40b7a6c9

But that's fine, as I pulled in Russ's patch after merging your tree,
and it did not do a fast forward of your tree. I didn't notices that
it did that, and it seemed a bit strange to do a commit for a fast
forward.

Is git set up to not fast forward by default? (I need to give it another try)

Anyway, changed my tree to be a fast forward (you haven't pulled it
yet, so no harm done with a rebase), and I added another fix.

New signed tag.

Please pull the latest ktest-for-v3.4-rc5 tree, which can be found at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-ktest.git
ktest-for-v3.4-rc5

Head SHA1: b66786c7ff4441f0b9ac3b05f8e62cad75df65ff


Russ Dill (1):
      ktest.pl: Fix combined usage of BISECT_REVERSE and BISECT_SKIP

Steven Rostedt (1):
      ktest: Fix reboot on success stopping all reboots

----
 tools/testing/ktest/ktest.pl |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

[PATCH 1/2] ktest.pl: Fix combined usage of BISECT_REVERSE and BISECT_SKIP

[Steven Rostedt]

[-- Attachment #1: 0001-ktest.pl-Fix-combined-usage-of-BISECT_REVERSE-and-BI.patch --]
[-- Type: text/plain, Size: 1063 bytes --]

From: Russ Dill <Russ.Dill@ti.com>

When BISECT_REVERSE and BISECT_SKIP are used together with boot or test
testing, build failures are treated as boot or test failures and
'git bisect bad' is executed instead of 'git bisect skip'. This is because
the $ret value of -1 is treated as a build failure, but the $reverse_bisect
logic does not properly handle this.

Simple fix, only invert it if it is positive.

Link: http://lkml.kernel.org/r/1335235380-8509-1-git-send-email-Russ.Dill@ti.com

Signed-off-by: Russ Dill <Russ.Dill@ti.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
 tools/testing/ktest/ktest.pl |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index 95d6a6f..d2ede59 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -2192,7 +2192,7 @@ sub run_bisect {
     }
 
     # Are we looking for where it worked, not failed?
-    if ($reverse_bisect) {
+    if ($reverse_bisect && $ret >= 0) {
 	$ret = !$ret;
     }
 
-- 
1.7.9.5

[PATCH 2/2] ktest: Fix reboot on success stopping all reboots

[Steven Rostedt]

[-- Attachment #1: 0002-ktest-Fix-reboot-on-success-stopping-all-reboots.patch --]
[-- Type: text/plain, Size: 1975 bytes --]

From: Steven Rostedt <srostedt@redhat.com>

The change to let individual tests decide to reboot the machine on
success of the entire test also prevented errors from rebooting
when an error was detected.

The "no_reboot" variable was only cleared if the test had
reboot_on_success set. But the no_reboot variable also prevents the test
rebooting when an error was detected even when REBOOT_ON_ERROR was set.

Add a new "reboot_success" variable that is used to determine if the
test should reboot on success and not touch the no_reboot variable.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
 tools/testing/ktest/ktest.pl |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index d2ede59..4915408 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -183,6 +183,9 @@ my %force_config;
 # do not force reboots on config problems
 my $no_reboot = 1;
 
+# reboot on success
+my $reboot_success = 0;
+
 my %option_map = (
     "MACHINE"			=> \$machine,
     "SSH_USER"			=> \$ssh_user,
@@ -3469,6 +3472,7 @@ for (my $i = 1; $i <= $opt{"NUM_TESTS"}; $i++) {
 
     # Do not reboot on failing test options
     $no_reboot = 1;
+    $reboot_success = 0;
 
     $iteration = $i;
 
@@ -3554,9 +3558,11 @@ for (my $i = 1; $i <= $opt{"NUM_TESTS"}; $i++) {
 	    die "failed to checkout $checkout";
     }
 
+    $no_reboot = 0;
+
     # A test may opt to not reboot the box
     if ($reboot_on_success) {
-	$no_reboot = 0;
+	$reboot_success = 1;
     }
 
     if ($test_type eq "bisect") {
@@ -3600,7 +3606,7 @@ for (my $i = 1; $i <= $opt{"NUM_TESTS"}; $i++) {
 
 if ($opt{"POWEROFF_ON_SUCCESS"}) {
     halt;
-} elsif ($opt{"REBOOT_ON_SUCCESS"} && !do_not_reboot) {
+} elsif ($opt{"REBOOT_ON_SUCCESS"} && !do_not_reboot && $reboot_success) {
     reboot_to_good;
 } elsif (defined($switch_to_good)) {
     # still need to get to the good kernel
-- 
1.7.9.5

Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes

[Linus Torvalds]

On Tue, May 1, 2012 at 5:44 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> Is git set up to not fast forward by default? (I need to give it another try)

Git will fast-forward by default if you do a pull and there is no
development of your own in your tree.

There are two exceptions:

 - you explicitly say that you don't want to fast-forward (--no-ff or
"[merge] ff=false" in the git config file)

 - if you pull a signed tag with a modern version of git.

That second case may be what you hit.

If you do a

  git pull linus v3.4-rc5

in order to just update to the state of my latest tag, then git will
assume you want to do a new commit (and thus a non-fast-forward) just
so that git can record the tag signature in the commit.

The sad part is that I don't think you can even override the second
case. IOW, I think even "git pull --ff linus v3.4-rc5" will still do a
non-fast-forward merge.

That's inconvenient, and an unintended consequence of the behavior I
wanted as a top-level maintainer. But I really do think it's wrong for
normal developers who might validly just want to update to some
particular tagged release.

Junio? Any ideas?

                           Linus

Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

Hi Linus,

On Tue, 1 May 2012 19:58:46 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> The sad part is that I don't think you can even override the second
> case. IOW, I think even "git pull --ff linus v3.4-rc5" will still do a
> non-fast-forward merge.

git merge v3.4-rc5^{commit}

works, but that doesn't work for "git pull" :-(  I tend to "fetch and
merge" rather than pull ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> If you do a
>
>   git pull linus v3.4-rc5
>
> in order to just update to the state of my latest tag, then git will
> assume you want to do a new commit (and thus a non-fast-forward) just
> so that git can record the tag signature in the commit.
>
> The sad part is that I don't think you can even override the second
> case.
> ...
> That's inconvenient, and an unintended consequence of the behavior I
> wanted as a top-level maintainer. But I really do think it's wrong for
> normal developers who might validly just want to update to some
> particular tagged release.
>
> Junio? Any ideas?

"Ideas" meaning "recipe to do with deployed binaries"?

When a normal developer wants to _reset to_ a particular tagged release,
in order to _start_ new work, she wouldn't be doing even the above "git
pull linus v3.4-rc5".  That will contaminate the result with whatever
random stuff she happened to have on the current branch.  A more natural
sequence would be "git fetch --tags linus" followed by either

        git checkout v3.4-rc5 ;# to detach

or

        git checkout -b mywork v3.4-rc5 ;# to start

So the case to "reset to" is not very interesting.

But when a normal developer wants to _sync to_ a particular tagged
release, in order to _continue_ working on her topic, she would need to
have a merge (unless she does not have _anything_ herself), and at that
point, merging v3.4-rc5 vs v3.4-rc5^0 would not make that much of a
difference.  If she absolutely detests the "mergetag" header, she could do
a "git fetch --tags linus" followed by

	git merge v3.4-rc5^0

which admittedly is two more letters than she used to type.

If you mean by "Ideas" for additional features, obviously the last step
could be enhanced to use a more intuitive command line that requires the
user to type even more, i.e.

	git merge --ff v3.4-rc5

Once that is done, "git pull --ff linus v3.4-rc5" would fall out as a
logical consequence.

But obviously these two would need new code ;-)

Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes

[Steven Rostedt]

[-- Attachment #1: Type: text/plain, Size: 3194 bytes --]

On Tue, 2012-05-01 at 20:49 -0700, Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 

> When a normal developer wants to _reset to_ a particular tagged release,
> in order to _start_ new work, she wouldn't be doing even the above "git
> pull linus v3.4-rc5".  That will contaminate the result with whatever
> random stuff she happened to have on the current branch.  A more natural
> sequence would be "git fetch --tags linus" followed by either
> 
>         git checkout v3.4-rc5 ;# to detach

The problem is, I like to know what has been pulled into mainline. I
have patches in quilt (for ktest only, not for my other work) and will
start adding them on a "clean" release. By doing a git pull (or fetch
and merge), I like to see the fast forward to know if everything that's
in my current branch has been pulled. If it hasn't, then something may
have been missed.

> 
> or
> 
>         git checkout -b mywork v3.4-rc5 ;# to start

But then I would end up with several branches that would require
deleting. One way I could see myself in handling this case would be to
delete the current branch and start again (thinking that everything was
already pulled). But by doing that, if something wasn't pulled in, then
I would have lost those changes without ever knowing.

> 
> So the case to "reset to" is not very interesting.
> 
> But when a normal developer wants to _sync to_ a particular tagged
> release, in order to _continue_ working on her topic, she would need to
> have a merge (unless she does not have _anything_ herself), and at that
> point, merging v3.4-rc5 vs v3.4-rc5^0 would not make that much of a
> difference.  If she absolutely detests the "mergetag" header, she could do
> a "git fetch --tags linus" followed by
> 
> 	git merge v3.4-rc5^0
> 
> which admittedly is two more letters than she used to type.

This would fit into my workflow. Thus I could use this.

> 
> If you mean by "Ideas" for additional features, obviously the last step
> could be enhanced to use a more intuitive command line that requires the
> user to type even more, i.e.
> 
> 	git merge --ff v3.4-rc5
> 
> Once that is done, "git pull --ff linus v3.4-rc5" would fall out as a
> logical consequence.
> 
> But obviously these two would need new code ;-)

The -ff would make sense as it seems to be the logical thing a user
would want. If they specify the fast-forward flag, then the user would
expect the merge to be a fast forward if possible.

BTW, is there a git compare type option. That is, I like to compare two
separate branches with the result that one currently gets with git when
a branch is following another branch. When you check out that branch, it
gives you an update on how those two branches are related (is one a fast
forward of the other, are they off by different commits?). It would be
nice if git could do this with any two branches. I wrote a script to do
this for me (attached) but it would be nice if git had it natively.

$ git-branch-status v3.0.4 v3.0.5              
Branch v3.0.4 can be fast forward to v3.0.5 in 240 commits

$ git-branch-status v3.0.4 v3.1  
Branch v3.0.4 and v3.1
differ by 257 and 9380 commit(s) respectively


-- Steve

[-- Attachment #2: git-branch-status --]
[-- Type: application/x-shellscript, Size: 679 bytes --]

Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes

[Junio C Hamano]

Steven Rostedt <rostedt@goodmis.org> writes:

> On Tue, 2012-05-01 at 20:49 -0700, Junio C Hamano wrote:
>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>> 
>
>> When a normal developer wants to _reset to_ a particular tagged release,...
>
> The problem is,...
> But then I would end up with ...

[comments on the part I declared "uninteresting" snipped]

>> So the case to "reset to" is not very interesting.

>> But when a normal developer wants to _sync to_ a particular tagged
>> release, in order to _continue_ working on her topic, she would need to
>> have a merge (unless she does not have _anything_ herself), and at that
>> point, merging v3.4-rc5 vs v3.4-rc5^0 would not make that much of a
>> difference.  If she absolutely detests the "mergetag" header, she could do
>> a "git fetch --tags linus" followed by
>> 
>> 	git merge v3.4-rc5^0
>> 
>> which admittedly is two more letters than she used to type.
>
> This would fit into my workflow. Thus I could use this.

OK.

>> If you mean by "Ideas" for additional features, obviously the last step
>> could be enhanced to use a more intuitive command line that requires the
>> user to type even more, i.e.
>> 
>> 	git merge --ff v3.4-rc5
>> 
>> Once that is done, "git pull --ff linus v3.4-rc5" would fall out as a
>> logical consequence.
>> 
>> But obviously these two would need new code ;-)
>
> The -ff would make sense as it seems to be the logical thing a user
> would want. If they specify the fast-forward flag, then the user would
> expect the merge to be a fast forward if possible.

OK.  Sounds like a good janitor project we could try to find a volunteer
on ;-).

> BTW, is there a git compare type option. That is, I like to compare two
> separate branches with the result that one currently gets with git when
> a branch is following another branch. When you check out that branch, it
> gives you an update on how those two branches are related (is one a fast
> forward of the other, are they off by different commits?). It would be
> nice if git could do this with any two branches. I wrote a script to do
> this for me (attached) but it would be nice if git had it natively.
>
> $ git-branch-status v3.0.4 v3.0.5              
> Branch v3.0.4 can be fast forward to v3.0.5 in 240 commits
>
> $ git-branch-status v3.0.4 v3.1  
> Branch v3.0.4 and v3.1
> differ by 257 and 9380 commit(s) respectively

I personally do not think "257 and 9380" vs "15 and 400" totally
uninteresting, in the sense that the absolute numbers do not matter much,
and the only question that matter is "Is everything in this one included
in the other?" and I just say "git lgf master..topic" (where I have in my
$HOME/.gitconfig "[alias] lgf = log --oneline --boundary --first-parent"
defined) to see the list of commits on a topic, with the indication of
where the topic forked from.  Obviously it takes the "never merge mainline
into topics" discipline for it to be useful.

I also use "git show-branch $A $B $C..." for something like this but that
is only useful when these branches are known to have only a handful of
commits on their own, and its output is not very suited if they have
hundreds of commits.

Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes

[Steven Rostedt]

[-- Attachment #1: Type: text/plain, Size: 5292 bytes --]

On Wed, 2012-05-02 at 13:14 -0700, Junio C Hamano wrote:
> Steven Rostedt <rostedt@goodmis.org> writes:
> 
> > On Tue, 2012-05-01 at 20:49 -0700, Junio C Hamano wrote:
> >> Linus Torvalds <torvalds@linux-foundation.org> writes:
> >> 
> >
> >> When a normal developer wants to _reset to_ a particular tagged release,...
> >
> > The problem is,...
> > But then I would end up with ...
> 
> [comments on the part I declared "uninteresting" snipped]

Just have to snip it, you don't need to declare it uninteresting.


> > $ git-branch-status v3.0.4 v3.0.5              
> > Branch v3.0.4 can be fast forward to v3.0.5 in 240 commits
> >
> > $ git-branch-status v3.0.4 v3.1  
> > Branch v3.0.4 and v3.1
> > differ by 257 and 9380 commit(s) respectively
> 
> I personally do not think "257 and 9380" vs "15 and 400" totally
> uninteresting, in the sense that the absolute numbers do not matter much,

I disagree here. Maybe it's because of the example I used. Here's a more
appropriate one:

I usually work against the tip.git tree for my kernel work (not ktest),
and I have several branches for different things I work on. I
periodically rebase against the latest tip branch to make sure
everything works (these development branches are only local to my own
machines, not public). Sometimes I forget what I pushed forward and
where I left off. I'll make a branch off of another branch's commit and
push that, and continue developing. But I rebase the new stuff and test
it before pushing it again. So I have something like this:

$ git-branch-status tip/perf/core
Branch HEAD and tip/perf/core
differ by 15 and 644 commit(s) respectively

Here it shows that this branch has 15 patches that are pending. I'll
usually rebase against tip/perf/core, run a bunch of tests, and then
push it out when ready.

I'll continue to work on this branch and add more patches. But because
other people may add things to tip/perf/core that affect me, I need to
rebase once in a while. But I also check to see if the previous push was
in, and I use my script git-branch-status on a daily basis. Lets me know
what patches I need to look at. Maybe it's not that important, but I
find it useful in my everyday workflow.

> and the only question that matter is "Is everything in this one included
> in the other?" and I just say "git lgf master..topic" (where I have in my
> $HOME/.gitconfig "[alias] lgf = log --oneline --boundary --first-parent"
> defined) to see the list of commits on a topic, with the indication of
> where the topic forked from.  Obviously it takes the "never merge mainline
> into topics" discipline for it to be useful.
> 
> I also use "git show-branch $A $B $C..." for something like this but that
> is only useful when these branches are known to have only a handful of
> commits on their own, and its output is not very suited if they have
> hundreds of commits.


If I'm the only one that finds this feature useful, then I'm happy with
just using my script. It works well and I have it on all my boxes. I
just wanted to show others in case I'm not the only one that finds this
information useful.

I just thought it would be easy to implement as git already does this
check. I liked what I saw from git that I based my output of this script
on it. In fact, I just saw it today:

$ git checkout trace/rfc/tracing/fentry
Switched to branch 'trace/rfc/tracing/fentry'
Your branch and 'ftrace/rfc/tracing/fentry' have diverged,
and have 65913 and 4 different commit(s) each, respectively.


I'll throw in one more feature request, that you can take or leave (I
have another script for it ;-), something that does a listing of
branches in order of date. I have over a hundred branches in my repo,
and I forget which branch was the last one I was working on. So I
created a script called git-ls (attached).

Here's what the output looks like:

$ git-ls | tail
681d1c4    2012-04-19    trace/tip/perf/urgent                         tracing: Fix stacktrace of latency tracers (irqsoff and friends)
59cfede    2012-04-19    trace/rfc/iolatency                           tracing: Add iolatency tracer
61463fa    2012-04-24    trace/tip/perf/core                           ftrace/x86: Remove the complex ftrace NMI handling code
e201738    2012-04-26    trace/tip/perf/core-2                         ftrace/x86: Remove the complex ftrace NMI handling code
053cef1    2012-04-27    trace/rfc/tracing/fentry                      ftrace/x86: Add support for -mfentry to x86_64
4a6d70c    2012-04-27    trace/tip/perf/core-3                         ftrace/x86: Remove the complex ftrace NMI handling code
a76c3eb    2012-04-30    trace/rfc/kprobes/ftrace                      ftrace/x86: Add support for x86_32 to pass pt_regs to function tracer
6e1b77e    2012-05-02    trace/rfc/kprobes/ftrace-v2                   kprobes: Update header for ftrace optimization
a4cc5f1    2012-05-02    trace/tip/perf/next-2                         ftrace/x86: Add separate function to save regs
9bd8569    2012-05-02    trace/tip/perf/next                           trace: Make removal of ring buffer pages atomic

It lists the branches in order of date of last commit.

Again, just showing some things that I find useful. If no one else finds
these interesting, then just ignore it. I have my scripts :-)

-- Steve


[-- Attachment #2: git-ls --]
[-- Type: application/x-perl, Size: 819 bytes --]

Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes

[Jakub Narebski]

Steven Rostedt <rostedt@goodmis.org> writes:

> I'll throw in one more feature request, that you can take or leave (I
> have another script for it ;-), something that does a listing of
> branches in order of date. I have over a hundred branches in my repo,
> and I forget which branch was the last one I was working on. So I
> created a script called git-ls (attached).
> 
> Here's what the output looks like:
> 
> $ git-ls | tail
> 681d1c4    2012-04-19    trace/tip/perf/urgent                         tracing: Fix stacktrace of latency tracers (irqsoff and friends)
> 59cfede    2012-04-19    trace/rfc/iolatency                           tracing: Add iolatency tracer
> 61463fa    2012-04-24    trace/tip/perf/core                           ftrace/x86: Remove the complex ftrace NMI handling code
> e201738    2012-04-26    trace/tip/perf/core-2                         ftrace/x86: Remove the complex ftrace NMI handling code
> 053cef1    2012-04-27    trace/rfc/tracing/fentry                      ftrace/x86: Add support for -mfentry to x86_64
> 4a6d70c    2012-04-27    trace/tip/perf/core-3                         ftrace/x86: Remove the complex ftrace NMI handling code
> a76c3eb    2012-04-30    trace/rfc/kprobes/ftrace                      ftrace/x86: Add support for x86_32 to pass pt_regs to function tracer
> 6e1b77e    2012-05-02    trace/rfc/kprobes/ftrace-v2                   kprobes: Update header for ftrace optimization
> a4cc5f1    2012-05-02    trace/tip/perf/next-2                         ftrace/x86: Add separate function to save regs
> 9bd8569    2012-05-02    trace/tip/perf/next                           trace: Make removal of ring buffer pages atomic
> 
> It lists the branches in order of date of last commit.
> 
> Again, just showing some things that I find useful. If no one else finds
> these interesting, then just ignore it. I have my scripts :-)

Well, there is "git branch -v -v":

  $ git branch -v -v
  [...]
    gsoc2012-wiki                  0e71ecb [gsoc2012/wiki/master: ahead 11, behind 4] '"Published" and "secret" commits' project
    html                           8b94cd8 Autogenerated HTML docs for v1.7.7.1-488-ge8e1c
    i18n-po.pl                     aa8ce2e [git-i18n/ab/i18n-po: ahead 1] po/pl.po: Eliminate fuzzy translations
    maint                          bf50515 Git 1.7.10.1
  [...]
    t/doc-config-extraction        451c2ef [git/trast/t/doc-config-extraction-v2: ahead 2257, behind 3] Documentation: complete config list from other manpages
    test                           b77178e gitweb: Separate features with no project specific override
    todo                           10c7888 Meta/dodoc: assign default values
    user-manual                    4c22f3d Comments to user-manual (WIP)


I guess that git-for-each-ref could be extended with behind / ahead
information, perhaps as modifiers to existing %(upstream) field...

P.S. I would associate "git ls" with listing worktree files.

-- 
Jakub Narebski

Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes

[Steven Rostedt]

On Wed, 2012-05-02 at 17:33 -0700, Jakub Narebski wrote:
> Steven Rostedt <rostedt@goodmis.org> writes:

> Well, there is "git branch -v -v":
> 
>   $ git branch -v -v
>   [...]
>     gsoc2012-wiki                  0e71ecb [gsoc2012/wiki/master: ahead 11, behind 4] '"Published" and "secret" commits' project
>     html                           8b94cd8 Autogenerated HTML docs for v1.7.7.1-488-ge8e1c
>     i18n-po.pl                     aa8ce2e [git-i18n/ab/i18n-po: ahead 1] po/pl.po: Eliminate fuzzy translations
>     maint                          bf50515 Git 1.7.10.1
>   [...]
>     t/doc-config-extraction        451c2ef [git/trast/t/doc-config-extraction-v2: ahead 2257, behind 3] Documentation: complete config list from other manpages
>     test                           b77178e gitweb: Separate features with no project specific override
>     todo                           10c7888 Meta/dodoc: assign default values
>     user-manual                    4c22f3d Comments to user-manual (WIP)
> 
> 
> I guess that git-for-each-ref could be extended with behind / ahead
> information, perhaps as modifiers to existing %(upstream) field...

Would that list them in order then? Also, having the date printed is
useful, as I sometimes remember the approximate date a I worked on
something.


> 
> P.S. I would associate "git ls" with listing worktree files.
> 

Yeah, I agree. I just wanted a script that had a short and easy name ;-)

git branch-sort

would probably be a better name.

Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes

[Nguyen Thai Ngoc Duy]

On Thu, May 3, 2012 at 7:33 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Steven Rostedt <rostedt@goodmis.org> writes:
>
>> I'll throw in one more feature request, that you can take or leave (I
>> have another script for it ;-), something that does a listing of
>> branches in order of date. I have over a hundred branches in my repo,
>> and I forget which branch was the last one I was working on. So I
>> created a script called git-ls (attached).
>>
>> Here's what the output looks like:
>>
>> $ git-ls | tail
>> 681d1c4    2012-04-19    trace/tip/perf/urgent                         tracing: Fix stacktrace of latency tracers (irqsoff and friends)
>> 59cfede    2012-04-19    trace/rfc/iolatency                           tracing: Add iolatency tracer
>> 61463fa    2012-04-24    trace/tip/perf/core                           ftrace/x86: Remove the complex ftrace NMI handling code
>> e201738    2012-04-26    trace/tip/perf/core-2                         ftrace/x86: Remove the complex ftrace NMI handling code
>> 053cef1    2012-04-27    trace/rfc/tracing/fentry                      ftrace/x86: Add support for -mfentry to x86_64
>> 4a6d70c    2012-04-27    trace/tip/perf/core-3                         ftrace/x86: Remove the complex ftrace NMI handling code
>> a76c3eb    2012-04-30    trace/rfc/kprobes/ftrace                      ftrace/x86: Add support for x86_32 to pass pt_regs to function tracer
>> 6e1b77e    2012-05-02    trace/rfc/kprobes/ftrace-v2                   kprobes: Update header for ftrace optimization
>> a4cc5f1    2012-05-02    trace/tip/perf/next-2                         ftrace/x86: Add separate function to save regs
>> 9bd8569    2012-05-02    trace/tip/perf/next                           trace: Make removal of ring buffer pages atomic
>>
>> It lists the branches in order of date of last commit.
>>
>> Again, just showing some things that I find useful. If no one else finds
>> these interesting, then just ignore it. I have my scripts :-)
>
> Well, there is "git branch -v -v":
>
>  $ git branch -v -v
>  [...]
>    gsoc2012-wiki                  0e71ecb [gsoc2012/wiki/master: ahead 11, behind 4] '"Published" and "secret" commits' project
>    html                           8b94cd8 Autogenerated HTML docs for v1.7.7.1-488-ge8e1c
>    i18n-po.pl                     aa8ce2e [git-i18n/ab/i18n-po: ahead 1] po/pl.po: Eliminate fuzzy translations
>    maint                          bf50515 Git 1.7.10.1
>  [...]
>    t/doc-config-extraction        451c2ef [git/trast/t/doc-config-extraction-v2: ahead 2257, behind 3] Documentation: complete config list from other manpages
>    test                           b77178e gitweb: Separate features with no project specific override
>    todo                           10c7888 Meta/dodoc: assign default values
>    user-manual                    4c22f3d Comments to user-manual (WIP)
>
>
> I guess that git-for-each-ref could be extended with behind / ahead
> information, perhaps as modifiers to existing %(upstream) field...

There's also a patch that adds sorting support to "git branch":

http://thread.gmane.org/gmane.comp.version-control.git/188705
-- 
Duy