Re: [PATCH] Make cvsexportcommit work with filenames with spaces and non-ascii characters.

söndag 10 december 2006 02:18 skrev Junio C Hamano:

Robin Rosenberg [off-list ref] writes:

quoted

This patch uses git-apply to do the patching which simplifies the code a
lot.

Removed the test for checking for matching binary files when deleting
them since git-apply happily deletes the file. This is matter of taste
since we allow some fuzz for text patches also.

Error handling was cleaned up, but not much tested.

Interesting.

I think you should be able to generate the patchfile once, and
use git-apply to figure out additions, deletions and binaryness,
and then use the same patchfile to apply the changes.  Currently
checking for binaryness is not easy with git-apply, so we would
want to fix git-apply first, instead of forcing you to have a
change like this:

   # the --binary format is harder to grok for names of binary
   # files so we execute a new diff
   # if it looks like binary files exists to find out
   if (grep /^GIT binary patch$/, @diff) {
       @binfiles = grep m/^Binary files/,
       safe_pipe_capture('git-diff-tree', '-p', $parent, $commit);

which is way too ugly.

	... goes to look and comes back, with a big grin ...

<grin> apparently

Well, have you tried this?

	git diff-tree -p --binary fe142b3a | git apply --summary --numstat

of course not. I didn't understand it. Why can't it tell me about removed
binary files, so I could remove the git-diff-tree invocation to find out about 
added/removed files?

The numstat part would let you see the binaryness, so we do not
have to "fix" git-apply.

Another thing that _might_ be interesting is to use rename
detection when preparing the patch, and make the matching rename
on the CVS side, but I do not recall the details of how one
would make CVS pretend to support renamed paths ;-).  I think it
involved copying the ,v file to a new name, and marking the
older revisions in that new ,v file as nonexistent or something
like that, but I did it only in my distant past and forgot the
details.

In server mode, which is the normal way of using CVS you cannot
do this with the CVS most of us are used with. CvsNT does support 
a rename command, I think, but I don't use it, partly due to rumors of it 
being somewhat unstable. If there's any truth in that, I don't know.

Anyway, I don't practice the rename trick in CVS myself. I'm not  sure how 
that would work with the roundtripping via CVS that I do.  cvsimport 
detects "renames" with the current approach so I'm happy as is, not that I 
rename files much.  I also think there than a copy is needed to play nice, 
like removing old tags from the copy, how about rename back and forth etc. 
There's a reason people want to migrate from CVS, as well as there are 
reasons not to hurry. CVS doesn't support rename, it's that simple.

By the way, I am not sure if giving fuzz by default is such a
good idea, though.

It was in the original. I don't know why. Maybe the original author can tell 
us why it was important. It may be problematic to stay fully in sync with a 
CVS repo because you have to git-cvsimport it first and that takes some time. 
This fuzz gives some, but not much slack. Reverting the option could be a 
good idea.

Update follows.