threads / discuss / 30724

Please revert e371046b6473907aa6d62b7862a3afe9d33561e1

Subject: Please revert e371046b6473907aa6d62b7862a3afe9d33561e1

## tl;dr

9 messages between Jun 6, 2012 and Jun 7, 2012.

replies: 8people: 6as markdown or json

John Wiegley· Jun 6, 2012, 10:28 UTC · lore

I've spoken to the author of this commit, Matthias Urlichs. Here is an excerpt of our conversation:

Show 8 quoted lines
> On Sat, 2012-04-21 at 00:08 -0500, John Wiegley wrote:
> > 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
Junio C Hamano· Jun 6, 2012, 17:41 UTC · re: John Wiegley · lore

Re: Please revert e371046b6473907aa6d62b7862a3afe9d33561e1

John Wiegley <jwiegley@gmail.com> writes:
Show 15 quoted lines
> I've spoken to the author of this commit, Matthias Urlichs.  Here is an
> excerpt of our conversation:
>
>> On Sat, 2012-04-21 at 00:08 -0500, John Wiegley wrote:
>> > 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

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.
Thomas Adam· Jun 6, 2012, 17:54 UTC · re: John Wiegley · lore

Re: Please revert e371046b6473907aa6d62b7862a3afe9d33561e1

On 6 June 2012 11:28, John Wiegley <jwiegley@gmail.com> wrote:
Show 10 quoted lines
> I've spoken to the author of this commit, Matthias Urlichs.  Here is an
> excerpt of our conversation:
>
>> On Sat, 2012-04-21 at 00:08 -0500, John Wiegley wrote:
>> > 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
John Wiegley· Jun 6, 2012, 18:26 UTC · re: Thomas Adam · lore

Re: Please revert e371046b6473907aa6d62b7862a3afe9d33561e1

>>>>> Thomas Adam <thomas@xteddy.org> writes:
Show 5 quoted lines
> 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
Michael Haggerty· Jun 7, 2012, 07:41 UTC · re: Thomas Adam · lore

Re: Please revert e371046b6473907aa6d62b7862a3afe9d33561e1

On 06/06/2012 07:54 PM, Thomas Adam wrote:
Show 16 quoted lines
> On 6 June 2012 11:28, John Wiegley<jwiegley@gmail.com>  wrote:
>> I've spoken to the author of this commit, Matthias Urlichs.  Here is an
>> excerpt of our conversation:
>>
>>> On Sat, 2012-04-21 at 00:08 -0500, John Wiegley wrote:
>>>> 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.

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)

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
Junio C Hamano· Jun 7, 2012, 16:49 UTC · re: Michael Haggerty · lore

Re: Please revert e371046b6473907aa6d62b7862a3afe9d33561e1

Michael Haggerty <mhagger@alum.mit.edu> writes:
Show 27 quoted lines
> On 06/06/2012 07:54 PM, Thomas Adam wrote:
>> On 6 June 2012 11:28, John Wiegley<jwiegley@gmail.com>  wrote:
>>> I've spoken to the author of this commit, Matthias Urlichs.  Here is an
>>> excerpt of our conversation:
>>>
>>>> On Sat, 2012-04-21 at 00:08 -0500, John Wiegley wrote:
>>>>> 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.
>
> 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 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...

Andreas Schwab· Jun 7, 2012, 17:07 UTC · re: Junio C Hamano · lore

Re: Please revert e371046b6473907aa6d62b7862a3afe9d33561e1

Junio C Hamano <gitster@pobox.com> writes:
Show 8 quoted lines
> 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.

Only if the conversion is restarted from scratch. Otherwise, any existing converted commits are preserved due to the incremental nature of git cvsimport.

Andreas.
-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Junio C Hamano· Jun 7, 2012, 17:54 UTC · re: Andreas Schwab · lore

Re: Please revert e371046b6473907aa6d62b7862a3afe9d33561e1

Andreas Schwab <schwab@linux-m68k.org> writes:
> 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.

Andreas Schwab· Jun 7, 2012, 18:47 UTC · re: Junio C Hamano · lore

Re: Please revert e371046b6473907aa6d62b7862a3afe9d33561e1

Junio C Hamano <gitster@pobox.com> writes:
Show 9 quoted lines
> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> 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.
-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

← back to recent threads