James Turner wrote: > I could benefit from some advice on using git to track (various) local > changes I'm working on. > Here's my workflow for using git with the FlightGear sources in CVS. Note that there are separate repositories for Fightgear, Simgear and the Flightgear data. This is inconvenient and there may a workaround using git submodules, but I haven't explored that yet.
> > Essentially I'd like: > - a branch that tracks CVS I have three git repos that I use only to track CVS using git-cvsimport. You could use the mapserver.flightgear.org mirrors instead; I like to have control over my imports, refresh them when I need to, etc. I think you could also do the mirroring in a "working" git repo directly, but keeping separate mirrors is less confusing. The incremental update using git-cvsimport is time-consuming, especially for the data tree, so I can fire off the update and keep working in my regular git repo. Also, using two repos on a single machine doesn't use twice the disk space because git uses hard links to do the clone. > - a branch that is close to CVS, that I can test commits on before For Flightgear, Simgear and data I have one repo each where I do actual work. These were initially cloned from my CVS mirror repos. Whenever I update the mirrors I bring the updates into the working repos using "git-fetch origin". The "master" branch in these repos contains work that I intend to check into CVS soon; they should track CVS, more-or-less. I use "git-rebase" to keep the master branch + new work synched with the CVS mirrors. > getting them into CVS 'somehow' (a patch against a CVS checkout, I > guess) I keep a check-out of the CVS repositories, done using CVS of course. When I'm ready to check something into CVS I use git-cvsexportcommit, which does everything necessary to the CVS tree except the actual commit. After committing I update my mirrors, suck the changes into the working repos, and then "git-rebase". Poof, my master branch is synched with the current CVS state of the world. > - 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 These are just normal git topic branches. I periodically rebase mine against the master branch. > > 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. See above. > > 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. > If we were already using git, then "master" would be the branch that you would push to share your commits with the rest of us; i.e., it would be your local version of the master sources. So that's the branch on which you do development you intend to share soon. > 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) > You want to think of the pure CVS branch as remotes/origin/master. Tim ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
