Please revert e371046b6473907aa6d62b7862a3afe9d33561e1
I've spoken to the author of this commit, Matthias Urlichs. Here is an excerpt of our conversation:
Quoted 8 lines · John Wiegley
Quoted 3 lines
Just wanted to let you know that this bit me. I have a client whose CVS repository I'm converting to Git, and they have _many_ log messages that are larger than 32k in size.
Feel free to submit a patch that reverts this. These days, there's probably no user of cvs2git left, but at that time it was important to get the same commit IDs back.
This just needs to be reverted:
git revert e371046b6473907aa6d62b7862a3afe9d33561e1
Thanks,
John
Quoted 8 lines · John Wiegley
I've spoken to the author of this commit, Matthias Urlichs. Here is an excerpt of our conversation:
Quoted 5 lines · John Wiegley
Quoted 3 lines
Just wanted to let you know that this bit me. I have a client whose CVS repository I'm converting to Git, and they have _many_ log messages that are larger than 32k in size.
Quoted 7 lines
Quoted 3 lines
Feel free to submit a patch that reverts this. These days, there's probably no user of cvs2git left, but at that time it was important to get the same commit IDs back.
This just needs to be reverted:
git revert e371046b6473907aa6d62b7862a3afe9d33561e1
That ancient commit does two things, and one thing that it claims to do does not have anything to do with 32k limit.
Please send in a patch that exactly addresses the issue (it is unclear if you want to keep or drop the removal of trailing whitespaces that is done by that commit). The proposed log message needs to justify why breaking other people's repositories that were converted by an ancient version of cvs2git is lessor of two evils (the other one being logs longer than 32k are not kept for you).
Thanks.
Quoted 10 lines · John Wiegley
I've spoken to the author of this commit, Matthias Urlichs. Here is an excerpt of our conversation:
Quoted 7 lines · John Wiegley
Quoted 3 lines
Just wanted to let you know that this bit me. I have a client whose CVS repository I'm converting to Git, and they have _many_ log messages that are larger than 32k in size.
Feel free to submit a patch that reverts this. These days, there's probably no user of cvs2git left, but at that time it was important to get the same
This assertion is not only wrong, it's just ludicrous. The intended functionality has a statement of intent with regards to its functionality -- and as a user of cvs2git, I'd not want to lose *any* of that functionality.
Don't be stupid with this. Please.
-- Thomas Adam
Quoted 9 lines · Thomas Adam
Quoted 8 lines · John Wiegley
I've spoken to the author of this commit, Matthias Urlichs. Here is an excerpt of our conversation:
Quoted 5 lines · John Wiegley
Quoted 3 lines
Just wanted to let you know that this bit me. I have a client whose CVS repository I'm converting to Git, and they have _many_ log messages that are larger than 32k in size.
Quoted 7 lines
Quoted 2 lines
Quoted 2 lines
Feel free to submit a patch that reverts this. These days, there's probably no user of cvs2git left, but at that time it was important to get the same
This assertion is not only wrong, it's just ludicrous. The intended functionality has a statement of intent with regards to its functionality -- and as a user of cvs2git, I'd not want to lose *any* of that functionality.
I was confused about this conversation. The commit that John Wiegley proposes to revert is from 2005. The "cvs2git" functionality in cvs2svn was not added until 2007. So it must be that commit e371046b64 was added for compatibility with some other cvs2git script (i.e., not the one that is part of the cvs2svn project). Nowadays the only script called "cvs2git" that I ever see mentioned (and I maintain a Google search on that string) is the one from the cvs2svn project. So I assume that the old "cvs2git" script (the one mentioned in commit e371046b64's log message) has died off.
The current cvs2svn-based cvs2git script doesn't have any limitation on the size of log messages and doesn't clean up their whitespace. The only things that it does, in the default configuration, is check that the message is ASCII (if not there are options to reencode it as UTF-8) and convert all EOL sequences into LF.
Therefore I don't believe that there is any reason to preserve the functionality of commit e371046b64 in the name of compatibility with cvs2git.
I have no opinion about whether it makes sense to revert/preserve the commit for other reasons.
Michael
(the cvs2svn/cvs2git maintainer)
Signature · 3 lines
Michael Haggerty [email protected] http://softwareswirl.blogspot.com/
Quoted 18 lines · Michael Haggerty
Quoted 9 lines · Thomas Adam
Quoted 8 lines · John Wiegley
I've spoken to the author of this commit, Matthias Urlichs. Here is an excerpt of our conversation:
Quoted 5 lines · John Wiegley
Quoted 3 lines
Just wanted to let you know that this bit me. I have a client whose CVS repository I'm converting to Git, and they have _many_ log messages that are larger than 32k in size.
Quoted 7 lines
Quoted 2 lines
Quoted 2 lines
Feel free to submit a patch that reverts this. These days, there's probably no user of cvs2git left, but at that time it was important to get the same
This assertion is not only wrong, it's just ludicrous. The intended functionality has a statement of intent with regards to its functionality -- and as a user of cvs2git, I'd not want to lose *any* of that functionality.
Quoted 9 lines
I was confused about this conversation. The commit that John Wiegley proposes to revert is from 2005. The "cvs2git" functionality in cvs2svn was not added until 2007. So it must be that commit
e371046b64was added for compatibility with some other cvs2git script (i.e., not the one that is part of the cvs2svn project). Nowadays the only script called "cvs2git" that I ever see mentioned (and I maintain a Google search on that string) is the one from the cvs2svn project. So I assume that the old "cvs2git" script (the one mentioned in commit e371046b64's log message) has died off.
The way I read the log message of e371046b64 is that the repository resulting from the conversion without this patch will be different for repositories that were originally converted by the older cvs2git. So my impression is that it does not matter if the older tool died long time ago. As long as repositories converted by it still lives in the field, reverting the patch will start producing different (and arguably more correct) results for people who are using such a repository that started its life long time ago.
The potential negative impact is not huge for projects that used cvsimport for a one-time converion, and further developments all happen in git, of course...
Quoted 8 lines · Junio C Hamano
The way I read the log message of
e371046b64is that the repository resulting from the conversion without this patch will be different for repositories that were originally converted by the older cvs2git. So my impression is that it does not matter if the older tool died long time ago. As long as repositories converted by it still lives in the field, reverting the patch will start producing different (and arguably more correct) results for people who are using such a repository that started its life long time ago.
Only if the conversion is restarted from scratch. Otherwise, any existing converted commits are preserved due to the incremental nature of git cvsimport.
Andreas.
Signature · 3 lines
Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Quoted 1 line · Andreas Schwab
Only if the conversion is restarted from scratch.
Yes, that was the use case I was the most worried about.
Often a re-import is one way to validate what you have (and worse yet, what you based your recent work on), so unmatching commit object names are red flags.
Quoted 9 lines · Junio C Hamano
Quoted 1 line · Andreas Schwab
Only if the conversion is restarted from scratch.
Yes, that was the use case I was the most worried about.
Often a re-import is one way to validate what you have (and worse yet, what you based your recent work on), so unmatching commit object names are red flags.
Given the notorious unreliability of cvsps that doesn't look like a very serious change in comparison.
Andreas.
Signature · 3 lines
Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Thomas Adam <[email protected]> writes:
This assertion is not only wrong, it's just ludicrous. The intended functionality has a statement of intent with regards to its functionality -- and as a user of cvs2git, I'd not want to lose *any* of that functionality.
Don't be stupid with this. Please.
My needs would be satisfied with an command-line option that removes the limit, while keeping the status quo unaffected if it's not used. How does that sound?
John