From: Junio C Hamano Date: Fri, 17 Jul 2009 08:25:08 GMT Subject: Re: [PATCHv2 2/2] pull: support rebased upstream + fetch + pull --rebase Message-ID: <7vr5wf67iz.fsf@alter.siamese.dyndns.org> In-Reply-To: Santi Béjar writes: > 2009/7/17 Santi Béjar : >> 2009/7/16 Junio C Hamano : >>> Johannes Schindelin writes: >>> >>>> How about >>>> >>>>       oldremoteref="$(git rev-list --boundary HEAD --not \ >>>>                       $(git rev-list -g $remoteref | sed 's/$/^@/') | >>>>               sed -e '/^[^-]/d' -e q)" >>>> >>>> Explanation: the "git rev-list -g $remoteref" lists the previous commits >>>> the remote ref pointed to, and the ^@ appended to them means all their >>>> parents.  Now, the outer rev-list says to take everything in HEAD but >>>> _not_ in those parents, showing the boundary commits.  The "sed" call >>>> lists the first such boundary commit (which must, by construction, be one >>>> of the commits shown by the first rev-list). >>> >>> Hmm, I am not sure about that "(which must..." part. > > Unfortunatly you are right with the "(which must..." part. Even > without the ^@. Normally gives the right answer, but it is not > sure that the first commit boundary is the correct one. For > example: > > o--C > / > A--x--y--B--o--z > \ / > o----o > > A, B, C are upstream@{n} > > It involves a merge with a branch forked before the fork commit > for the current branch, and it will not work neither with git > pull --rebase. We could say that it is not supported, but > nevertheless it gives the wrong answer. > > The right answer is B, but: > $ git rev-list --boundary z --not C B A > z > o > o > o > -x > -B Now a short question. Does your original loop give a correct answer in this case?