On Wednesday 03 August 2005 19:37, you wrote: > Linus Torvalds <[EMAIL PROTECTED]> writes: > > I started out to make the "-f" flag to send-file work around it, but I > > never finished that, partly because it really ends up being the same > > thing as "git-fetch-pack" in reverse, which was against the whole point > > of git-send-pack. Send-pack is meant to be an "update remote tree" thing, > > with the assumption that the remote tree is a subset - and exactly that > > assumption is what makes send-pack much cheaper than fetch-pack. > > I think in addition to the existing ref_newer() check, which > makes sure you are advancing the remote head, not just replacing > with something unrelated, making sure that we have objects > referenced by ref->old_sha1 we obtained from the remote on our > end for all branches involved would be the only thing needed. > The latter the users should not even be able to override with > the --force flag, of course, but we would remind them to pull > from the other end first.
But my example shows that the error happens even with 2 branches totally unrelated to each other: if branch1 got a new commit, you can not push to branch2 from another clone. Why is it not enough to have all the history of a remote branch in the local clone to be able to push to this branch? Josef - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
