Re: Users of git-check-files?
- From
- Josef Weidendorfer <josef.weidendorfer@gmx.de>
- Date
- Aug 3, 2005, 17:46 UTC
- 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:
Show 16 quoted lines
> 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