Felipe Contreras <felipe.contre...@gmail.com> writes:

> There's no need to remove 'refs/heads/' yet again.
>
> Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com>
> ---
>  git-pull.sh | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/git-pull.sh b/git-pull.sh
> index f0df41c..3bdcbfd 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -166,7 +166,6 @@ error_on_no_merge_candidates () {
>               op_prep=with
>       fi
>  
> -     curr_branch=${curr_branch#refs/heads/}

The code assumes that at this point $curr_branch has the result of
git symbolic-ref -q HEAD it did at the beginning, before it entered
in the command line parsing loop.  But immediately after it, the
code sets up $curr_branch_short for the value this code computes.

>       upstream=$(git config "branch.$curr_branch.merge")
>       remote=$(git config "branch.$curr_branch.remote")

So it appears to me that the above two lines that are not updated
would introduce a regression.  Am I missing something trivial?

Puzzled.


> @@ -183,7 +182,7 @@ error_on_no_merge_candidates () {
>               echo "You asked to pull from the remote '$1', but did not 
> specify"
>               echo "a branch. Because this is not the default configured 
> remote"
>               echo "for your current branch, you must specify a branch on the 
> command line."
> -     elif [ -z "$curr_branch" -o -z "$upstream" ]; then
> +     elif [ -z "$curr_branch_short" -o -z "$upstream" ]; then

If $curr_branch in the original code was (wasn't) an empty string,
then with the updated code that does not strip refs/heads/ from the
beginning of it after applying the first hunk of this patch, the
variable is (isn't) an empty string, respectively. So there is no
need for this hunk, I think.

>               . git-parse-remote
>               error_on_missing_default_upstream "pull" $op_type $op_prep \
>                       "git pull <remote> <branch>"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to