On Sun, Jan 20, 2013 at 06:20:08PM -0500, Eric S. Raymond wrote:
> John Keeping <john@xxxxxxxxxxxxx>:
>> I don't think there is any way to solve this without giving cvsps more
>> information, probably the last commit time for all git branches, but
>> perhaps I'm missing a fast-import feature that can help solve this
>> problem.
>
> Yes, you are. The magic incantation is
>
> from refs/heads/<branch>^0
>
> I've just pushed a cvsps-3.9 with an -i option that generates these at
> each branch root. Combine it with -d and you get incremental
> fast-export.
I don't think this is enough. I made a very similar change here for
testing (conditional on relative_date_start instead of a new flag) and I
needed this as well in order to prevent empty duplicate commits being
added:
-- >8 --
diff --git a/cvsps.c b/cvsps.c
index fb6a3ad..5771462 100644
--- a/cvsps.c
+++ b/cvsps.c
@@ -1560,7 +1560,7 @@ static bool visible(PatchSet * ps)
ok:
//fprintf(stderr, "Time check: %zd %zd %zd\n", restrict_date_start, restrict_date_end, ps->date);
if (restrict_date_start > 0 &&
- (ps->date < restrict_date_start ||
+ (ps->date <= restrict_date_start ||
(restrict_date_end > 0 && ps->date > restrict_date_end)))
return false;
-- 8< --
But this is nothing more than a sticking plaster that happens to do
enough in this particular case - if the Git repository happened to be on
a different branch, the start date would be wrong and too many or too
few commits could be output. Git doesn't detect that they commits are
identical to some that we already have because we're explicitly telling
it to make a new commit with the specified parent.
You can easily see the breakage by running the tests in the Git tree,
where the CVS revision map tests fail because they end up with duplicate
versions.
You'll need my cvsimport-3 branch to see these failures as it adds the
"git config" support that the tests rely on:
git://github.com/johnkeeping/git.git cvsimport-3
John
--
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