On Wed, 20 Sep 2006, Stephen Hemminger wrote: > > This doesn't work with all the branches for some reason. Is this a git > bug? It's a "Jeff bug". He rebases some of his branches, and git by default refuses to throw away the old data (so if the new branch is not a fast forward, it will _not_ just silently throw away the old state). However, you can tell git that Jeff is being difficult by marking such branches individually as being rebased. The git archive itself has one such branch: Junio re-writes the "pu" branch all the time, and so it seldom fast-forwards nicely (the thing about a fast forward is that you do _not_ lose any old history, you only append to it, while a rebase will throw the old history away and generate new history in its place). So for example, for git itself, you might have a "remotes" file like mine: [torvalds@g5 git]$ cat .git/remotes/parent URL: master.kernel.org:/pub/scm/git/git Pull: master:parent Pull: next:next Pull: +pu:pu which just says that the "parent" repo is the master repo for git, and notice how the "Pull: +pu:pu" line has that extra "+" at the head. That's a marker that the remote "pu" branch (which is fetched into the _local_ "pu" branch) should be updated even if it doesn't fast-forward. So you could either mark _all_ the remote branches with the extra "+" (to say that you always want to fetch that exact state for whatever branch you're tracking), or you can ask Jeff which branches he expects to do strange things and just mark those individual ones. > A temporary workaround is to prune the offending branches locally > first, but that seems like a hack. So there's a non-hack version of this as per above, and it's even documented, although hard to find (see Documentation/pull-fetch-param.txt) 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