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/ - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Wed Jun 01 23:12:17 2005
This archive was generated by hypermail 2.1.8 : 2005-06-01 23:12:18 EST