Re: [PATCH] Make rebase smarter

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 26, 2007, 21:02 UTC
Message-ID: <7vk5p9wpwd.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <1193373682-3608-1-git-send-email-stevenrwalter@gmail.com>

Steven Walter <stevenrwalter@gmail.com> writes:

> It is a common workflow to run "git fetch; git rebase origin/<foo>" Where
> foo is the remote tracking branch.  git-rebase should default to using
> the remote tracking branch if no other ref is given.

This would be a reasonable choice between refusing outright and picking one possible action. I do not have a strong preference as to what that "one possible action" should be, but if people like to base on the remote tracking branch set to merge by default, I am fine with it.

Show 11 quoted lines

> +	curr_branch=$(git symbolic-ref -q HEAD)
> +	curr_branch=${curr_branch//refs\/heads\//}
> +	merge=$(git config branch.$curr_branch.merge)
> +	remote=$(git config branch.$curr_branch.remote)
> +	fetch=$(git config remote.$remote.fetch)
> +
> +	expanded=$(git fetch--tool expand-refs-wildcard "0000000000000000000000000000000000000000 $merge" "$remote" "$fetch")
> +	upstream_name=${expanded/#*:/}
> +fi
>  upstream=`git rev-parse --verify "${upstream_name}^0"` ||
>      die "invalid upstream $upstream_name"

 * How does this work if there is no such tracking configuration?

   - branch.<curr>.merge may be missing;
   - branch.<curr>.remote may be missing;
   - remote.<remote>.fetch may be explicit, multiple and/or non-wildcard;

 * ${parameter/pattern/string} is a bashism we do not allow in
   git scripts.

Problems in the implementation aside, it probably makes sense to first have a helper function that takes a local branch name and computes the remote tracking branch that a given local branch is set to merge from, if exists, and use it here. I suspect there are other places in the Porcelain that would benefit from such a helper function.