{"thread":{"id":"18493","subject":"[PATCH] Add warning about known issues to documentation of cvsimport","startedAt":"2009-03-23T19:53:05Z","lastAt":"2009-04-02T05:25:01Z","messageCount":22,"participants":["Heiko Voigt","Ferry Huberts (Pelagic)","Jeff King","Junio C Hamano","Chris Johnsen"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"109099","messageId":"20090323195304.GC26678@macbook.lan","threadId":"18493","inReplyTo":null,"subject":"[PATCH] Add warning about known issues to documentation of cvsimport","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2009-03-23T19:53:05Z","receivedAt":"2009-03-23T19:53:05Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"The described issues are compiled from the tests by Michael Haggerty and me.\nBecause it is not apparent that these can be fixed anytime soon at least warn\nunwary users not to rely on the inbuilt cvsimport to much.\n\nSigned-off-by: Heiko Voigt \n---\n Documentation/git-cvsimport.txt | 34 ++++++++++++++++++++++++++++++++++\n 1 files changed, 34 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt\nindex b7a8c10..3123725 100644\n--- a/Documentation/git-cvsimport.txt\n+++ b/Documentation/git-cvsimport.txt\n@@ -24,6 +24,9 @@ repository, or incrementally import into an existing one.\n Splitting the CVS log into patch sets is done by 'cvsps'.\n At least version 2.1 is required.\n \n+*WARNING:* for certain situations the import leads to incorrect results.\n+Please see the section <> for further reference.\n+\n You should *never* do any work of your own on the branches that are\n created by 'git-cvsimport'. By default initial import will create and populate a\n \"master\" branch from the CVS repository's main branch which you're free\n@@ -164,6 +167,37 @@ If '-v' is specified, the script reports what it is doing.\n Otherwise, success is indicated the Unix way, i.e. by simply exiting with\n a zero exit status.\n \n+[[issues]]\n+ISSUES\n+------\n+Problems related to timestamps:\n+\n+ * If timestamps of commits in the cvs repository are not stable enough\n+ to be used for ordering commits\n+ * If any files were ever \"cvs import\"ed more than once (e.g., import of\n+ more than one vendor release)\n+ * If the timestamp order of different files cross the revision order\n+ within the commit matching time window\n+\n+Problems related to branches:\n+\n+ * Branches on which no commits have been made are not imported\n+ * All files from the branching point are added to a branch even if\n+ never added in cvs\n+ * files added to the source branch *after* a daughter branch was\n+ created: If previously no commit was made on the daugther branch they\n+ will erroneously be added to the daughter branch in git\n+\n+Problems related to tags:\n+\n+* Multiple tags on the same revision are not imported\n+\n+If you suspect that any of these issues may apply to the repository you\n+want to import consider using these alternative tools which proved to be\n+more stable in practise:\n+\n+* cvs2git (part of cvs2svn), `http://cvs2svn.tigris.org`\n+* parsecvs, `http://cgit.freedesktop.org/~keithp/parsecvs`\n \n Author\n ------\n-- \n1.6.1.2.390.gba743\n"},{"id":"109102","messageId":"49C7F233.9050205@pelagic.nl","threadId":"18493","inReplyTo":"20090323195304.GC26678@macbook.lan","subject":"Re: [PATCH] Add warning about known issues to documentation of cvsimport","fromName":"Ferry Huberts (Pelagic)","fromEmail":"ferry.huberts@pelagic.nl","sentAt":"2009-03-23T20:33:55Z","receivedAt":"2009-03-23T20:33:55Z","isPatch":true,"sender":{"key":"ferry.huberts@pelagic.nl","avatar":"https://gravatar.com/avatar/9f63c0289ad23cbdef0f7609a0af85ff0f4b3babfd066de9ff58f62d48cfd6f2?d=mp&s=160"},"body":"Heiko Voigt wrote:\n> The described issues are compiled from the tests by Michael Haggerty and me.\n> Because it is not apparent that these can be fixed anytime soon at least warn\n> unwary users not to rely on the inbuilt cvsimport to much.\n> \n> Signed-off-by: Heiko Voigt \n> ---\n> Documentation/git-cvsimport.txt | 34 ++++++++++++++++++++++++++++++++++\n> 1 files changed, 34 insertions(+), 0 deletions(-)\n> \n> diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt\n> index b7a8c10..3123725 100644\n> --- a/Documentation/git-cvsimport.txt\n> +++ b/Documentation/git-cvsimport.txt\n> @@ -24,6 +24,9 @@ repository, or incrementally import into an existing one.\n> Splitting the CVS log into patch sets is done by 'cvsps'.\n> At least version 2.1 is required.\n> \n> +*WARNING:* for certain situations the import leads to incorrect results.\n> +Please see the section <> for further reference.\n> +\n> You should *never* do any work of your own on the branches that are\n> created by 'git-cvsimport'. By default initial import will create and populate a\n> \"master\" branch from the CVS repository's main branch which you're free\n> @@ -164,6 +167,37 @@ If '-v' is specified, the script reports what it is doing.\n> Otherwise, success is indicated the Unix way, i.e. by simply exiting with\n> a zero exit status.\n> \n> +[[issues]]\n> +ISSUES\n> +------\n> +Problems related to timestamps:\n> +\n> + * If timestamps of commits in the cvs repository are not stable enough\n> + to be used for ordering commits\n> + * If any files were ever \"cvs import\"ed more than once (e.g., import of\n> + more than one vendor release)\n> + * If the timestamp order of different files cross the revision order\n> + within the commit matching time window\n> +\n> +Problems related to branches:\n> +\n> + * Branches on which no commits have been made are not imported\n> + * All files from the branching point are added to a branch even if\n> + never added in cvs\n> + * files added to the source branch *after* a daughter branch was\n> + created: If previously no commit was made on the daugther branch they\n> + will erroneously be added to the daughter branch in git\n> +\n> +Problems related to tags:\n> +\n> +* Multiple tags on the same revision are not imported\n> +\n> +If you suspect that any of these issues may apply to the repository you\n> +want to import consider using these alternative tools which proved to be\n> +more stable in practise:\n> +\n> +* cvs2git (part of cvs2svn), `http://cvs2svn.tigris.org`\n> +* parsecvs, `http://cgit.freedesktop.org/~keithp/parsecvs`\n> \n> Author\n> ------\nmaybe you can also add remarks about autocrlf and safecrlf?\nboth need to be off\n"},{"id":"109152","messageId":"20090324031448.GA12829@coredump.intra.peff.net","threadId":"18493","inReplyTo":"20090323195304.GC26678@macbook.lan","subject":"Re: [PATCH] Add warning about known issues to documentation of cvsimport","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-03-24T03:14:48Z","receivedAt":"2009-03-24T03:14:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 23, 2009 at 08:53:05PM +0100, Heiko Voigt wrote:\n\n> The described issues are compiled from the tests by Michael Haggerty and me.\n> Because it is not apparent that these can be fixed anytime soon at least warn\n> unwary users not to rely on the inbuilt cvsimport to much.\n\nI think this change is good in concept.\n\n> +[[issues]]\n> +ISSUES\n> +------\n> +Problems related to timestamps:\n> +\n> + * If timestamps of commits in the cvs repository are not stable enough\n> + to be used for ordering commits\n> + * If any files were ever \"cvs import\"ed more than once (e.g., import of\n> + more than one vendor release)\n> + * If the timestamp order of different files cross the revision order\n> + within the commit matching time window\n\nReading this, I kept waiting for the \"then\" to your \"if\". I think the\nimplication is \"your import will be incorrect\". But it would be nice to\nsay _how_, even if it's something as simple as \"changes may show up in\nthe wrong commit, the wrong branch, be omitted\" or whatever. Just give a\ngeneral idea of what can happen.\n\nAlso, this renders somewhat poorly in the manpage version. I get:\n\n\nISSUES\n Problems related to timestamps:\n\n\n · If timestamps of commits in the cvs repository are not stable\n enough to be used for ordering commits\n\n · If any files were ever \"cvs import\"ed more than once (e.g., import\n of more than one vendor release)\n\n · If the timestamp order of different files cross the revision order\n within the commit matching time window\n Problems related to branches:\n\n\n · Branches on which no commits have been made are not imported\n\n\nNote the extra blank line between each heading and its list, and the\nlack of a blank line between the end of the first list and the heading\nof the second. Your source is very readable, so it really is just\nasciidoc being silly, but I wonder if there is a way to work around\nthat.\n\n-Peff\n"},{"id":"109945","messageId":"20090330221729.GB68118@macbook.lan","threadId":"18493","inReplyTo":"49C7F233.9050205@pelagic.nl","subject":"Re: [PATCH] Add warning about known issues to documentation of cvsimport","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2009-03-30T22:17:29Z","receivedAt":"2009-03-30T22:17:29Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Mon, Mar 23, 2009 at 09:33:55PM +0100, Ferry Huberts (Pelagic) wrote:\n> maybe you can also add remarks about autocrlf and safecrlf?\n> both need to be off\n\n>From my experience thats not necessarily true. You can use\nautocrlf=input to repair broken revisions were crlf's have been\nmistakenly committed into the repository. And if I remember correctly\nsafecrlf helps if you want to make sure that no information gets lost.\n\nSo when importing from a nice correct cvs repository you would expect\nsafecrlf to not stop your import. And I suspect there are actually cvs\nusers that were very careful with their lineendings who would use it.\n\ncheers Heiko\n"},{"id":"109946","messageId":"20090330223646.GC68118@macbook.lan","threadId":"18493","inReplyTo":"20090324031448.GA12829@coredump.intra.peff.net","subject":"Re: [PATCH] Add warning about known issues to documentation of cvsimport","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2009-03-30T22:36:46Z","receivedAt":"2009-03-30T22:36:46Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Mon, Mar 23, 2009 at 11:14:48PM -0400, Jeff King was talking about:\n> On Mon, Mar 23, 2009 at 08:53:05PM +0100, Heiko Voigt wrote:\n> \n> > The described issues are compiled from the tests by Michael Haggerty and me.\n> > Because it is not apparent that these can be fixed anytime soon at least warn\n> > unwary users not to rely on the inbuilt cvsimport to much.\n> \n> I think this change is good in concept.\n> \n> > +[[issues]]\n> > +ISSUES\n> > +------\n> > +Problems related to timestamps:\n> > +\n> > + * If timestamps of commits in the cvs repository are not stable enough\n> > + to be used for ordering commits\n> > + * If any files were ever \"cvs import\"ed more than once (e.g., import of\n> > + more than one vendor release)\n> > + * If the timestamp order of different files cross the revision order\n> > + within the commit matching time window\n> \n> Reading this, I kept waiting for the \"then\" to your \"if\". I think the\n> implication is \"your import will be incorrect\". But it would be nice to\n> say _how_, even if it's something as simple as \"changes may show up in\n> the wrong commit, the wrong branch, be omitted\" or whatever. Just give a\n> general idea of what can happen.\n\nYou are right, I actually wanted to update my patch but as I've seen\ntoday my patch already made it into master. So I guess I will prepare an\nupdate patch to address these issues.\n\n> \n> Also, this renders somewhat poorly in the manpage version. I get:\n> \n> \n> ISSUES\n> Problems related to timestamps:\n> \n> \n> · If timestamps of commits in the cvs repository are not stable\n> enough to be used for ordering commits\n> \n> · If any files were ever \"cvs import\"ed more than once (e.g., import\n> of more than one vendor release)\n> \n> · If the timestamp order of different files cross the revision order\n> within the commit matching time window\n> Problems related to branches:\n> \n> \n> · Branches on which no commits have been made are not imported\n> \n> \n> Note the extra blank line between each heading and its list, and the\n> lack of a blank line between the end of the first list and the heading\n> of the second. Your source is very readable, so it really is just\n> asciidoc being silly, but I wonder if there is a way to work around\n> that.\n\nMy xmlto is not working at the moment. I will check that.\n"},{"id":"109953","messageId":"7v4oxaa506.fsf@gitster.siamese.dyndns.org","threadId":"18493","inReplyTo":"20090330223646.GC68118@macbook.lan","subject":"Re: [PATCH] Add warning about known issues to documentation of cvsimport","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-31T00:51:53Z","receivedAt":"2009-03-31T00:51:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt writes:\n\n> On Mon, Mar 23, 2009 at 11:14:48PM -0400, Jeff King was talking about:\n>> On Mon, Mar 23, 2009 at 08:53:05PM +0100, Heiko Voigt wrote:\n>> \n>> > The described issues are compiled from the tests by Michael Haggerty and me.\n>> > Because it is not apparent that these can be fixed anytime soon at least warn\n>> > unwary users not to rely on the inbuilt cvsimport to much.\n>> \n>> I think this change is good in concept.\n>> \n>> > +[[issues]]\n>> > +ISSUES\n>> > +------\n>> > +Problems related to timestamps:\n>> > +\n>> > + * If timestamps of commits in the cvs repository are not stable enough\n>> > + to be used for ordering commits\n>> > + * If any files were ever \"cvs import\"ed more than once (e.g., import of\n>> > + more than one vendor release)\n>> > + * If the timestamp order of different files cross the revision order\n>> > + within the commit matching time window\n>> \n>> Reading this, I kept waiting for the \"then\" to your \"if\". I think the\n>> implication is \"your import will be incorrect\". But it would be nice to\n>> say _how_, even if it's something as simple as \"changes may show up in\n>> the wrong commit, the wrong branch, be omitted\" or whatever. Just give a\n>> general idea of what can happen.\n>\n> You are right, I actually wanted to update my patch but as I've seen\n> today my patch already made it into master. So I guess I will prepare an\n> update patch to address these issues.\n\nThanks.\n"},{"id":"109965","messageId":"49D1ABD0.8070707@pelagic.nl","threadId":"18493","inReplyTo":"20090330221729.GB68118@macbook.lan","subject":"Re: [PATCH] Add warning about known issues to documentation of cvsimport","fromName":"Ferry Huberts (Pelagic)","fromEmail":"ferry.huberts@pelagic.nl","sentAt":"2009-03-31T05:36:16Z","receivedAt":"2009-03-31T05:36:16Z","isPatch":true,"sender":{"key":"ferry.huberts@pelagic.nl","avatar":"https://gravatar.com/avatar/9f63c0289ad23cbdef0f7609a0af85ff0f4b3babfd066de9ff58f62d48cfd6f2?d=mp&s=160"},"body":"Heiko Voigt wrote:\n> On Mon, Mar 23, 2009 at 09:33:55PM +0100, Ferry Huberts (Pelagic) wrote:\n>> maybe you can also add remarks about autocrlf and safecrlf?\n>> both need to be off\n> \n> From my experience thats not necessarily true. You can use\n> autocrlf=input to repair broken revisions were crlf's have been\n> mistakenly committed into the repository. And if I remember correctly\n> safecrlf helps if you want to make sure that no information gets lost.\n> \n> So when importing from a nice correct cvs repository you would expect\n> safecrlf to not stop your import. And I suspect there are actually cvs\n> users that were very careful with their lineendings who would use it.\n> \n> cheers Heiko\nIf you look at this thread:\nhttp://thread.gmane.org/gmane.comp.version-control.git/110152/focus=110358\nyou'll see why I said it. I did some testing to prove my statement.\n\nFerry\n"},{"id":"110001","messageId":"20090331112812.GA2090@coredump.intra.peff.net","threadId":"18493","inReplyTo":"20090330223646.GC68118@macbook.lan","subject":"Re: [PATCH] Add warning about known issues to documentation of cvsimport","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-03-31T11:28:12Z","receivedAt":"2009-03-31T11:28:12Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 31, 2009 at 12:36:46AM +0200, Heiko Voigt wrote:\n\n> > Note the extra blank line between each heading and its list, and the\n> > lack of a blank line between the end of the first list and the heading\n> > of the second. Your source is very readable, so it really is just\n> > asciidoc being silly, but I wonder if there is a way to work around\n> > that.\n> \n> My xmlto is not working at the moment. I will check that.\n\nI looked into it a little more; it happens all over the place, so it is\na problem somewhere in the documentation toolchain. So don't worry about\nit for this particular patch.\n\n-Peff\n"},{"id":"110026","messageId":"20090331162103.GA72569@macbook.lan","threadId":"18493","inReplyTo":"49D1ABD0.8070707@pelagic.nl","subject":"Re: [PATCH] Add warning about known issues to documentation of cvsimport","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2009-03-31T16:22:18Z","receivedAt":"2009-03-31T16:22:18Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Tue, Mar 31, 2009 at 07:36:16AM +0200, Ferry Huberts (Pelagic) wrote:\n> Heiko Voigt wrote:\n> > On Mon, Mar 23, 2009 at 09:33:55PM +0100, Ferry Huberts (Pelagic) wrote:\n> >> maybe you can also add remarks about autocrlf and safecrlf?\n> >> both need to be off\n> > \n> > From my experience thats not necessarily true. You can use\n> > autocrlf=input to repair broken revisions were crlf's have been\n> > mistakenly committed into the repository. And if I remember correctly\n> > safecrlf helps if you want to make sure that no information gets lost.\n> > \n> > So when importing from a nice correct cvs repository you would expect\n> > safecrlf to not stop your import. And I suspect there are actually cvs\n> > users that were very careful with their lineendings who would use it.\n> > \n> > cheers Heiko\n> If you look at this thread:\n> http://thread.gmane.org/gmane.comp.version-control.git/110152/focus=110358\n> you'll see why I said it. I did some testing to prove my statement.\n\nWell, from that thread I see my statement supported. It is not true that\nthey *need* to be off. Maybe a statement that certain crlf settings are\nexclusive would be good, but I agree that should go into the config\ndocumentation.\n\nThe main point I see here is that the User may not be aware that such a\nconversion is applied so something like this could help.\n\ncheers Heiko\n\ndiff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt\nindex e1fd047..d4e7fd4 100644\n--- a/Documentation/git-cvsimport.txt\n+++ b/Documentation/git-cvsimport.txt\n@@ -40,6 +40,11 @@ probably want to make a bare clone of the imported repository\n and use the clone as the shared repository.\n See linkgit:gitcvs-migration[7].\n \n+Note: All revisions are imported using the index so settings of\n+core.autocrlf and core.safecrlf are applied. This way you can change or\n+safety check the import. If you do not want this make sure these options\n+are both set to false.\n+\n \n OPTIONS\n -------\n"},{"id":"110033","messageId":"20090331164503.GB72569@macbook.lan","threadId":"18493","inReplyTo":"7v4oxaa506.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] Cleanup warning about known issues in cvsimport documentation","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2009-03-31T16:45:03Z","receivedAt":"2009-03-31T16:45:03Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Not all statements were complete sentences.\n\nSigned-off-by: Heiko Voigt \n---\n Documentation/git-cvsimport.txt | 20 +++++++++++---------\n 1 files changed, 11 insertions(+), 9 deletions(-)\n\ndiff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt\nindex e1fd047..ba6a50b 100644\n--- a/Documentation/git-cvsimport.txt\n+++ b/Documentation/git-cvsimport.txt\n@@ -173,24 +173,26 @@ ISSUES\n Problems related to timestamps:\n \n * If timestamps of commits in the cvs repository are not stable enough\n- to be used for ordering commits\n+ to be used for ordering commits changes may show up in the wrong\n+ order.\n * If any files were ever \"cvs import\"ed more than once (e.g., import of\n- more than one vendor release)\n+ more than one vendor release) the HEAD will be incorrect.\n * If the timestamp order of different files cross the revision order\n- within the commit matching time window\n+ within the commit matching time window the order of commits may be\n+ wrong.\n \n Problems related to branches:\n \n- * Branches on which no commits have been made are not imported\n+ * Branches on which no commits have been made are not imported.\n * All files from the branching point are added to a branch even if\n- never added in cvs\n- * files added to the source branch *after* a daughter branch was\n- created: If previously no commit was made on the daugther branch they\n- will erroneously be added to the daughter branch in git\n+ never added in cvs.\n+ * This applies to files added to the source branch *after* a daughter\n+ branch was created: If previously no commit was made on the daugther\n+ branch they will erroneously be added to the daughter branch in git.\n \n Problems related to tags:\n \n-* Multiple tags on the same revision are not imported\n+* Multiple tags on the same revision are not imported.\n \n If you suspect that any of these issues may apply to the repository you\n want to import consider using these alternative tools which proved to be\n-- \n1.6.1.2.390.gba743\n"},{"id":"110034","messageId":"20090331165339.GC72569@macbook.lan","threadId":"18493","inReplyTo":"20090331162103.GA72569@macbook.lan","subject":"[PATCH] cvsimport: Add a note about crlf options to the documentation","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2009-03-31T16:53:39Z","receivedAt":"2009-03-31T16:53:39Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"---\nThis is a proper resend of the crlf note patch for Junio's import convenience\n\n Documentation/git-cvsimport.txt | 5 +++++\n 1 files changed, 5 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt\nindex e1fd047..d4e7fd4 100644\n--- a/Documentation/git-cvsimport.txt\n+++ b/Documentation/git-cvsimport.txt\n@@ -40,6 +40,11 @@ probably want to make a bare clone of the imported repository,\n and use the clone as the shared repository.\n See linkgit:gitcvs-migration[7].\n \n+Note: All revisions are imported using the index so settings of\n+core.autocrlf and core.safecrlf are applied. This way you can change or\n+safety check the import. If you do not want this make sure these options\n+are both set to false.\n+\n \n OPTIONS\n -------\n-- \n1.6.1.2.390.gba743\n"},{"id":"110037","messageId":"49D24E76.60904@pelagic.nl","threadId":"18493","inReplyTo":"20090331162103.GA72569@macbook.lan","subject":"Re: [PATCH] Add warning about known issues to documentation of cvsimport","fromName":"Ferry Huberts (Pelagic)","fromEmail":"ferry.huberts@pelagic.nl","sentAt":"2009-03-31T17:10:14Z","receivedAt":"2009-03-31T17:10:14Z","isPatch":true,"sender":{"key":"ferry.huberts@pelagic.nl","avatar":"https://gravatar.com/avatar/9f63c0289ad23cbdef0f7609a0af85ff0f4b3babfd066de9ff58f62d48cfd6f2?d=mp&s=160"},"body":"Heiko Voigt wrote:\n> On Tue, Mar 31, 2009 at 07:36:16AM +0200, Ferry Huberts (Pelagic) wrote:\n>> Heiko Voigt wrote:\n>>> On Mon, Mar 23, 2009 at 09:33:55PM +0100, Ferry Huberts (Pelagic) wrote:\n>>>> maybe you can also add remarks about autocrlf and safecrlf?\n>>>> both need to be off\n>>> From my experience thats not necessarily true. You can use\n>>> autocrlf=input to repair broken revisions were crlf's have been\n>>> mistakenly committed into the repository. And if I remember correctly\n>>> safecrlf helps if you want to make sure that no information gets lost.\n>>>\n>>> So when importing from a nice correct cvs repository you would expect\n>>> safecrlf to not stop your import. And I suspect there are actually cvs\n>>> users that were very careful with their lineendings who would use it.\n>>>\n>>> cheers Heiko\n>> If you look at this thread:\n>> http://thread.gmane.org/gmane.comp.version-control.git/110152/focus=110358\n>> you'll see why I said it. I did some testing to prove my statement.\n> \n> Well, from that thread I see my statement supported. It is not true that\n> they *need* to be off. Maybe a statement that certain crlf settings are\n> exclusive would be good, but I agree that should go into the config\n> documentation.\n> \n> The main point I see here is that the User may not be aware that such a\n> conversion is applied so something like this could help.\n> \n> cheers Heiko\n> \n> diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt\n> index e1fd047..d4e7fd4 100644\n> --- a/Documentation/git-cvsimport.txt\n> +++ b/Documentation/git-cvsimport.txt\n> @@ -40,6 +40,11 @@ probably want to make a bare clone of the imported repository\n> and use the clone as the shared repository.\n> See linkgit:gitcvs-migration[7].\n> \n> +Note: All revisions are imported using the index so settings of\n> +core.autocrlf and core.safecrlf are applied. This way you can change or\n> +safety check the import. If you do not want this make sure these options\n> +are both set to false.\n> +\n> \n\nI can agree with this. However,\nI still think that this is too weak a statement and a bit too cryptic:\nthe import will/can actually fail when a crlf conversion is performed,\neven though safecrlf is not set to true. At least that was the case I\nwas talking about in the thread. I don't know the current situation, I\nhaven't tried it since 'cause I just use it with both set to false :-)\nI discussed a patch for this but never got around to implementing it\nsince I'm now busy with ignore functionality for EGit.\n\ncheers.\n\nFerry\n"},{"id":"110052","messageId":"20090331194056.GA23102@coredump.intra.peff.net","threadId":"18493","inReplyTo":"20090331112812.GA2090@coredump.intra.peff.net","subject":"Re: [PATCH] Add warning about known issues to documentation of cvsimport","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-03-31T19:40:56Z","receivedAt":"2009-03-31T19:40:56Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 31, 2009 at 07:28:12AM -0400, Jeff King wrote:\n\n> On Tue, Mar 31, 2009 at 12:36:46AM +0200, Heiko Voigt wrote:\n> \n> > > Note the extra blank line between each heading and its list, and the\n> > > lack of a blank line between the end of the first list and the heading\n> > > of the second. Your source is very readable, so it really is just\n> > > asciidoc being silly, but I wonder if there is a way to work around\n> > > that.\n> > \n> > My xmlto is not working at the moment. I will check that.\n> \n> I looked into it a little more; it happens all over the place, so it is\n> a problem somewhere in the documentation toolchain. So don't worry about\n> it for this particular patch.\n\nI looked into it more and posted to the docbook-apps list. Here's what\nI found out: the problem is fixed in docbook-xsl 1.74.3. However, our\ntemplate to prevent extra .sp in manpage-base.xml prevents it.\n\nThat fix is in 7ef0435 (spurious .sp in manpages, 2006-12-13), and I get\ngood output by reverting it and using docbook 1.74.3.\n\nGoing back to the original discussion, it looks like it is a workaround\nfor docbook-xsl 1.69.0:\n\n http://article.gmane.org/gmane.comp.version-control.git/32957\n\nAssuming that is correct, I think the sane choices are:\n\n 1. drop the workaround, as that version of docbook-xsl is now several\n years old\n\n or\n\n 2. turn the workaround off by default, but add a knob to turn it on\n (DOCBOOK_XSL_1690?)\n\nHaving it on by default and turning it off with a knob seems silly,\nsince most versions don't need it. Debian stable is shipping 1.73 these\ndays, which looks fine without 7ef0435. Are there other platforms still\nshipping 1.69.0? Is it too old for us to care?\n\n-Peff\n"},{"id":"110055","messageId":"20090331194940.GB23184@coredump.intra.peff.net","threadId":"18493","inReplyTo":"20090331164503.GB72569@macbook.lan","subject":"Re: [PATCH] Cleanup warning about known issues in cvsimport documentation","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-03-31T19:49:40Z","receivedAt":"2009-03-31T19:49:40Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 31, 2009 at 06:45:03PM +0200, Heiko Voigt wrote:\n\n> Not all statements were complete sentences.\n\nThanks, this is looking much better. A few minor comments:\n\n> * If any files were ever \"cvs import\"ed more than once (e.g., import of\n> - more than one vendor release)\n> + more than one vendor release) the HEAD will be incorrect.\n\nIncorrect how? I assume \"contains the wrong content\".\n\n> + * This applies to files added to the source branch *after* a daughter\n> + branch was created: If previously no commit was made on the daugther\n> + branch they will erroneously be added to the daughter branch in git.\n\ns/If/if/, s/daugther/daughter/\n\nOther than that, looks good to me.\n\n-Peff\n"},{"id":"110083","messageId":"7vljql4586.fsf@gitster.siamese.dyndns.org","threadId":"18493","inReplyTo":"20090331194056.GA23102@coredump.intra.peff.net","subject":"Re: [PATCH] Add warning about known issues to documentation of cvsimport","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-31T23:55:53Z","receivedAt":"2009-03-31T23:55:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Going back to the original discussion, it looks like it is a workaround\n> for docbook-xsl 1.69.0:\n>\n> http://article.gmane.org/gmane.comp.version-control.git/32957\n>\n> Assuming that is correct, I think the sane choices are:\n>\n> 1. drop the workaround, as that version of docbook-xsl is now several\n> years old\n>\n> or\n>\n> 2. turn the workaround off by default, but add a knob to turn it on\n> (DOCBOOK_XSL_1690?)\n>\n> Having it on by default and turning it off with a knob seems silly,\n> since most versions don't need it. Debian stable is shipping 1.73 these\n> days, which looks fine without 7ef0435. Are there other platforms still\n> shipping 1.69.0? Is it too old for us to care?\n\nI am very tempted to say 1. but we seem to have a track record of trying\nto be nice to people. How involved would 2 be compared to 1?\n"},{"id":"110108","messageId":"1238575834-17838-1-git-send-email-chris_johnsen@pobox.com","threadId":"18493","inReplyTo":"7vljql4586.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] Documentation: use \"spurious .sp\" XSLT if DOCBOOK_SUPPRESS_SP is set","fromName":"Chris Johnsen","fromEmail":"chris_johnsen@pobox.com","sentAt":"2009-04-01T08:50:34Z","receivedAt":"2009-04-01T08:50:34Z","isPatch":true,"sender":{"key":"chris_johnsen@pobox.com","avatar":"https://avatars.githubusercontent.com/u/107071?v=4"},"body":"With this change, the \"spurious .sp\" suppression XSLT code is\ndisabled by default. It can be enabled by defining\nDOCBOOK_SUPPRESS_SP.\n\nThe \"spurious .sp\" XSLT fragment was used to work around a bug\nfirst released in docbook-xsl 1.69.1. Modern versions of\ndocbook-xsl are negatively affected by the code (some empty lines\nare omitted from manpage output; see\n).\n\nThe key revisions in the docbook SVN repo seem to be 5144 (before\ndocbook-xsl 1.69.1) and 6359 (before docbook-xsl 1.71.1).\n\nTesting done with asciidoc 8.3.1 and docbook-xsl 1.74.0.\n\nSigned-off-by: Chris Johnsen \n\n---\n\nHere is a proof-of-concept. It is on top of next (it requires the\nprevious XSLT/asciidoc cleanup).\n\nI went with a \"feature knob\" instead of a \"version knob\" since my\nresearch in the docbook SVN repo indicates that multiple versions\nare affected. Maybe the name could be better. Also I am not at\nall sure that my research into past docbook-xsl releases is 100%\naccurate. Anyone motivated enough to install old versions of\ndocbook-xsl and test with them?\n\nThe message that Peff cites\n()\nseems to indicate that the \"spurious .sp\" problem was injected\n_between_ 1.69.0 and 1.69.1. So, I did some research in the\ndocbook SVN repo.\n\nI grepped for \".sp\" and \"simpara\" in\n\nto find likely interesting spots (sure, not thorough, but I hoped\nto get lucky). Then I slogged through the \"tags\" directory to\nfind out when in the revision stream docbook-xsl releases seemed\nto have been cut.\n\nHere are some of the \"interesting\" revision numbers:\n\n5119 1.69.0\n5144 .sp instead of blank line in mixed blocks\n5152 1.69.1\n5755 newline before .sp in verbatims (not simpara)\n5985 1.70.0\n6003 1.70.1\n6166 suppress .sp inside {author,person}blurb\n6279 1.71.0\n6359 newline before .sp in simpara\n6373 1.71.1\n6552 1.72.0\n...\n7398 1.73.2\n no tags for 1.74.*?\n7782 move .sp to before, not after simpara text\n7844 suppress .sp inside callout\n? 1.74.0 {relnotes include descriptions of 7782 and 7844}\n\nBefore I got tired of digging through the SVN history, it seemed\nto me that the problematic \".sp\" was introduced at 5144 and\nresolved at 6359. The code in Git's XSLT is very similar to that\nof revision 6359, lines 81-91 (with a double newline instead of a\nproperly positioned \".sp\" command).\n\nSo, it seems that the \"spurious .sp\" problem that Git's simpara\ntemplate \"fixes\" is not present in docbook-xsl 1.69.0, but is\npresent in 1.69.1, 1.70.0, 1.70.1, and 1.71.0. The \"spurious .sp\"\nmight not be present in 1.69.0 and earlier, but I would guess\nthat there are still line spacing issues there.\n\nShould more of this background info be in the commit message?\nLess?\n---\n Documentation/Makefile | 7 ++++++-\n Documentation/manpage-base.xsl | 13 -------------\n Documentation/manpage-suppress-sp.xsl | 21 +++++++++++++++++++++\n 3 files changed, 27 insertions(+), 14 deletions(-)\n create mode 100644 Documentation/manpage-suppress-sp.xsl\n\ndiff --git a/Documentation/Makefile b/Documentation/Makefile\nindex dae3174..dba97dc 100644\n--- a/Documentation/Makefile\n+++ b/Documentation/Makefile\n@@ -69,7 +69,9 @@ endif\n #\n # For docbook-xsl ...\n #\t-1.68.1,\tset ASCIIDOC_NO_ROFF? (based on changelog from 1.73.0)\n-#\t1.69.0-1.71.1,\tno extra settings are needed?\n+#\t1.69.0,\t\tno extra settings are needed?\n+#\t1.69.1-1.71.0,\tset DOCBOOK_SUPPRESS_SP?\n+#\t1.71.1,\t\tno extra settings are needed?\n #\t1.72.0,\t\tset DOCBOOK_XSL_172.\n #\t1.73.0-,\tset ASCIIDOC_NO_ROFF\n #\n@@ -97,6 +99,9 @@ endif\n ifdef MAN_BOLD_LITERAL\n XMLTO_EXTRA += -m manpage-bold-literal.xsl\n endif\n+ifdef DOCBOOK_SUPPRESS_SP\n+XMLTO_EXTRA += -m manpage-suppress-sp.xsl\n+endif\n \n #\n # Please note that there is a minor bug in asciidoc.\ndiff --git a/Documentation/manpage-base.xsl b/Documentation/manpage-base.xsl\nindex 16e2e40..a264fa6 100644\n--- a/Documentation/manpage-base.xsl\n+++ b/Documentation/manpage-base.xsl\n@@ -32,17 +32,4 @@\n \tbr \n \n \n-\n-\n- \n- \n- \n- \n- \n- \n- \n-\n-\n \ndiff --git a/Documentation/manpage-suppress-sp.xsl b/Documentation/manpage-suppress-sp.xsl\nnew file mode 100644\nindex 0000000..a63c763\n--- /dev/null\n+++ b/Documentation/manpage-suppress-sp.xsl\n@@ -0,0 +1,21 @@\n+\n+\n+\n+\n+\n+ \n+ \n+ \n+ \n+ \n+ \n+ \n+\n+\n+\n-- \n1.6.2.1.556.g581a3\n"},{"id":"110115","messageId":"20090401101400.GA26181@coredump.intra.peff.net","threadId":"18493","inReplyTo":"1238575834-17838-1-git-send-email-chris_johnsen@pobox.com","subject":"Re: [PATCH] Documentation: use \"spurious .sp\" XSLT if DOCBOOK_SUPPRESS_SP is set","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-04-01T10:14:00Z","receivedAt":"2009-04-01T10:14:00Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 01, 2009 at 03:50:34AM -0500, Chris Johnsen wrote:\n\n> With this change, the \"spurious .sp\" suppression XSLT code is\n> disabled by default. It can be enabled by defining\n> DOCBOOK_SUPPRESS_SP.\n> [...]\n> Signed-off-by: Chris Johnsen \n\nAcked-by: Jeff King \n\nThis looks good to me. Thank you for being so thorough in both the\nresearch and implementation, especially when I was being so lazy. :)\n\n> I went with a \"feature knob\" instead of a \"version knob\" since my\n> research in the docbook SVN repo indicates that multiple versions\n> are affected. Maybe the name could be better. Also I am not at\n> all sure that my research into past docbook-xsl releases is 100%\n> accurate. Anyone motivated enough to install old versions of\n> docbook-xsl and test with them?\n\nI think the \"feature knob\" makes sense. I don't know that it is worth\nextensive testing with old releases. You have a pretty good guess about\nwhich versions are affected, and people who experience the problem can\nturn the knob. Your Makefile comments make it easy for them find the\nknob once they see the breakage.\n\nIt is probably worth mentioning in the release notes to give a heads-up,\nthough.\n\nSomething like:\n\n-- >8 --\nSubject: mention docbook knob in the release notes\n\nPeople with ancient docbook-xsl will see the return of the \"spurious\n.sp\" unless this knob is turned, so let's inform them.\n\n---\ndiff --git a/Documentation/RelNotes-1.6.3.txt b/Documentation/RelNotes-1.6.3.txt\nindex f0a2e41..0c8a14e 100644\n--- a/Documentation/RelNotes-1.6.3.txt\n+++ b/Documentation/RelNotes-1.6.3.txt\n@@ -107,6 +107,11 @@ Updates since v1.6.2\n * Makefile learned 'coverage' option to run the test suites with\n coverage tracking enabled.\n \n+* Building the manpages with docbook-xsl between 1.69.1 and 1.71.1 now\n+ requires setting DOCBOOK_SUPPRESS_SP to work around a docbook-xsl bug.\n+ This workaround used to be enabled by default, but causes problems\n+ with newer versions of docbook-xsl.\n+\n Fixes since v1.6.2\n ------------------\n \n"},{"id":"110119","messageId":"20090401103442.GD26181@coredump.intra.peff.net","threadId":"18493","inReplyTo":"1238575834-17838-1-git-send-email-chris_johnsen@pobox.com","subject":"Re: [PATCH] Documentation: use \"spurious .sp\" XSLT if DOCBOOK_SUPPRESS_SP is set","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-04-01T10:34:42Z","receivedAt":"2009-04-01T10:34:42Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 01, 2009 at 03:50:34AM -0500, Chris Johnsen wrote:\n\n> The key revisions in the docbook SVN repo seem to be 5144 (before\n> docbook-xsl 1.69.1) and 6359 (before docbook-xsl 1.71.1).\n> \n> Testing done with asciidoc 8.3.1 and docbook-xsl 1.74.0.\n\nIn the course of your SVN research, did you find the fixes between\n1.73.1 and 1.74.3 that fixed the spacing issue? If so, I wonder if it's\nworth backporting that fix to DOCBOOK_FIX_LIST_SPACING.\n\n-Peff\n"},{"id":"110127","messageId":"DDA1F213-D15C-49B3-90CB-557F9A465A6A@pobox.com","threadId":"18493","inReplyTo":"20090401103442.GD26181@coredump.intra.peff.net","subject":"Re: [PATCH] Documentation: use \"spurious .sp\" XSLT if DOCBOOK_SUPPRESS_SP is set","fromName":"Chris Johnsen","fromEmail":"chris_johnsen@pobox.com","sentAt":"2009-04-01T12:19:08Z","receivedAt":"2009-04-01T12:19:08Z","isPatch":true,"sender":{"key":"chris_johnsen@pobox.com","avatar":"https://avatars.githubusercontent.com/u/107071?v=4"},"body":"On 2009 Apr 1, at 05:34, Jeff King wrote:\n> On Wed, Apr 01, 2009 at 03:50:34AM -0500, Chris Johnsen wrote:\n>\n>> The key revisions in the docbook SVN repo seem to be 5144 (before\n>> docbook-xsl 1.69.1) and 6359 (before docbook-xsl 1.71.1).\n>>\n>> Testing done with asciidoc 8.3.1 and docbook-xsl 1.74.0.\n>\n> In the course of your SVN research, did you find the fixes between\n> 1.73.1 and 1.74.3 that fixed the spacing issue? If so, I wonder if \n> it's\n> worth backporting that fix to DOCBOOK_FIX_LIST_SPACING.\n\nI guess you are referring to an issue different from the one created \nby using the \"spurious .sp\" simpara template, but I am not familiar \nwith another one. If not, then I am confused. The new patch to avoid \nusing the \"spurious .sp\" template fixes the list spacing in pu's git- \ncvsimport.1 when I generate it here (using docbook-xsl 1.74.0). For \nexample, the extra blank line after \"Problems related to timestamps:\" \ngoes away and a new blank line is inserted before \"Problems related \nto branches:\".\n\nMy poking around in the docbook SVN repo was largely limited to the \nmanpages/block.xsl file since that is where the normal simpara \ntemplate lives. If this other issue is list specific, it seems likely \nthat fixes would be in manpages/lists.xsl. It looks like there have \nonly been around ten commits to that lists.xsl since 1.73.1, but none \nof them jumped out at me as likely culprits unless the spacing you \nmean is indentation or \"bullet\"-to-text spacing (though my brain is \ntired right now).\n\n-- \nChris\n"},{"id":"110140","messageId":"20090401130636.GA29113@coredump.intra.peff.net","threadId":"18493","inReplyTo":"DDA1F213-D15C-49B3-90CB-557F9A465A6A@pobox.com","subject":"Re: [PATCH] Documentation: use \"spurious .sp\" XSLT if DOCBOOK_SUPPRESS_SP is set","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-04-01T13:06:36Z","receivedAt":"2009-04-01T13:06:36Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 01, 2009 at 07:19:08AM -0500, Chris Johnsen wrote:\n\n>> In the course of your SVN research, did you find the fixes between\n>> 1.73.1 and 1.74.3 that fixed the spacing issue? If so, I wonder if it's\n>> worth backporting that fix to DOCBOOK_FIX_LIST_SPACING.\n>\n> I guess you are referring to an issue different from the one created by \n> using the \"spurious .sp\" simpara template, but I am not familiar with \n> another one. If not, then I am confused. The new patch to avoid using the \n> \"spurious .sp\" template fixes the list spacing in pu's git-cvsimport.1 \n> when I generate it here (using docbook-xsl 1.74.0). For example, the extra \n> blank line after \"Problems related to timestamps:\" goes away and a new \n> blank line is inserted before \"Problems related to branches:\".\n\nSorry, I should have been more clear (it seems we have enough docbook\nproblems to cause confusion in referring to them :) ). What I meant is:\n\n The original issue which caused me to investigate this, namely the\n extra blank line before a list and the missing blank line after the\n list, is present in 1.73 but not in 1.74 (I tested only with 1.74.3,\n but your statement above leads me to believe it is fixed in 1.74.0).\n\n Is it worth including a fix in our docbook templates to make it look\n right for people on 1.73?\n\n> My poking around in the docbook SVN repo was largely limited to the \n> manpages/block.xsl file since that is where the normal simpara template \n> lives. If this other issue is list specific, it seems likely that fixes \n> would be in manpages/lists.xsl. It looks like there have only been around \n> ten commits to that lists.xsl since 1.73.1, but none of them jumped out at \n> me as likely culprits unless the spacing you mean is indentation or \n> \"bullet\"-to-text spacing (though my brain is tired right now).\n\nHmm. I think part of the fix is actually in param.xsl, which contains:\n\n \n \n\nin 1.74, but not 1.73.\n\nI am torn on whether it makes sense to try backporting this. Debian\nstable, at least, will be on 1.73 for quite a long time. On the other\nhand, the problem is relatively minor (it is ugly, but you can still\nread the text) and I'm not sure we want to get into pulling random fixes\nfrom upstream docbook-xsl; it could turn into a huge time sink.\n\n-Peff\n"},{"id":"110163","messageId":"20090401202415.GA90837@macbook.lan","threadId":"18493","inReplyTo":"20090331194940.GB23184@coredump.intra.peff.net","subject":"[PATCH v2] Cleanup warning about known issues in cvsimport documentation","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2009-04-01T20:24:28Z","receivedAt":"2009-04-01T20:24:28Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Not all statements were complete sentences.\n\nSigned-off-by: Heiko Voigt \n---\n\nI corrected the typos. This is the interdiff:\n\n diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt\n index ba6a50b..d7bab13 100644\n --- a/Documentation/git-cvsimport.txt\n +++ b/Documentation/git-cvsimport.txt\n @@ -176,7 +176,7 @@ Problems related to timestamps:\n to be used for ordering commits changes may show up in the wrong\n order.\n * If any files were ever \"cvs import\"ed more than once (e.g., import of\n - more than one vendor release) the HEAD will be incorrect.\n + more than one vendor release) the HEAD contains the wrong content.\n * If the timestamp order of different files cross the revision order\n within the commit matching time window the order of commits may be\n wrong.\n @@ -187,7 +187,7 @@ Problems related to branches:\n * All files from the branching point are added to a branch even if\n never added in cvs.\n * This applies to files added to the source branch *after* a daughter\n - branch was created: If previously no commit was made on the daugther\n + branch was created: if previously no commit was made on the daughter\n branch they will erroneously be added to the daughter branch in git.\n \n Problems related to tags:\n\n\n Documentation/git-cvsimport.txt | 20 +++++++++++---------\n 1 files changed, 11 insertions(+), 9 deletions(-)\n\ndiff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt\nindex e1fd047..d7bab13 100644\n--- a/Documentation/git-cvsimport.txt\n+++ b/Documentation/git-cvsimport.txt\n@@ -173,24 +173,26 @@ ISSUES\n Problems related to timestamps:\n \n * If timestamps of commits in the cvs repository are not stable enough\n- to be used for ordering commits\n+ to be used for ordering commits changes may show up in the wrong\n+ order.\n * If any files were ever \"cvs import\"ed more than once (e.g., import of\n- more than one vendor release)\n+ more than one vendor release) the HEAD contains the wrong content.\n * If the timestamp order of different files cross the revision order\n- within the commit matching time window\n+ within the commit matching time window the order of commits may be\n+ wrong.\n \n Problems related to branches:\n \n- * Branches on which no commits have been made are not imported\n+ * Branches on which no commits have been made are not imported.\n * All files from the branching point are added to a branch even if\n- never added in cvs\n- * files added to the source branch *after* a daughter branch was\n- created: If previously no commit was made on the daugther branch they\n- will erroneously be added to the daughter branch in git\n+ never added in cvs.\n+ * This applies to files added to the source branch *after* a daughter\n+ branch was created: if previously no commit was made on the daughter\n+ branch they will erroneously be added to the daughter branch in git.\n \n Problems related to tags:\n \n-* Multiple tags on the same revision are not imported\n+* Multiple tags on the same revision are not imported.\n \n If you suspect that any of these issues may apply to the repository you\n want to import consider using these alternative tools which proved to be\n-- \n1.6.2.1.424.g0b27.dirty\n"},{"id":"110192","messageId":"7veiwbk4pe.fsf@gitster.siamese.dyndns.org","threadId":"18493","inReplyTo":"20090401101400.GA26181@coredump.intra.peff.net","subject":"Re: [PATCH] Documentation: use \"spurious .sp\" XSLT if DOCBOOK_SUPPRESS_SP is set","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-02T05:25:01Z","receivedAt":"2009-04-02T05:25:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I think the \"feature knob\" makes sense. I don't know that it is worth\n> extensive testing with old releases. You have a pretty good guess about\n> which versions are affected, and people who experience the problem can\n> turn the knob. Your Makefile comments make it easy for them find the\n> knob once they see the breakage.\n>\n> It is probably worth mentioning in the release notes to give a heads-up,\n> though.\n\nThanks.\n"}]}