On Mon, 2007-03-12 at 13:52 +0100, Timmerman, Bert wrote: > I allready miss the $Id$ tag with the version, status and commit date in > it, which is a quick and visible pointer to me, as to see something has > changed in a schematic.
Funny.. I find myself detesting files with those tags in them, as they cause false merge problems which I have to check out! git is VERY flexible in what you can do with branching, and I think this is what makes it great for lots of people working on gEDA at once. > A question that come to mind is: Is there a decent way (as in not > cumbersome) to revert from git to cvs and not losing the intermediate > commits made in git ? I believe there is, but I've not tried the automated approach myself. I've been staging patches in git, and applying them individually (after testing) to the noscreen branch in CVS. > IMO that is what's needed when stable code written by one or more > students is to be merged into the geda/gaf or pcb cvs repository. The approach (and opinion) I have taken is that git is great for working, incrementally checking in small changes. When it goes into CVS, each commit should be a working change. Perhaps underlying that working change are more than one git-commits. I don't necessarily want a 1-1 mapping between git and CVS. (Ok - strictly, I do... but I produce a new git branch based at the end of the CVS branch I'm working on - then apply those patches to CVS). Extracting patches between any arbitrary commits in git is _easy_ and there are scripts to automate their output. > It's very likely that someone has to do a test to find the caveats, if > any exist. There are some, Peter Brett and myself have encountered some in keeping a tracked git repository of CVS - but it is possible, and I've found it really useful for what I've been doing. Regards, Peter C _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
