{"thread":{"id":"43202","subject":"Re: [Fwd: Re: What's in git.git]","startedAt":"2006-11-19T17:40:06Z","lastAt":"2006-11-19T19:11:53Z","messageCount":4,"participants":["Jon Smirl","Robin Rosenberg","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"294025","messageId":"9e4733910611190940y147992b8mbdfac5a51f42e0fe@mail.gmail.com","threadId":"43202","inReplyTo":"20061119171135.GA13054@spearce.org","subject":"Re: [Fwd: Re: What's in git.git]","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-11-19T17:40:06Z","receivedAt":"2006-11-19T17:40:06Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 11/19/06, Shawn Pearce wrote:\n> Have you been watching the shallow clone threads?\n\nSome friends of mine are doing a start up that is sort of like a Sonos\nsystem but with some major differences. I've been helping them out so\nI've been doing chip design and PCB layouts lately. The system also\nneeds some really complicated real-time, wireless mesh routing\nsoftware, I wish the OLPC 802.11s code was ready.\n\nBrendan told me that he would not consider Mozilla moving to git until\na native Windows version is released so I just dropped the whole\nthing. It is too much effort and they don't even really want it. They\nare probably going to switch to SVN. I told him that SVN would end up\nbeing a disaster and he got mad at me. That's when I stopped working\non cvs2svn/git.\n\nThe shallow clone work is being done in the wrong order to get the\nMozilla people interested.\n#1) There needs to be a tool that can accurately import the\nrepository. cvs2svn does not do this. The good programmers working on\ngit could probably whip this out in a week or two if they wanted to.\ncvs2svn is very close but they refuse to solve the symbol dependency\nproblem.\n#2) git needs native Windows support, this probably includes MSVC\nintegration. There are a lot of non-technical people working on\nMozilla like accessibility, doc, artwork, translations, they are all\non Windows. Brendan explicitly ruled out cygwIn.\n#3) Once #1 and #2 are achieved then they will care about shallow clone.\n\nThe only way I can see Mozilla moving to git is if the git community\nports the repository for them and then demonstrates that all of the\nneeded tools and available and working.\n\n> ---------- Forwarded message ----------\n> From: Johannes Schindelin \n> To: Junio C Hamano \n> Date: Sun, 19 Nov 2006 16:17:17 +0100 (CET)\n> Subject: Re: What's in git.git\n> Hi,\n>\n> On Sat, 18 Nov 2006, Junio C Hamano wrote:\n>\n> > Junio C Hamano writes:\n> >\n> > > - 'pu' has the shallow clone WIP and a half-finished rewrite of\n> > > git branch in C, both by Johannes. Both needs a bit more\n> > > polishing and confidence building before going into 'next',\n> > > and given the recent discussion of enhancing branch\n> > > management for pulls/pushes, it might be easier to drop the\n> > > latter for now.\n> >\n> > OOPS; sorry but the latter half is entirely untrue. What's\n> > there is half-done git-shortlog. Scratch everything about\n> > branch management please.\n>\n> IMHO -shortlog needs support to read .mailmap, and maybe nods to throw out\n> the built-in mailmap which is totally specific to the Linux kernel\n> development.\n>\n> As for shallow clone support: I am a bit underwhelmed by the enthusiasm\n> to test this thing by the people I thought would be most interested. It\n> really could be the case that it is not needed at all.\n>\n> Just for the record, though: AFAICT the shallow stuff is lacking support\n> for at least pushing from/into shallow repos and it should avoid making a\n> commit shallow unnecessarily. And quite likely there are a few thinkos in\n> it, so it would not hurt having more test cases (notably of things I did\n> not think of), and some bad-ass testing with huge amounts of commits and\n> files which were added/modified identically in different commits.\n>\n> Ciao,\n> Dscho\n>\n>\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n>\n>\n\n\n-- \nJon Smirl\n"},{"id":"298714","messageId":"20061119174902.GW7201@pasky.or.cz","threadId":"43202","inReplyTo":"9e4733910611190940y147992b8mbdfac5a51f42e0fe@mail.gmail.com","subject":"Re: [Fwd: Re: What's in git.git]","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-19T17:49:02Z","receivedAt":"2006-11-19T17:49:02Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sun, Nov 19, 2006 at 06:40:06PM CET, Jon Smirl wrote:\n> Brendan told me that he would not consider Mozilla moving to git until\n> a native Windows version is released so I just dropped the whole\n> thing. It is too much effort and they don't even really want it. They\n> are probably going to switch to SVN. I told him that SVN would end up\n> being a disaster and he got mad at me. That's when I stopped working\n> on cvs2svn/git.\n\nI see. :-(\n\nCould you please publish cvs2git in whatever state you have it so that\nsomeone else possibly interested could pick it up and finish the missing\nbits? It would be shame if the already done work would end up wasted.\n\n> #2) git needs native Windows support, this probably includes MSVC\n> integration. There are a lot of non-technical people working on\n> Mozilla like accessibility, doc, artwork, translations, they are all\n> on Windows. Brendan explicitly ruled out cygwIn.\n\nThis is sort of catch-22, we have probably no developers interested\nenough in porting Git to native Windows and it's not clear we are going\nto get any until Git runs on native Windows.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nThe meaning of Stonehenge in Traflamadorian, when viewed from above, is:\n\"Replacement part being rushed with all possible speed.\"\n"},{"id":"295221","messageId":"200611192006.54071.robin.rosenberg.lists@dewire.com","threadId":"43202","inReplyTo":"20061119174902.GW7201@pasky.or.cz","subject":"Re: [Fwd: Re: What's in git.git]","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2006-11-19T19:06:53Z","receivedAt":"2006-11-19T19:06:53Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 19 november 2006 18:49 skrev Petr Baudis:\n> On Sun, Nov 19, 2006 at 06:40:06PM CET, Jon Smirl wrote:\n> > Brendan told me that he would not consider Mozilla moving to git until\n> > a native Windows version is released so I just dropped the whole\n> > thing. It is too much effort and they don't even really want it. They\n> > are probably going to switch to SVN. I told him that SVN would end up\n> > being a disaster and he got mad at me. That's when I stopped working\n> > on cvs2svn/git.\n>\n> I see. :-(\n>\n> Could you please publish cvs2git in whatever state you have it so that\n> someone else possibly interested could pick it up and finish the missing\n> bits? It would be shame if the already done work would end up wasted.\n>\n> > #2) git needs native Windows support, this probably includes MSVC\n> > integration. There are a lot of non-technical people working on\n> > Mozilla like accessibility, doc, artwork, translations, they are all\n> > on Windows. Brendan explicitly ruled out cygwIn.\n>\n> This is sort of catch-22, we have probably no developers interested\n> enough in porting Git to native Windows and it's not clear we are going\n> to get any until Git runs on native Windows.\n\nHaving a usable set of git in C-format (or C++) is what it takes to get things \nrolling. Make the shores of Git-land shallow with nice beaches, so it easy to \nenter and you'll get people there, just out of curiosity. They'll start \nimproving things after a while.\n\nEven if it is possible to run bash, python, perl and who-knows-what in native \nwindows it makes installing and packaging complicated. It is quite simple to \ninstall git under cygwin for people versed in cygwin or Linux, but not for \nthose that have no interest in those two.\n\nAs for plugins to visual studio and othe strange things, they will come if a \npractically usable core set is in place, that can be built and redestributed \nwithout a ton of dependencies. People have used visual studio with CVS and \nother tools without plugins for a long time just fine so Git will do fine \nwithour it for a while too. Eventually we'll have TortoiseGit. They key is a \nusable subset of Git that only requires a C compiler (or C++). Other \nsolutions are ofcourse possible (like a C# re-implementation), but making \nthings native C-code is the most straightforward path that doesn't split the \ncode base.\n\n"},{"id":"297681","messageId":"9e4733910611191111q65424631j875f444c9bb367f7@mail.gmail.com","threadId":"43202","inReplyTo":"20061119174902.GW7201@pasky.or.cz","subject":"Re: [Fwd: Re: What's in git.git]","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-11-19T19:11:53Z","receivedAt":"2006-11-19T19:11:53Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 11/19/06, Petr Baudis wrote:\n> On Sun, Nov 19, 2006 at 06:40:06PM CET, Jon Smirl wrote:\n> > Brendan told me that he would not consider Mozilla moving to git until\n> > a native Windows version is released so I just dropped the whole\n> > thing. It is too much effort and they don't even really want it. They\n> > are probably going to switch to SVN. I told him that SVN would end up\n> > being a disaster and he got mad at me. That's when I stopped working\n> > on cvs2svn/git.\n>\n> I see. :-(\n>\n> Could you please publish cvs2git in whatever state you have it so that\n> someone else possibly interested could pick it up and finish the missing\n> bits? It would be shame if the already done work would end up wasted.\n\nWorking on cvs2git is the wrong direction. cvs2svn has been\nspecifically tuned for importing into SVN and they aren't interested\nin making the architectural changes that git needs.\n\nThere is a core problem in the way cvs2svn handles CVS symbols.\n\n> I posted a three commit example of the problem.\n>\n> FileA has rev 1.1 and rev 1.2\n> FileB has rev 1.1\n> A symbol is created between A 1.1/1.2 and after B 1.1\n>\n> cvs2svn generated two change sets\n> 1) FileA 1.1\n> 2) FileB 1.1, FileA 1.2\n>\n> With these two change sets it is impossible to base the symbol simply,\n> there is no solution without copying. cvs2svn generates the symbol\n> based on #1 and copies FileB 1.1 from #2.\n>\n> The alternative is to output three change sets which is also a valid\n> representation of the same data.\n> 1) FileA 1.1\n> 2) FileB 1.1\n> 3) FileA 1.2\n>\n> Now there is a solution for the symbol, base is on change set #2. No\n> copies needed.\n>\n> By introducing symbol dependencies (which cvs2svn does not do) you can\n> force the second change set sequence to be generated.\n\nSVN allows a label to be made by picking a commit from six months ago\nwith 80% of the right files in it. They then link to revisions from\nlater commits to build up the file set needed for the label. Doing it\nthis way turns every symbol into a little branch. It is fixing the\nsymptoms rather than fixing the problem of figuring out the correct\nconstruction of the change sets. The SVN people seem to be perfectly\nhappy with these little branches and they aren't going to change\ncvs2svn.\n\ncvs2svn is a nice piece of code and a good thing to look at for\nreference. It includes some excellent test cases. The author is a\nPython expert and uses every last feature of the language which makes\nto code hard to understand at times. He also loves to refactor things\nand does so continuously. This is a major problem for any long lived\npatches. If you do choose to work on cvs2svn, just fork it until you\nare done developing, don't try to track the refactorings.\n\nThere are several other choices. Monotone is getting a pretty good\nimporter and the author is aware of the problem described above and is\nwriting his code to avoid it. Monotone is in C++ and make heavy use of\nthe Boost C++ template library. Because of this I can't tell what\ntheir code does, it doesn't look like C++ anymore.\n\ngit is in C and has high code quality standards. I would just start\nfrom scratch and write the importer over while referencing the\nexisting code. If anyone is interested in doing this I will be happy\nto explain what I know about doing the import accurately and quickly.\nWith the right algorithms it is possible to import Mozilla CVS with\n2GB memory in under an hour on a desktop machine.\n\nShawn has written git-fastimport. fastimport takes an input stream of\na simple language and then creates the git repository. The CVS\nimporter just needs to generate these commands.\n\nWith the current knowledge of issues around doing CVS import this\nproblem is not as hard as it used to be. Dozens of attempts have been\nmade at this problem, Shawn and I have looked at all of these and know\nwhere the algorithmic mistakes are. The only big outstanding problem I\nknow of with import is the issue described above which no one has\ncoded a solution for yet.\n\nOnce a solution has been found for this problem the next problem is\ndetecting when a branch gets merged back into the trunk. After that I\nthink the problem is fully solved.\n\n-- \nJon Smirl\n"}]}