Re: [PATCH] Teach cvsexportcommit to add new files

On 1/7/06, Junio C Hamano [off-list ref] wrote:

Yann Dirson [off-list ref] writes:

quoted

Teach cvsexportcommit to add new files
"cvs add" support was already there, but the "unknown" status
returned when querying a file not yet known to cvs caused the
script to abort prematurely.

Thanks.  I'll take the patch as is, but I noticed that the
cvsexportcommit still has some room for polishing.

Definitely. It's a bit of a hack job that I got started with, and as
it's /worked for me/ so far, haven't done much with it. I am actually
quite busy at the moment, so I don't think you'll see many patches
from me on this fron yet...

(BTW: I'm hoping to find a bit of time to code the git-cvsdaemon that
I've mentioned before, which would be a hell of an interesting
addition, methinks.)

 * The command is to be run from CVS working copy (as desribed
   in the documentation) and seems to assume that the parent
   commit is checked out at least for the paths involved between
   the commit and the parent (not clearly documented).

Indeed, and you can also use it for the same thing you'd use git-am --
for instance, to "merge into CVS" feature branches kept on GIT.

 * I wonder if it is safe with filenames with embedded SP?

It's not -- shame on me. Backticks should be replaced with
safe_pipe_capture() as Eric's done on git-archimport.

 * I think this grep '^Binary' is unsafe; different versions of
   gnu diff say just "Files differ".

Unsure how to detect binary files safely. Is there a way to ask git
whether it considers the files to be binary?

(snipped several good suggestions here...)

I am getting an impression that _if_ we care about applying
fuzzy patch like this, giving fuzz feature to git-apply would
help this program somewhat, but at the same time I do not think
of a good reason to even accept nonexact patch when synching two
SCM histories.

Well, with some fuzz you can use this to merge something into CVS even
if the trunk or branch you're merging into has moved forward a bit.
OTOH, I guess you can go back to git and do a git-rebase if needed.

cheers,


martin