Hi Denis, Denis> Hi Daniel and others, >> it would really great if you switched to git. it would be way easier >> for us to integrate your changes (and for you to integrate ours).
Denis> I'll consider it, but don't really want to spend time learning the Denis> fine points of git. As department co-chair and new father I have very Denis> little spare time and I'd rather code than learn how to manage code. Denis> If I switched the CVS repository on Sourceforge to a GIT repository Denis> still on sourceforge, and kept using it in the same way, i.e. just Denis> doing my own commits at my pace and essentially ignoring the rest of Denis> the world, would that be useful to you? (I guess it'd save you from Denis> reimporting the cvs into your git, instead making it just a git pull Denis> or clone or whatever it's called from the "official" repo into yours?) If you switched, it would be great. The workflow you are discussing is the same that postgres uses. In their GIT repo there are branches, no merges. All changes are sent via mail and committed by the core developers. Yet, there is a healthy community of git repositories where people do their features, and easily synchronize with the official repository. What you need is the following: git clone <repo> (original create a "working copy" of the repo. It is more than a working copy, but it is the same concept). git commit -a -m 'Message for the commit" you can commit as many times as you want in your local repository. But you need the -a option, so don't forget it (or create an alias for it). git push by default it will push to the repository from where you cloned originally. it is equivalent to the old svn commit) git pull You don't need this is you only have one working copy. If you have several ones, this will synchronize your copy to the remote repository. Be warned, if you make different changes to your local repos, you will implicitly create branches, but the issues are not any different than working in two working copies of CVS. If you make sure you don't make independent copies in two local repositories (i.e. you only work in one local repository) then you will be creating a single code-line repository. When we have changes ready for you we can create a patch (easiest would be to use patch because you don't want to clutter your repo with the histories we maintain--- this patch is no different than what we have now). but it is easier for us to make sure it commits cleanly in your code, and git gives the tools to keep it up to date without much work. I think that is all you need. Denis> The two things I feel strongly about: Denis> - the "official" repo should be on sourceforge and not on github or Denis> any other platform; Denis> - for now I want to keep control over the "official" repo, and don't Denis> trust others to make changes to the main branch; Yes, I agree. That is the fundamental difference with centralized vs distributed (i called it the paradox of distr. version control): in a system where everybody is supposed to have commit privileges, centralized VC is democratic ( everybody can commit to the repo), while in distribute only its owner (and those who she selects) can commit to her repository. Denis> - I'm not going to learn any fancy git tricks for the time being, but Denis> using git as a basic linear repository should be within my Denis> abilities... If you have questions, problems, I commit to help you. Denis> About integrating others' changes: given the amount of coding Denis> errors I find in the patches I integrate, I'm going to continue Denis> reviewing all code line by line before merging anything, and Denis> patch files are actually what I work from... I think this is a very good idea. --dmg Denis> Best, Denis> Denis Denis> -- Denis> Denis Auroux [email protected] Denis> University of California, Berkeley Tel: 510-642-4367 Denis> Department of Mathematics Fax: 510-642-8204 Denis> 817 Evans Hall # 3840 Denis> Berkeley, CA 94720-3840 -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Xournal-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xournal-devel
