All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Woolley <nickwoolley@yahoo.co.uk>
To: David Chanters <david.chanters@googlemail.com>
Cc: Jakub Narebski <jnareb@gmail.com>, git@vger.kernel.org
Subject: Re: CVS <--> GIT workflow...
Date: Thu, 02 Jul 2009 13:01:27 +0100	[thread overview]
Message-ID: <4A4CA197.5050202@yahoo.co.uk> (raw)
In-Reply-To: <ac3d41850907011425x966483awe1757e24417d9da4@mail.gmail.com>

Hi,

David Chanters wrote:
> So what would I do?  Something like this:
> 
> 1.  Use git-cvsimport to "convert" a snapshot of the current CVS
> project to something Git can understand.
> 2.  Checkout this git project via git clone in the usual way.
> 3,  Hack away in this Git clone.
> 4.  Use git-cvsexportcommit to extract commits?
> 

I don't think step 2 is needed, since git-cvsimport imports into a local .git
repository that you can work with directly.  A read-only copy of all the
imported CVS commits go into the git repository, within a "remote" whose name
you need to specify with git-cvsimport's -r parameter.  I normally use "-r cvs
-o cvshead", which will import CVS's HEAD onto remotes/cvs/cvshead and BRANCHX
onto remotes/cvs/BRANCHX.

> What about my workflow within the Git repository?  I assume that
> "Master" would be the branch I would want to merge *to* if I have
> local topic brances I wish to have in to CVS, and then the commits on
> Master would be something git-cvsexportcommit would look at?
>
> Indeed, it seems git-cvsexportcommit is somewhat "manual" -- is there
> no way of automating that to say something like:  "Take all commits on
> branch $FOO in Git, which aren't in CVS, and apply them?"   I might be
> missing some understanding here.

Yes, git-cvsexportcommit has to be told explicitly which commits to export.  It
will only check that they seem to be sane, in that they will apply cleanly.

Currently I presume everyone has to roll their own solution to this.  In my
case, with the absence of any available prior art, I wrote a wrapper script, in
an attempt to simplify the process to 'git-cvs push' and 'git-cvs pull'.  See my
earlier post to this list:

 http://article.gmane.org/gmane.comp.version-control.git/120351

This works for me for basic day-to-day interaction with my CVS repository, which
has over a year's work in it, although there are times when I still need to
manually intervene.

If you do try it I'd be interested hear how  well it works, especially if it
means I can improve it. Currently it doesn't have a lot of documentation besides
what's in the script itself,  but if I could be encouraged to write more if
asked nicely.



Note, you probably also want a step 5 before cycling back to step 3: use
git-cvsimport to incrementally import your exported commits back into git.  If
this succeeds, git-cvsimport will also merge the remote CVS branch with your
local one - like this, where c' and d' are the re-imported copies of commits c
and d which come via CVS:

 a-b----c'-d'    <- e.g. remotes/cvs/cvshead
    \       \
     c-d-----e-  <- e.g. master

I find that merge loops in the history like this make it hard to get the list of
exports to commit next time.

i.e. After adding some more commits to master:

 a-b----c'-d'      <- remotes/cvs/cvshead
    \       \
     c-d-----e-f-g <- master

Then you want to commit f and g.  But:

  git rev-list master..remotes/cvs/cvshead

Will return c, d, e, f, g.  So instead I typically add this to step 5:

  git reset --hard remotes/cvs/cvshead

Which discards c, d and e, leaving:

 a-b-c'-d'      <- remotes/cvs/cvshead and master

Then you have a clean linear history and future commits to export.  My script
doesn't do this for you, currently, since in the case where there have been
multiple branches merged in before commit e, you might prune away those branches
as well as the duplicate commits on the working branch (i.e. c and d).

(I've just been avoiding this situation rather than fixing it, partly because
I'd not found a better way yet, despite fiddling with various invocations of
git-rebase. So I'd be particularly interested if anyone can suggest one.)

In theory c' and d' should be identical to c and d - although if you haven't set
up an author map for git-cvsimport, you may find that your commits come back
with the username you use in CVS, which may differ from that in git.

In this case, you need to have supplied the -A parameter to git-cvsimport in step 1.



Finally, whatever you use, you'll probably want the latest release of git, since
it has a bug fix for git-cvsexportcommit.  See:

  http://article.gmane.org/gmane.comp.version-control.git/120241


Cheers,

N

      reply	other threads:[~2009-07-02 12:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-01 18:32 CVS <--> GIT workflow David Chanters
2009-07-01 19:24 ` John Tapsell
2009-07-01 19:29   ` David Chanters
2009-07-01 20:00 ` Jakub Narebski
2009-07-01 21:25   ` David Chanters
2009-07-02 12:01     ` Nick Woolley [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A4CA197.5050202@yahoo.co.uk \
    --to=nickwoolley@yahoo.co.uk \
    --cc=david.chanters@googlemail.com \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.