Alex Riesen <raa.lkml@xxxxxxxxx> writes: > David Woodhouse, Sat, May 05, 2007 19:50:28 +0200: >> > > >> > > Is there a better way? >> > >> > I would just remove the pluses. git-fetch will say that the branch is >> > already up-to-date, if the local branch already has everything the >> > remote has. >> >> Then after I pull from Linus' tree, I can't pull from the mtd tree -- it >> complains that the 'linus' branch there can't be fast-forwarded, and >> refuses to pull the 'master' branch. > > Which got me by surprise (just tried). I though it'd notice that all > the commits are already present... > > Experts, is it really supposed to be that way? I am not sure what the issue is here. If the copy of Linus's tip mtd tree has is behind the current Linus's tip, after you fetch from Linus's tree to obtain its tip, if you allowed the fetch from mtd tree to update the remote tracking ref that you use to keep track of where Linus is, it would _rewind_ it, so I think it is natural to warn/prevent that mistake. I think David's use of linus ref is bogus. What is he really trying to "track"? If he is trying to track where the tip of Linus's tree is, he should not let fetch from mtd to muck with that remote tracking ref that he uses to track Linus's tree. On the other hand, I think it is perfectly reasonable thing to want to track where the tip of Linus's tree is "from mtd tree's point of view". Then diff between "mtd's idea of Linus's tip" and "mtd's tip" would represent what mtd people did, regardless of what Linus did in his tree, before mtd people had a chance to sync again with Linus. - 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