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). 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. cheers, martin - 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 22:39:41 2005
This archive was generated by hypermail 2.1.8 : 2005-06-01 22:39:42 EST