Closed dabrahams closed 11 years ago
Were seeing two different problems here:
/trunk
, but there are rules that match /trunk/<some path>
. The tool should recurse into the source of the copy and try to match the content in order to get the correct destinations (mind the plural)./tags/Version_1_34_1/boost/boost/algorithm
, but there is one for /tags/Version_1_34_1/boost/boost/algorithm/
(mind the ending slash). The tool should realize that the source of the copy is a folder and append a slash to the path before trying to find a match.I don't see why the source path of the copy should affect the destination. It seems to me that the lack of a rule that matches the source path/revision should have absolutely no effect on what the tool does (?)
Oh... maybe something like this is necessary in order to be able to look up the git-fast-import "mark(s)" corresponding to the source of the copy?
It is not strictly required, but if we want to represent the copy as a copy in git, we need to know the git source path. Otherwise, it cannot be represented as a copy but just as a modification (as hinted by the warning).
Yes, the git source path. Also the fast-import mark, I'm pretty sure. OK.
On Tue, Apr 16, 2013 at 11:38 AM, Daniel Pfeifer notifications@github.comwrote:
It is not strictly required, but if we want to represent the copy as a copy in git, we need to know the git source path. Otherwise, it cannot be represented as a copy but just as a modification (as hinted by the warning).
— Reply to this email directly or view it on GitHubhttps://github.com/ryppl/Boost2Git/issues/12#issuecomment-16463217 .
Dave Abrahams
I'm seeing these in the log, which I'm at a loss to explain:
(etc)
Seems like there must be a bug somewhere.