Hi, On Tue, 31 Jan 2006, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > Worse, you cannot pull from older servers into shallow repos. > > "have X" means different thing if you do not have matching > grafts information, so I suspect that is fundamentally > unsolvable. If the shallow-capable client could realize that the server is not shallow-capable *and* the local repo is shallow, and refuse to operate (unless called with "-f", in which case the result may or may not be a broken repo, which has to be fixed up manually by copying over ORIG_HEAD to HEAD). Of course, the client has to know that the local repo is shallow, which it must not determine by looking at the grafts file. > I am not sure you can convince "git-rev-list ^A" to mean "not at > A but things before that is still interesting", especially when > you give many other heads to start traversing from, but if you > can, then you can do things at rev-list command line parameter > level without doing the "exchange and use the same grafts" > trickery. That _might_ be easier to implement but I do not see > an obvious correctness guarantee in the approach. If you introduce a different "have X" -- like "have-no-parent X" -- and teach git-rev-list that "~A" means "traverse the tree of A, but not A's parents", you'd basically have everything you need, right? > Implementation bugs aside, it is obvious the things _would_ work > correctly with "exchange and use the same grafts" approach. Yes, I agree. But again, the local repo has to know which grafts were introduced by making the repo shallow. Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Thu Feb 02 01:34:29 2006
This archive was generated by hypermail 2.1.8 : 2006-02-02 01:34:39 EST