Hi, On Sat, 26 Jan 2008, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > When the upstream branch is tracked, we can detect if that branch was > > rebased since it was last fetched. Teach git to use that information > > to rebase from the old remote head onto the new remote head. > > This is certainly nicer than the original (which is not in 1.5.3, so > even this late in the cycle it is "fixing up a new feature we will be > introducing in 1.5.4" category that I will apply). But I think a bit of > caution and perhaps an illustration or two in the doucmentation would > help. Well, I half expected it to be post-1.5.4. > If you do "git fetch" from the origin since the last time you ran "pull > --rebase" for the remote, we will have the same issue. Yes, that occurred to me, too. > So it might make sense to make the logic to figure out B, given > your local history that leads from 0 to x's (and nothing else), > a bit cleverer than looking at the tracking branch. We can look > at reflog for example. "git log -g --pretty=oneline" may have > entries of this form: > > * branch: Created from B > * rebase finished <branch> onto B > > and the latest (i.e. younguest) entry is where the part of your current > history to be rebased (i.e. base commit) starts. This is much more > reliable than looking at the tracking branch, whose answer may or may > not match B at all. I did not want to do that, because it is quite possible that the reflogs were disabled, or that the relevant reflogs were already expired. However, I think that it might be a good approach to try reflogs first, and fallback to what I sent if there are no reflogs (or if it is detected that the reflog entry is not possibly the correct one, since what was rebased to is no longer an ancestor of the current branch). Ciao, Dscho - 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
