Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx> writes:
> diff --git a/git-rebase.sh b/git-rebase.sh
> index 5abfeac..1bc0c29 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh
> @@ -466,6 +466,19 @@ esac
>
> require_clean_work_tree "rebase" "Please commit or stash them."
>
> +test -n "$upstream_name" && for reflog in \
> + $(git rev-list -g $upstream_name 2>/dev/null)
Ugly.
test -n "$upstream_name" &&
for reflog in $(git rev-list ...)
do
...
done
Don't you need to make sure $upstream_name is a branch (or a ref in
general that can have a reflog), or does it not matter because the
"rev-list -g" will die without producing anything and you are discarding
the error message?
Now, a handful of random questions, none of them rhetorical, as I don't
know the answers to any of them.
Would it help if the code is made just as clever as the patch attempts to
be, when the user says
git rebase origin/next~4
IOW, use the reflog of origin/next even in such a case?
> +do
> + if test $reflog = $(git merge-base $reflog $orig_head)
> + then
> + if test $reflog != $(git merge-base $onto $reflog)
> + then
> + upstream=$reflog
> + fi
> + break
> + fi
Do we always traverse down to the beginning of the reflog in the worst
case? Would bisection help to avoid the cost?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html