From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: Thu, 29 Sep 2005 15:15:35 GMT
Subject: Re: Really happy with cogito for inhouse teamwork, now that I've figured out cg-clone...
Message-ID: <200509291715.35317.Josef.Weidendorfer@gmx.de>
In-Reply-To: <46a038f905092822587f5414d4@mail.gmail.com>

On Thursday 29 September 2005 07:58, Martin Langhoff wrote:
> 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

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