Re: Using cvs2git to track an external CVS project

On Thu, 2005-06-02 at 00:35 +1200, Martin Langhoff wrote:

Following the cvs2git threads, I'm left with a few doubts.

Linus has stated that it can be used incrementally to track a project
that uses CVS -- in which case I assume I would be maintaining two git
repos, one strictly tracking "upstream", pulling changes from CVS on a
crontab, and the 2nd one with my local changes. Or is it meant to work
on the "local" repo as a pull/merge/update?

What'd be the strategy in that case if I am working on patches that I
intend to feed upstream? To what degree will git try and remerge
against the local repo where the patch originates from? This kind of
smarts are nice when they work -- but I am interested in exploring
more git-style approaches, if git supports this at all.

In the scenario above, if I push _some_ patches upstream, does git
help me at all in sorting out what is upstream and what is not?

I suspect all this patch-based horsetrading amounts to cherry-picking,
and is therefore not supported. What strategy would work with git to
run local branches with a mix of patches that go upstream and others
that don't (or just may take longer to get there).

Disregarding anything about cvs2git there is one point you may not be
thinking about but you may want to care about:  when you send something
upstream to the cvs repository and then get it back via cvs2git you will
get a completely different commit to the one your local git repository
has.  So while the file changes inside those two commits are the same
the actual commits are not and you will end up with all those commits in
duplicate because of it as well as an automatic merge commit to merge
the two commits.  If you don't want that to happen you would need to do
your local changes in throw-away git trees which you rm -rf after the
patch gets applied and you use cvs2git to get your changes.  You could
of course do your local things in git branches and then throw-away the
branch that got applied to cvs and only keep the main trunk in sync but
I personally prefer separate trees to branches.

Right now we are using arch where a long-lived branch tracks
theexternal cvs repo, and we open short-lived branches where we do a
mix of development -- most of which is merged upstream in several
stages.

Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/