Re: Really happy with cogito for inhouse teamwork, now that I've figured out cg-clone...
- From
- Josef Weidendorfer <josef.weidendorfer@gmx.de>
- Date
- Sep 29, 2005, 15:15 UTC
- 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:
Show 9 quoted lines
> 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