From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: Wed, 03 Aug 2005 17:46:00 GMT
Subject: Re: Users of git-check-files?
Message-ID: <200508031946.01017.Josef.Weidendorfer@gmx.de>
In-Reply-To: <7virymdirb.fsf@assigned-by-dhcp.cox.net>

On Wednesday 03 August 2005 19:37, you wrote:
> Linus Torvalds <torvalds@osdl.org> 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