{"thread":{"id":"9047","subject":"Questions about git-fast-import for cvs2svn","startedAt":"2007-07-15T14:11:41Z","lastAt":"2007-07-16T06:19:48Z","messageCount":10,"participants":["Michael Haggerty","Sean","Linus Torvalds","Steffen Prohaska","Junio C Hamano","Robin Rosenberg","Robin H. Johnson","Eric Wong","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"47430","messageId":"469A2B1D.2040107@alum.mit.edu","threadId":"9047","inReplyTo":null,"subject":"Questions about git-fast-import for cvs2svn","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2007-07-15T14:11:41Z","receivedAt":"2007-07-15T14:11:41Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"I've been reading the documentation for git-fast-import (thanks for the\nfine documentation!) as part of determining how much work it would be to\nadd a git back end to cvs2svn, and I have a few questions.\n\n1. Is it a problem to create blobs that are never referenced? The\neasiest point to create blobs is when the RCS files are originally\nparsed, but later we discard some CVS revisions, meaning that the\ncorresponding blobs would never be needed. Would this be a problem?\n\n2. It appears that author/committer require an email address. How\nimportant is a valid email address here?\n\n a. CVS commits include a username but not an email address. If an\nemail address is really required, then I suppose the person doing the\nconversion would have to supply a lookup table mapping username -> email\naddress.\n\n b. CVS tag/branch creation events do not even include a username.\nAny suggestions for what to use here?\n\n3. I expect we should set 'committer' to the value determined from CVS\nand leave 'author' unused. But I suppose another possibility would be\nto set the 'committer' to 'cvs2svn' and the 'author' to the original CVS\nauthor. Which one makes sense?\n\n4. It appears that a commit can only have a single 'from', which I\nsuppose means that files can only be added to one branch from a single\nsource branch/revision in a single commit. But CVS branches and tags\ncan include files from multiple source branches and/or revisions. What\nwould be the most git-like way to handle this situation? Should the\nbranch be created in one commit, then have files from other sources\nadded to it in other commits? Or should (is this even possible?) all\nfiles be added to the branch in a single commit, using multiple \"merge\"\nsources?\n\n5. Is there any significance at all to the order that commits are output\nto git-fast-import? Obviously, blobs have to be defined before they are\nused, and ''s have to be defined before they are referenced.\n But is there any other significance to the order of commits?\n\nAll in all, I don't think that a git back end for cvs2svn would be very\ntrick at all. There will be a bit of refactoring work to allow the user\nto switch between SVN/git output at runtime, but so far I don't see any\nreason that the fundamental algorithms of cvs2svn will have to be changed.\n\nThanks,\nMichael\n"},{"id":"47440","messageId":"20070715120149.3271b736.seanlkml@sympatico.ca","threadId":"9047","inReplyTo":"469A2B1D.2040107@alum.mit.edu","subject":"Re: Questions about git-fast-import for cvs2svn","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-07-15T16:01:49Z","receivedAt":"2007-07-15T16:01:49Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 15 Jul 2007 16:11:41 +0200\nMichael Haggerty wrote:\n\nHi Michael,\n\nWill take a stab at answering your questions...\n\n> 1. Is it a problem to create blobs that are never referenced? The\n> easiest point to create blobs is when the RCS files are originally\n> parsed, but later we discard some CVS revisions, meaning that the\n> corresponding blobs would never be needed. Would this be a problem?\n\nNot a problem. Running \"git gc\" later will cleanup any unused objects.\n\n> 2. It appears that author/committer require an email address. How\n> important is a valid email address here?\n\nIt's not necessary for the operation of Git itself; it's up to you to\ndecide how important the information is to your project. You should\nbe able to set an empty email address for author or committer in\ngit fast-import as \"name <>\".\n\n> a. CVS commits include a username but not an email address. If an\n> email address is really required, then I suppose the person doing the\n> conversion would have to supply a lookup table mapping username -> email\n> address.\n\nYes, take a look at the format supported by git-cvsimport and git-svnimport,\nwhich can map each username into an appropriate name and email addy for Git.\n\n> b. CVS tag/branch creation events do not even include a username.\n> Any suggestions for what to use here?\n\nPerhaps just use your own username or one specifically created to\nrun the conversion process.\n\n> 3. I expect we should set 'committer' to the value determined from CVS\n> and leave 'author' unused. But I suppose another possibility would be\n> to set the 'committer' to 'cvs2svn' and the 'author' to the original CVS\n> author. Which one makes sense?\n\nAnother option is to just allow Git to set author and committer to the\nsame value. As noted in the man page: \"If author is omitted then\nfast-import will automatically use the committer's information for\nthe author portion of the commit\".\n\n> 4. It appears that a commit can only have a single 'from', which I\n> suppose means that files can only be added to one branch from a single\n> source branch/revision in a single commit. But CVS branches and tags\n> can include files from multiple source branches and/or revisions. What\n> would be the most git-like way to handle this situation? Should the\n> branch be created in one commit, then have files from other sources\n> added to it in other commits? Or should (is this even possible?) all\n> files be added to the branch in a single commit, using multiple \"merge\"\n> sources?\n\nGit supports the ability to merge from multiple branches at once (known\nas an octopus merge). So it's possible to start a new branch, drawing\nin files from more than one source branch in a single commit. As i\nunderstand it, fast-import allows only a single \"from\" line for a commit,\nbut allows multiple \"merge\" lines for additional parentage info. \n\n> 5. Is there any significance at all to the order that commits are output\n> to git-fast-import? Obviously, blobs have to be defined before they are\n> used, and ''s have to be defined before they are referenced.\n> But is there any other significance to the order of commits?\n\nDon't think so, except perhaps for the packfile optimization issues\nmentioned in the man page.\n\nHTH,\nSean\n"},{"id":"47447","messageId":"alpine.LFD.0.999.0707151119120.20061@woody.linux-foundation.org","threadId":"9047","inReplyTo":"469A2B1D.2040107@alum.mit.edu","subject":"Re: Questions about git-fast-import for cvs2svn","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-15T18:43:40Z","receivedAt":"2007-07-15T18:43:40Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 15 Jul 2007, Michael Haggerty wrote:\n> \n> 1. Is it a problem to create blobs that are never referenced? The\n> easiest point to create blobs is when the RCS files are originally\n> parsed, but later we discard some CVS revisions, meaning that the\n> corresponding blobs would never be needed. Would this be a problem?\n\nNo, don't worry about it. The resulting intermediate pack-file may be \nunnecessarily big, but you'd want to do a \"git gc\" to re-pack everything \nafterwards *anyway*, since the pack-files git-fast-import generates are \ngenerally not all that optimall, and that will also prune any unreferenced \nblobs.\n\n> 2. It appears that author/committer require an email address. How\n> important is a valid email address here?\n\nGit itself doesn't really care, and many CVS conversions have just \nconverted the username into \"user \", but from a QoI standpoint it's \nmuch nicer if you at least were to allow the kind of conversion that \nallows user-name to be associated with an email.\n\nMaybe git-fast-import could be taught to do the kind of user name \nconversion that we already do for CVS imports.. Shawn?\n\n> a. CVS commits include a username but not an email address. If an\n> email address is really required, then I suppose the person doing the\n> conversion would have to supply a lookup table mapping username -> email\n> address.\n\nThat would be optimal. Note that it's not just user names: it's much nicer \nif you can regenerate a readable full name too, so instead of having \nsomething like \"torvalds \", you could map \"torvalds\" into \"Linus \nTorvalds \", which is a lot more readable.\n\nBut as far as git is concerned, this is all about being _pretty_, it \ndoesn't really have any semantic meaning!\n\nAnyway, git-cvsimport knows about a magic file (\"CVSROOT/users\") that can \nmap user names into full names and emails. Having soemthing equvalent \nfor a SVN import would be nice (git-svnimport does the same thing, and \nuses \".git/svn-authors\" as the default source of author name conversion \ndata).\n\n> b. CVS tag/branch creation events do not even include a username.\n> Any suggestions for what to use here?\n\nGit tags and branch creation doesn't do that either (unless you use signed \ntags): only when you create the first commit on a branch does the user \nmatter.\n\nBut if there really is data that doesn't have any user information at all \n(for real *changes*), then I'd just make one up. Again, the user \ninformation really doesn't have any *semantics* in git, it's just meant to \nbe informational for showing the logs. It's nothing more than a structured \npart of the commit (or tag) message.\n\n> 3. I expect we should set 'committer' to the value determined from CVS\n> and leave 'author' unused. But I suppose another possibility would be\n> to set the 'committer' to 'cvs2svn' and the 'author' to the original CVS\n> author. Which one makes sense?\n\nJust make them be the same. Git-fast-import will default to that, if you \nonly give a committer date/name.\n\nThat's what git itself does if you just do a \"git commit\": the committer \nwill the the same as the author.\n\n> 4. It appears that a commit can only have a single 'from'\n\nNo, commits can have an arbitrary number of parents, and if you create a \ntag where the data comes from several sources, you could literally do that \nass a really strange merge, and that would probably be the most \"correct\" \nthing to do, even if it might end up looking *really* odd.\n\n[ To be strictly technically correct, I have to admit that I think we \n limit the number of parents to 16, but that's not a fundamental limit, \n that's just because nobody has ever been so crazy as to need more than \n that.\n\n However, there is no \"data structure limit\" in that number, it's just aa \n arbitrary \"you'd be crazy to generate a merge of that many parents\" kind \n of thing, and we could lift the limit if you actually think it's worth \n it.\n\n I think the most we have ever seen in practice is a merge of 12 parents, \n and the people who did that were told to please not do it again, because \n it really does make the graph look extremely \"cool\". ]\n\n> What would be the most git-like way to handle this situation? Should \n> the branch be created in one commit, then have files from other sources \n> added to it in other commits? Or should (is this even possible?) all \n> files be added to the branch in a single commit, using multiple \"merge\" \n> sources?\n\nUsing multiple parents and just generating a single commit (it will be \ncalled a \"merge\", but really, in git terms a commit is just a commit, and \nthe difference in number of parents is really not a _technical_ \ndifference, it's just a difference for how these things get visualized).\n\nIt would be extremely interesting to see how this works in practice, but I \n_think_ it would work really well. The possible downsides might be:\n\n - it *may* just end up looking so confusing that people would prefer some \n alternate model.\n\n - we might have some performance issues with lots and lots of parents, \n and maybe we'd need to fix something. In particular, I can well imagine \n that showing the diff for the end result would be \"interesting\" (read: \n \"totally useless\")\n\n> 5. Is there any significance at all to the order that commits are output\n> to git-fast-import? Obviously, blobs have to be defined before they are\n> used, and ''s have to be defined before they are referenced.\n> But is there any other significance to the order of commits?\n\nNot afaik. Git internally very fundamentally simply doesn't care (there \nsimply _is_ no object ordering, there is just objects that point to other \nobjects), and I don't think git-fast-import could possibly care either. \nYou do need to be \"topologically\" sorted (since you cannot even point to \ncommits without having their SHA1's), but that should be it.\n\n\t\tLinus\n"},{"id":"47449","messageId":"F06A5876-BA2A-4172-B2D1-BBCFF92C83EF@zib.de","threadId":"9047","inReplyTo":"20070715120149.3271b736.seanlkml@sympatico.ca","subject":"Re: Questions about git-fast-import for cvs2svn","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-07-15T18:51:42Z","receivedAt":"2007-07-15T18:51:42Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 15, 2007, at 6:01 PM, Sean wrote:\n\n> On Sun, 15 Jul 2007 16:11:41 +0200\n> Michael Haggerty wrote:\n>\n> [...]\n>\n>> 3. I expect we should set 'committer' to the value determined from \n>> CVS\n>> and leave 'author' unused. But I suppose another possibility \n>> would be\n>> to set the 'committer' to 'cvs2svn' and the 'author' to the \n>> original CVS\n>> author. Which one makes sense?\n>\n> Another option is to just allow Git to set author and committer to the\n> same value. As noted in the man page: \"If author is omitted then\n> fast-import will automatically use the committer's information for\n> the author portion of the commit\".\n\nI expect that committer and author would both be set to the value\ndetermined from CVS. CVS doesn't differentiate and I think the\nmost reasonable assumption in many CVS settings is that the one\nwho committed a change is the original author.\n\n\n>> 4. It appears that a commit can only have a single 'from', which I\n>> suppose means that files can only be added to one branch from a \n>> single\n>> source branch/revision in a single commit. But CVS branches and tags\n>> can include files from multiple source branches and/or revisions. \n>> What\n>> would be the most git-like way to handle this situation? Should the\n>> branch be created in one commit, then have files from other sources\n>> added to it in other commits? Or should (is this even possible?) all\n>> files be added to the branch in a single commit, using multiple \n>> \"merge\"\n>> sources?\n\nThis is really a hard question, which I feel unable to answer.\nMy feeling is that you would not be able to construct a git\nhistory where branches would need multiple 'froms'. git always\ntracks the complete state of all files in the project. So\nyou can only branch all files at once or no file at all.\nIt's really hard to say how the situation you described can\nbe handled.\n\nHowever, I have a related comment.\n\nWell maintained CVS branches shouldn't suffer from this problem. In\nour repository we typically set a tag topic-split on the CVS trunk\nand create the branch topic-branch from this tag. Note, some time may\npass before we commit the first change to topic-branch. I'd expect that\na CVS to git importer should handle this situation perfectly. I'd expect\nthat the git tag topic-split would be set to the last commit common\nto the git branch representing the CVS trunk and the git branch\nrepresenting the CVS topic-branch. git-cvsimport fails to do so if\nthe timing of the first commit to the CVS topic-branch is wrong.\n\nTo be honest, we have messy branches as well that start off in an\nuncontrolled way. But I'd care less about them than about the well\nmaintained branches.\n\nMichael,\nwhat do you think. Would cvs2svn perfectly handle the well-formed\nCVS branches I described?\n\nI already would be very happy if the well-formed branches can be\nimported to git and any malformed branch would be reported.\n\nMaybe a second step could be to import malformed branches nonetheless,\nperhaps in a non-standard way and give a hint what the difficulty was.\nA human may have a chance to fix it using git tools, such as\ngit-filter-branch or similar.\n\n\n> Git supports the ability to merge from multiple branches at once \n> (known\n> as an octopus merge). So it's possible to start a new branch, drawing\n> in files from more than one source branch in a single commit. As i\n> understand it, fast-import allows only a single \"from\" line for a \n> commit,\n> but allows multiple \"merge\" lines for additional parentage info.\n>\n> [...]\n\nI'm not sure if merges help to solve the situation described by Michael.\n From my understanding the situation is more like starting a branch and\nlater 'cherry-picking' commits from various other branches at different\ntimes. Michael describes a situation where a branch would need to start\nfrom multiple commits. I think this is different from merging.\n\nI propose not to create any merge commits during import from CVS to git.\nCVS doesn't track merges and therefore I'd expect that the history \ncreated\nin git during import should form a tree (without merges). If you have\na custom way to detect merges for a specific CVS repository (e.g. by \nparsing\nCVS commit messages) you can use a grafts file to add them to git later.\n\n\tSteffen\n"},{"id":"47450","messageId":"7vd4ytebsw.fsf@assigned-by-dhcp.cox.net","threadId":"9047","inReplyTo":"20070715120149.3271b736.seanlkml@sympatico.ca","subject":"Re: Questions about git-fast-import for cvs2svn","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-15T18:55:59Z","receivedAt":"2007-07-15T18:55:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sean writes:\n\n> Will take a stab at answering your questions...\n>\n>> 1. Is it a problem to create blobs that are never referenced? The\n>> easiest point to create blobs is when the RCS files are originally\n>> parsed, but later we discard some CVS revisions, meaning that the\n>> corresponding blobs would never be needed. Would this be a problem?\n>\n> Not a problem. Running \"git gc\" later will cleanup any unused objects.\n>\n>> 2. It appears that author/committer require an email address. How\n>> important is a valid email address here?\n>\n> It's not necessary for the operation of Git itself; it's up to you to\n> decide how important the information is to your project. You should\n> be able to set an empty email address for author or committer in\n> git fast-import as \"name <>\".\n\nDon't do this; git-cvsimport and git-svn uses \"name \"\nwhich is a saner compromise. This way, you can add .mailmap to\nhelp later \"git shortlog\" to map using \"\" part to more\nhuman friendly name. Mapping at conversion time would also be\ngood and git-cvsimport knows about it (I do not know about\ngit-svn).\n\n>> b. CVS tag/branch creation events do not even include a username.\n>> Any suggestions for what to use here?\n>\n> Perhaps just use your own username or one specifically created to\n> run the conversion process.\n\nI'd suggest to take the person and time information from the\ncommit that is tagged; that way you can keep the conversion\nstable (iow, two conversoin runs using the same input data would\nproduce identical result).\n\nIn git we do not record \"branch creation event\". Also you can\nuse lightweight tags which does not have its own data -- which\nmeans you do not have to come up with \"the person who made the\ntag\".\n\n>> 3. I expect we should set 'committer' to the value determined from CVS\n>> and leave 'author' unused. But I suppose another possibility would be\n>> to set the 'committer' to 'cvs2svn' and the 'author' to the original CVS\n>> author. Which one makes sense?\n\nI would set both to \"name \" from CVS information.\n"},{"id":"47451","messageId":"877A33E8-7C61-4E36-BF07-5819914FCE21@zib.de","threadId":"9047","inReplyTo":"F06A5876-BA2A-4172-B2D1-BBCFF92C83EF@zib.de","subject":"Re: Questions about git-fast-import for cvs2svn","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-07-15T18:58:39Z","receivedAt":"2007-07-15T18:58:39Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 15, 2007, at 8:51 PM, Steffen Prohaska wrote:\n\n> I'm not sure if merges help to solve the situation described by \n> Michael.\n> From my understanding the situation is more like starting a branch and\n> later 'cherry-picking' commits from various other branches at \n> different\n> times. Michael describes a situation where a branch would need to \n> start\n> from multiple commits. I think this is different from merging.\n\n[ Hmm.. should have checked my email another time\nto avoid the race condition with Linus ...]\n\n\tSteffen\n"},{"id":"47463","messageId":"200707152356.58304.robin.rosenberg.lists@dewire.com","threadId":"9047","inReplyTo":"469A2B1D.2040107@alum.mit.edu","subject":"Re: Questions about git-fast-import for cvs2svn","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-07-15T21:56:56Z","receivedAt":"2007-07-15T21:56:56Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 15 juli 2007 skrev Michael Haggerty:\n> b. CVS tag/branch creation events do not even include a username.\n> Any suggestions for what to use here?\n\nThe CVSROOT/history file contains the user name and timestamp of the tag\ncreation. CVS can be told not to update the file. It is appended to by default.\n\n-- robin\n"},{"id":"47471","messageId":"20070715232115.GD12664@curie-int.orbis-terrarum.net","threadId":"9047","inReplyTo":"200707152356.58304.robin.rosenberg.lists@dewire.com","subject":"Re: Questions about git-fast-import for cvs2svn","fromName":"Robin H. Johnson","fromEmail":"robbat2@gentoo.org","sentAt":"2007-07-15T23:21:15Z","receivedAt":"2007-07-15T23:21:15Z","isPatch":false,"sender":{"key":"robbat2@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/373898?v=4"},"body":"On Sun, Jul 15, 2007 at 11:56:56PM +0200, Robin Rosenberg wrote:\n> s?ndag 15 juli 2007 skrev Michael Haggerty:\n> > b. CVS tag/branch creation events do not even include a username.\n> > Any suggestions for what to use here?\n> The CVSROOT/history file contains the user name and timestamp of the tag\n> creation. CVS can be told not to update the file. It is appended to by default.\nThis assumes that said file is intact, and that LogFormat was not\nchanged to not put entries into the file on tag/branch.\n\n-- \nRobin Hugh Johnson\nGentoo Linux Developer & Council Member\nE-Mail : robbat2@gentoo.org\nGnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85\n"},{"id":"47503","messageId":"20070716033540.GB29521@muzzle","threadId":"9047","inReplyTo":"7vd4ytebsw.fsf@assigned-by-dhcp.cox.net","subject":"Re: Questions about git-fast-import for cvs2svn","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-07-16T03:35:41Z","receivedAt":"2007-07-16T03:35:41Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Junio C Hamano wrote:\n> Sean writes:\n> >> 2. It appears that author/committer require an email address. How\n> >> important is a valid email address here?\n> >\n> > It's not necessary for the operation of Git itself; it's up to you to\n> > decide how important the information is to your project. You should\n> > be able to set an empty email address for author or committer in\n> > git fast-import as \"name <>\".\n> \n> Don't do this; git-cvsimport and git-svn uses \"name \"\n> which is a saner compromise. This way, you can add .mailmap to\n> help later \"git shortlog\" to map using \"\" part to more\n> human friendly name. Mapping at conversion time would also be\n> good and git-cvsimport knows about it (I do not know about\n> git-svn).\n\ngit-svn can do this, too.\n\nI don't use it myself, but I remember the file format is the\nsame as the one git-svnimport and git-cvsimport use.\n\n-- \nEric Wong\n"},{"id":"47517","messageId":"20070716061948.GG32566@spearce.org","threadId":"9047","inReplyTo":"alpine.LFD.0.999.0707151119120.20061@woody.linux-foundation.org","subject":"Re: Questions about git-fast-import for cvs2svn","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-16T06:19:48Z","receivedAt":"2007-07-16T06:19:48Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> On Sun, 15 Jul 2007, Michael Haggerty wrote:\n> > 2. It appears that author/committer require an email address. How\n> > important is a valid email address here?\n> \n> Git itself doesn't really care, and many CVS conversions have just \n> converted the username into \"user \", but from a QoI standpoint it's \n> much nicer if you at least were to allow the kind of conversion that \n> allows user-name to be associated with an email.\n> \n> Maybe git-fast-import could be taught to do the kind of user name \n> conversion that we already do for CVS imports.. Shawn?\n\nIt could, but I'm not sure I want to implement it. ;-)\n\nI pretty much view source->Git translation as the business/policy\nof the frontend, not of fast-import. But we have three frontends\nthat all share the same file format (git-cvsimport, git-svnimport,\ngit-svn), and are all independent implementations. Maybe pushing\nit down into a tool like fast-import would benefit a lot of users,\nand thus should be done.\n\nI'll put it on my todo list. Which is much longer than I have\ntime for.\n \n> > 5. Is there any significance at all to the order that commits are output\n> > to git-fast-import? Obviously, blobs have to be defined before they are\n> > used, and ''s have to be defined before they are referenced.\n> > But is there any other significance to the order of commits?\n> \n> Not afaik. Git internally very fundamentally simply doesn't care (there \n> simply _is_ no object ordering, there is just objects that point to other \n> objects), and I don't think git-fast-import could possibly care either. \n> You do need to be \"topologically\" sorted (since you cannot even point to \n> commits without having their SHA1's), but that should be it.\n\nLinus is completely correct here. The only requirement on data\nordering is that all parent commits (from/merge lines) must\ncome before any child that depends on them. But that's a pretty\nreasonable request, as almost all VCS systems want data to come in\nat least that order, if not something even more strict.\n\nIn theory marks could be used to stub in commits and let you feed\nthem out of order, but to make that work fast-import would need to\nbuffer them until it saw everything it needed to produce a SHA-1.\nNot exactly a good idea.\n\n-- \nShawn.\n"}]}