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
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
On 8/19/05, Linus Torvalds [off-list ref] wrote:
quoted
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).
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.
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:
#!/bin/bash
HEADNAME=$1
if [ -e .git/refs/heads/$HEADNAME ]; then
cd .git/
ln -s -f .git/refs/heads/$HEADNAME HEAD
cd ..
cg-reset
cg-restore -f
fi;
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?
cheers,
martin
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