Junio C Hamano wrote:
His second point is also a real issue. If you allowed cloning an empty repo (either bare or non-bare), then you and Bill can both clone from it, come up with an initial commit each. Bill pushes his initial commit first. Your later attempt to push will hopefully fail with "non fast forward", if you know better than forcing such a push, but then what? You need to fetch, and merge (or rebase) your change on top of Bill's initial commit, and at that point the history you are trying to merge does not have any common ancestor with his history.
If we assume zero communication between these two, the alternative is this: Bill starts hacking in his own repo and then uploads his .git dir to the server. David starts hacking in his own repo and then uploads his .git dir to the server. The only difference between the two scenarios is (assuming they have write access to those shared directories) that the last-in wins in the second case, while first-in wins in the first one. Oh, and the fact that the first to upload his .git dir to the server will lose all his refs if he isn't careful to save his original copy until they both have established which "first" commit to use, which could take a while in this imaginary world where they don't seem to be speaking to each other but are still working together. -- Andreas Ericsson andreas.ericsson@xxxxxx OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 - 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
