John Keeping <j...@keeping.me.uk>:
> But this is nothing more than a sticking plaster that happens to do
> enough in this particular case
I'm beginning to think that's the best outcome we ever get in this
> - 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.
Then I don't understand the actual failure case. Either that or you
don't understand the effect of -i. Have you actually experimented with
it? The reason I suspect you don't understand the feature is that it
shouldn't make any difference to the way -i works which repository branch is
active at the time of the second import.
Here is how I model what is going on:
1. We make commits to multiple branches of a CVS repo up to some given time T.
2. We import it, ending up with a collection of git branches all of which
have tip commits dated T or earlier. And *every* commit dated T or earlier
gets copied over.
3. We make more commits to the same set of branches in CVS.
4. We now run cvsps -d T on the repo. This generates an incremental
fast-import stream describing all CVS commits *newer* than T (see
the cvsps manual page).
5. That stream should consist of a set of disconnected branches, each
(because of -i) beginning with a root commit containing "from
refs/heads/foo^0" which says to parent the commit on the tip of
branch foo, whatever that happens to be. (I don't have to guess
about this, I tested the feature before shipping.)
6. Now, when git fast-import interprets that stream in the context of
the repository produced in step 2, for each branch in the
incremental dump the branch root commit is parented on the tip
commit of the same branch in the repo.
At step 6, it shouldn't matter at all which branch is active, because
where an incremental branch root gets attached has nothing to do with
which branch is active.
It is sufficient to avoid duplicate commits that cvsps -d 0 -d T and
cvsps -d T run on the same CVS repo operate on *disjoint sets* of CVS
file commits. I can see this technique possibly getting confused if T
falls in the middle of a changeset where the CVS timestamps for the
file commits are out of order. But that's the same case that will
fail if we're importing at file-commit granularity, so there's no new
Can you explain at what step my logic is incorrect?
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html