On 11/19/06, Shawn Pearce <spearce@xxxxxxxxxxx> wrote:
Have you been watching the shallow clone threads?
Some friends of mine are doing a start up that is sort of like a Sonos system but with some major differences. I've been helping them out so I've been doing chip design and PCB layouts lately. The system also needs some really complicated real-time, wireless mesh routing software, I wish the OLPC 802.11s code was ready. Brendan told me that he would not consider Mozilla moving to git until a native Windows version is released so I just dropped the whole thing. It is too much effort and they don't even really want it. They are probably going to switch to SVN. I told him that SVN would end up being a disaster and he got mad at me. That's when I stopped working on cvs2svn/git. The shallow clone work is being done in the wrong order to get the Mozilla people interested. #1) There needs to be a tool that can accurately import the repository. cvs2svn does not do this. The good programmers working on git could probably whip this out in a week or two if they wanted to. cvs2svn is very close but they refuse to solve the symbol dependency problem. #2) git needs native Windows support, this probably includes MSVC integration. There are a lot of non-technical people working on Mozilla like accessibility, doc, artwork, translations, they are all on Windows. Brendan explicitly ruled out cygwIn. #3) Once #1 and #2 are achieved then they will care about shallow clone. The only way I can see Mozilla moving to git is if the git community ports the repository for them and then demonstrates that all of the needed tools and available and working.
---------- Forwarded message ---------- From: Johannes Schindelin <Johannes.Schindelin@xxxxxx> To: Junio C Hamano <junkio@xxxxxxx> Date: Sun, 19 Nov 2006 16:17:17 +0100 (CET) Subject: Re: What's in git.git Hi, On Sat, 18 Nov 2006, Junio C Hamano wrote: > Junio C Hamano <junkio@xxxxxxx> writes: > > > - 'pu' has the shallow clone WIP and a half-finished rewrite of > > git branch in C, both by Johannes. Both needs a bit more > > polishing and confidence building before going into 'next', > > and given the recent discussion of enhancing branch > > management for pulls/pushes, it might be easier to drop the > > latter for now. > > OOPS; sorry but the latter half is entirely untrue. What's > there is half-done git-shortlog. Scratch everything about > branch management please. IMHO -shortlog needs support to read .mailmap, and maybe nods to throw out the built-in mailmap which is totally specific to the Linux kernel development. As for shallow clone support: I am a bit underwhelmed by the enthusiasm to test this thing by the people I thought would be most interested. It really could be the case that it is not needed at all. Just for the record, though: AFAICT the shallow stuff is lacking support for at least pushing from/into shallow repos and it should avoid making a commit shallow unnecessarily. And quite likely there are a few thinkos in it, so it would not hurt having more test cases (notably of things I did not think of), and some bad-ass testing with huge amounts of commits and files which were added/modified identically in different commits. Ciao, Dscho - 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
-- Jon Smirl jonsmirl@xxxxxxxxx - 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