[PATCH] __git_recent_commits: prefer recent commit objects

[PATCH] __git_recent_commits: prefer recent commit objects

[Daniel Hahler]

From: Daniel Hahler <git@thequod.de>

Without this "commit to be amended" shows up before "recent commit object
name" with `git commit --fixup`, but the recent commit objects are the
most useful here.

RFC: Daniel Shahaf mentioned that `expl=()` might not be right here after all,
so I am waiting for feedback before pushing it.
---
 Completion/Unix/Command/_git | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index 85aac9264..a46e3b55d 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -6326,11 +6326,11 @@ __git_recent_commits () {
   ret=1
   # Resetting expl to avoid it 'leaking' from one line to the next.
   expl=()
+  _describe -V -t commits 'recent commit object name' descr && ret=0
+  expl=()
   _wanted commit-tags expl 'commit tag' compadd "$@" -a - tags && ret=0
   expl=()
   _wanted heads expl 'head' compadd "$@" -a - heads && ret=0
-  expl=()
-  _describe -V -t commits 'recent commit object name' descr && ret=0
   return $ret
 }
 
-- 
2.12.2

Re: [PATCH] __git_recent_commits: prefer recent commit objects

[Daniel Shahaf]

Daniel Hahler wrote on Sun, Apr 09, 2017 at 17:23:35 +0200:
> RFC: Daniel Shahaf mentioned that `expl=()` might not be right here after all,
> so I am waiting for feedback before pushing it.

I don't think fixing that needs to block this patch.  I suggest that,
whether the expl=() is right or not, to go ahead with this patch, since
it doesn't make things any worse in that front and does fix your issue;
and if the expl=() is wrong, we can fix it in a separate patch.

Re: [PATCH] __git_recent_commits: prefer recent commit objects

[Bart Schaefer]

On Apr 9,  5:23pm, Daniel Hahler wrote:
}
} RFC: Daniel Shahaf mentioned that `expl=()` might not be right here after all,
} so I am waiting for feedback before pushing it.

expl isn't used by _describe so there's no reason to reset it both before
and after that call, and it's local to __git_recent_commits so there's
also no reason to reset it before the first time it's passed to _wanted.
I'm not certain whether it's necessary to reset it between _wanted calls,
though it typically will have been assigned a value by the first one.