Re: Questions on 'cvs migration guide''
On Fri, 19 Aug 2005, Martin Langhoff wrote: I'm keen on keeping my 'merge publish' step in a single repo that has all the 'team' branches. The person running this repo will probably actually code in separate repos, and merge in there too. I would suggest against a person owning a merge and publish. Instead, just have a public repo that everybody involved to can push to - _they_ will need to merge before they push (since a push won't accept a unrelated parent), but that way anybody can export their changes at any time, exactly like with a central CVS repository. Right now I'm switching 'heads' (I'm getting used to cogito's use of 'branch' for 'remote head') using this quick'n'dirty bit of shell: No, just do git checkout headname but I want to prevent the action if the checkout is 'dirty'. Is there any way to check whether cg-diff thinks anything has changed? If you use git checkout to switch branches, it will do that testing for you. You can still _force_ a head switch with git checkout -f. Oh, and if a file was dirty that is the same in both heads, the dirtyness follows you into the new head. If that isn't what you want, then you need to add some logic like if [ $(git-diff-files) != ]; then echo Current branch not clean 2 exit 1 fi git checkout $@ or something. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Questions on 'cvs migration guide''
In the section 'Emulating CVS behaviour', where the team setup is described with a team 'merger'. What is not clear is how to deal with project-wide branches. Should they be created in the master repo, and everyone clone a new repo from it? With a team of 10 people, and perhaps 4 or 5 branches, the setup to pull stuff back seems messy. And yet another question: the teammember who is pulling must 'switch' the merging repo to the right branch, pull from the corresponding remote repos of each teammember, and push to the public view of the repo. Is that right? cheers, martin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions on 'cvs migration guide''
On Fri, 19 Aug 2005, Martin Langhoff wrote: In the section 'Emulating CVS behaviour', where the team setup is described with a team 'merger'. What is not clear is how to deal with project-wide branches. Should they be created in the master repo, and everyone clone a new repo from it? Just make them another branch in the master repo. Whether people will clone a whole new repo for it, or have just one repo and switch between local branches in their own local (single) repo is their personal choice. Some people may well prefer to have all different branches checked out in different places (ie have one repository per branch) others may prefer to work with one repository and just switch. And yet another question: the teammember who is pulling must 'switch' the merging repo to the right branch, pull from the corresponding remote repos of each teammember, and push to the public view of the repo. Is that right? .. yes. Or alternatively, just keep the repo at that branch (and if such a person works on multiple branches, he/she can thus just keep multiple repos). Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
