On 26 Dec 2008, at 16:37, Timothy Moore wrote: > I recommend that you use git-cvsimport -k. It can be a bit time- > consuming, but > I've never had the kind of "inconsistencies" that I would see with > taylor, and > it knows how to do deletes!
I could benefit from some advice on using git to track (various) local changes I'm working on. (note, in the following discussion, I suspect for 'branch' you can also read 'tree') Essentially I'd like: - a branch that tracks CVS - a branch that is close to CVS, that I can test commits on before getting them into CVS 'somehow' (a patch against a CVS checkout, I guess) - branches for chunks of stuff I'm working on - a working head where I can combine from the various chunks-of-work- branches, and play with the end result I assume that when I want to commit to CVS, I'd merge/generate-patches from a 'work' branch, apply it to the 'close to CVS' branch, check everything builds, and somehow get that into CVS. What I'm not clear on is what's the best master to use, and which of the above steps are best done with a git merge, or by generating and applying patches to a non-git tree, or what. Obviously I want to be able to rebase the work branches as CVS moves forward, so presumably the should be branched 'from' the pure CVS copy? And hence the pure CVS branch is in fact the master? (I'm guessing wildly now) I\m sure all of the above is possible, and maybe even easy, but as ever with git I struggle with documentation. I've already managed to lose work by doing something dumb on a second machine. James ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
