Re: [PATCH] Replace git-cvsimport with a rewrite that fixes major bugs.

[Jonathan Nieder <jrnieder@gmail.com>]

Eric S. Raymond wrote:
> Jonathan Nieder <jrnieder@gmail.com>:

>> The former is already loudly advertised in the package description and
>> manpage, at least lets you get work done, and works fine for simple
>> repositories with linear history.
>
> Two of the three claims in this paragraph are false.

Give me a break.

Are you telling me that when multiple users read a manpage that states

| WARNING: for certain situations the import leads to incorrect
| results. Please see the section ISSUES for further reference.
[...]
| Problems related to timestamps:
[...]
| Problems related to branches:
[...]
| Problems related to tags:
[...]
| consider using these alternative tools which proved to be more
| stable in practice:

and a package description that states

| The git cvsimport tool can incrementally import from a repository
| that is being actively developed and only requires remote access
| over CVS protocol. Unfortunately, in many situations the import
| leads to incorrect results. For reliable, one-shot imports, cvs2git
| from the cvs2svn package or parsecvs may be a better fit.

and decide to use the tool anyway, this is not evidence that the tool
is invaluable to them, despite its shortcomings?

Perhaps the users reporting bugs didn't read the manpage and package
description (despite quoting the same passages and explaining why they
used the command nonetheless) or I should ignore the judgement calls
they make.

Consider the following workflow:

 1. Update imported project periodically using git-cvsimport
 2. Hack, do code archaeology using "git log -S" and "git bisect",
    etc.
 3. Fall back to a web browser and cvsweb to confirm conclusions.

You are telling me that it is not a regression to change the workflow
to the following:

 1. Try to use git-cvsimport.
 2. Wonder where that command went.

Meanwhile Junio has already suggested a way out.  Just rename the
command.

Hope that helps,
Jonathan