Re: [PATCH] rebase: be cleverer with rebased upstream branches
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 15, 2011, 20:30 UTC
- Message-ID
- <7vzkpxm45e.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <1297691481-3308-1-git-send-email-martin.von.zweigbergk@gmail.com>
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
Show 10 quoted lines
> 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
...
doneDon'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?
Show 9 quoted lines
> +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?