Really happy with cogito for inhouse teamwork, now that I've figured out cg-clone...

Just wanted to mention something that isn't in Cogito's readme, and has been crucial in making our use of cogito straightforward.

We've made the transition a few weeks ago, and we've been _really_ happy with git/cogito (over cvs and tla, our "other" SCMs). Whoever, there was something we all found ackward in how we did clone/pull/push.

The _right_ way to do for a team with git-over-ssh is:

Doing the checkout the 'right' way:
 $ cg-clone git+ssh://locke.catalyst.net.nz/var/git/project.git#branchname
localdirname

Work cycle:
 # work work work
 $ cg-commit
 $ cg-update
 $ cg-push

The README doesn't talk about teams with "peer" access to a shared repo. So I fumbled about and we were doing cg-clone using rsync (rsync protocol or over ssh), or just straight http. This made pushing back to the repo impossible with Cogito. So we were calling git-push directly, with the risk of pushing to the wrong head (only really risky for two very closely related heads, but still).

Now, I should put this into a patch to Cogito's README.... give me 5'...

martin

On Thursday 29 September 2005 07:58, Martin Langhoff wrote:

Yes, this works very well here, too. And it works officially since cg-push allows to push on a non-master remote head (based on git's advanced push allowing mapping of different head names on local and remote side). [Before, I used a hack in cg-clone: with e.g. cloning remote head "rem", symlink local master to a local "rem". This was working quite fine, too]

The following is equally fine (smaller work per commit, with lot more commits relative to the pushing to the central rep - gives more documentation on the development history):

# work $ cg-commit # work $ cg-commit # work $ cg-commit $ cg-update $ cg-push

Aditionally, we have in the central repository a head per developer, to publish experimental/instable work, and they are regularly merged back into the central master.

The key to simplicity is here, to have one clone for every remote head. Introducing Git/Cogito to other people this way almost needs no tutorial at all.

This is complemented by an automated mail to a project mailing list via use of the update-hook in the central repository, so that every developer is kept up-to-date on work of others. The mail is formatted to include URLs for every commit to a matching gitweb interface. Was really easy to setup and quite handy.

Josef