patchgit.el: Only show completions from refs/heads, refs/remotes and refs/tags

> Otherwise it will pick up e.g. lots of irrelevant stuff from
> refs/bisect, refs/stash or refs/patches (for StGit users).
>
> Signed-off-by: David Kågedal <davidk@lysator.liu.se>
> ---
>  contrib/emacs/git.el |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
> index feb229c..125e684 100644
> --- a/contrib/emacs/git.el
> +++ b/contrib/emacs/git.el
> @@ -1388,7 +1388,10 @@ With a prefix arg, diff the marked files instead."
>  (defun git-read-commit-name (prompt &optional default)
>    "Ask for a commit name, with completion for local branch, remote branch and tag."
>    (completing-read prompt
> -                   (list* "HEAD" "ORIG_HEAD" "FETCH_HEAD" (mapcar #'car (git-for-each-ref)))
> +                   (list* "HEAD" "ORIG_HEAD" "FETCH_HEAD"

> +                          (mapcar #'car (git-for-each-ref "refs/heads"
> +                                                          "refs/remotes"
> +                                                          "refs/tags")))
>  		   nil nil nil nil default))
>  
>  (defun git-checkout (branch &optional merge)

> David Kågedal <davidk@lysator.liu.se> writes:
>
>> Otherwise it will pick up e.g. lots of irrelevant stuff from
>> refs/bisect, refs/stash or refs/patches (for StGit users).
>>
>> Signed-off-by: David Kågedal <davidk@lysator.liu.se>
>> ---
>>  contrib/emacs/git.el |    5 ++++-
>>  1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
>> index feb229c..125e684 100644
>> --- a/contrib/emacs/git.el
>> +++ b/contrib/emacs/git.el
>> @@ -1388,7 +1388,10 @@ With a prefix arg, diff the marked files instead."
>>  (defun git-read-commit-name (prompt &optional default)
>>    "Ask for a commit name, with completion for local branch, remote branch and tag."
>>    (completing-read prompt
>> -                   (list* "HEAD" "ORIG_HEAD" "FETCH_HEAD" (mapcar #'car (git-for-each-ref)))
>> +                   (list* "HEAD" "ORIG_HEAD" "FETCH_HEAD"
>
> Sorry, I didn't check this properly. I thought I was fixing inside the
> git-checkout function, but this is git-read-commit-name which is used
> in more than one place.
>
> But for git-checkout, I would like to see a much shorter list of named
> commits, namely those that can be called "branches".

> Sorry, I didn't check this properly. I thought I was fixing inside the
> git-checkout function, but this is git-read-commit-name which is used
> in more than one place.
>
> But for git-checkout, I would like to see a much shorter list of named
> commits, namely those that can be called "branches". I'll come up with
> a better patch.

> David Kågedal <davidk@lysator.liu.se> writes:
>
>> Sorry, I didn't check this properly. I thought I was fixing inside the
>> git-checkout function, but this is git-read-commit-name which is used
>> in more than one place.
>>
>> But for git-checkout, I would like to see a much shorter list of named
>> commits, namely those that can be called "branches". I'll come up with
>> a better patch.
>
> I think it's reasonable to do this for the other uses of
> git-read-commit-name too, so your original patch looks OK.

> Alexandre Julliard <julliard@winehq.org> writes:
>
>> David Kågedal <davidk@lysator.liu.se> writes:
>>
>>> Sorry, I didn't check this properly. I thought I was fixing inside the
>>> git-checkout function, but this is git-read-commit-name which is used
>>> in more than one place.
>>>
>>> But for git-checkout, I would like to see a much shorter list of named
>>> commits, namely those that can be called "branches". I'll come up with
>>> a better patch.
>>
>> I think it's reasonable to do this for the other uses of
>> git-read-commit-name too, so your original patch looks OK.
>
> Actually, I'd like to go one step further. I'm only interested in
> branches, and only in branches I can commit to. So only asking for
> refs/heads seems the best solution.

> David Kågedal <davidk@lysator.liu.se> writes:
>
>> Alexandre Julliard <julliard@winehq.org> writes:
>>
>>> David Kågedal <davidk@lysator.liu.se> writes:
>>>
>>>> Sorry, I didn't check this properly. I thought I was fixing inside the
>>>> git-checkout function, but this is git-read-commit-name which is used
>>>> in more than one place.
>>>>
>>>> But for git-checkout, I would like to see a much shorter list of named
>>>> commits, namely those that can be called "branches". I'll come up with
>>>> a better patch.
>>>
>>> I think it's reasonable to do this for the other uses of
>>> git-read-commit-name too, so your original patch looks OK.
>>
>> Actually, I'd like to go one step further. I'm only interested in
>> branches, and only in branches I can commit to. So only asking for
>> refs/heads seems the best solution.
>
> I think that's going too far. It's useful to be able to checkout a tag,
> or to cherry-pick from a remote branch.

> Cherry-pick, yes. And checkout, sometimes. My problem is that I have a
> truckload of remote (svn) branches and that means I can't see the
> obvious checkout candidates for all the noise.
>
> But add "refs/remotes" and "refs/tags" to the last patch, and maybe we
> have a good compromise.

> Signed-off-by: David Kågedal <davidk@lysator.liu.se>
> ---
>
> Here is a version that can to both commit name lookup and branch name
> lookup, and with a configuration parameter that determines how to find
> branch names to complete on.

> David Kågedal <davidk@lysator.liu.se> writes:
>
>> Signed-off-by: David Kågedal <davidk@lysator.liu.se>
>> ---
>>
>> Here is a version that can to both commit name lookup and branch name
>> lookup, and with a configuration parameter that determines how to find
>> branch names to complete on.
>
> Why do you introduce a separate function for checkouts?  I don't see
> much need to have a different set of completions for checkout
> vs. cherry-pick, they both can be used with an arbitrary commit anyway.

> Yes, but the typical uses differ a lot. The (overwhelmingly) typical
> use of checkout is to switch to another branch. The typical use of
> cherry-pick is to pick any commit and not treat branch heads
> specially.
>
> So when switching branches, I obviously want a simple way to select
> which branch to switch to. When cherry-picking, I would need some
> simple way of picking any single commit, but that's hard so making it
> easy to pick any named commit is probably the reasonable solution.