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

2 messages from 2005-09-29 to 2005-09-29. Participants: Martin Langhoff, Josef Weidendorfer.
Thread: https://gitlist.dev/t/1972

## Martin Langhoff, 2005-09-29 05:58

Subject: Really happy with cogito for inhouse teamwork, now that I've figured out cg-clone...
Message-ID: <46a038f905092822587f5414d4@mail.gmail.com>
URL: https://gitlist.dev/e/46a038f905092822587f5414d4%40mail.gmail.com

```
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

```

## Josef Weidendorfer, 2005-09-29 15:15

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>
URL: https://gitlist.dev/e/200509291715.35317.Josef.Weidendorfer%40gmx.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

```