söndag 10 december 2006 02:18 skrev Junio C Hamano:
> Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> writes:
> > 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.
-- robin
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html