From: Petr Baudis <pasky@suse.cz>
To: Abhijit Bhopatkar <bain@devslashzero.com>
Cc: git <git@vger.kernel.org>, teamgit@googlegroups.com
Subject: Re: [RFC] teamGIT bonjour support
Date: Fri, 20 Nov 2009 10:05:30 +0100 [thread overview]
Message-ID: <20091120090529.GM17748@machine.or.cz> (raw)
In-Reply-To: <2fcfa6df0908280002y221a22e6md27db56865472144@mail.gmail.com>
Hi!
On Fri, Aug 28, 2009 at 12:32:39PM +0530, Abhijit Bhopatkar wrote:
> I plan to do this on LAN using bonjour service discovery
I wonder why so much emphasis for this? It seems like a nifty
convenience bit, but I don't think making this idea too central is any
good. What if you get a second office at the other end of the world?
What if part of your team is working on a deployment at customer site?
What if part of your team works from home over a VPN? What if your
team is collaborating over the internet on an open project? What if...?
That said, it sounds like a great idea to have let's say a post-commit
hook that will start an upload job:
extbranch="$(whoami)/$(git symbolic-ref HEAD | sed 's#refs/heads/##')"
pushurl="$(melting_pot)"
git push --force "$pushurl" "HEAD:$extbranch" >/dev/null &
(untested, +corner cases). On the server side, cronjob or post-update
hook can do the integration testing. The complete setup should be
a matter of few-minutes hack.
Now, it seems totally irrelevant if melting_pot is
melting_pot() { git config teamgit.meltingpot }
or extra code that tries/caches some local discovery first.
P.S.: It's not clear if you want the information sharing with commit
granularity or less - in that case, things might get rather tricky e.g.
if you add new files and don't git add them until right before you
commit, and the work tree state might be total mess anyway.
P.P.S.: It's not clear if you strive after complete de-centralization of
the service, with no central melting pot. That would seem fancy, but
I think rather useless and hard in practice to arrange your reports
that you want, etc. It's not clear again then if the integration testing
should happen on single machine they all vote on (samba-like), or if
all machines should do integration-testing, and whether of all branches
or only some of them, and how to recognize the interesting branches, and
things are getting very hairy already... Your requirements are too
ambiguous.
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
next prev parent reply other threads:[~2009-11-20 9:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-28 7:02 [RFC] teamGIT bonjour support Abhijit Bhopatkar
2009-08-28 8:05 ` John Tapsell
2009-08-28 8:39 ` Abhijit Bhopatkar
2009-08-28 10:06 ` Ben Hoskings
2009-08-28 10:17 ` Ben Hoskings
2009-08-28 10:22 ` Jakub Narebski
2009-08-28 13:07 ` Abhijit Bhopatkar
2009-11-20 9:05 ` Petr Baudis [this message]
2009-11-20 9:12 ` Petr Baudis
2009-11-20 9:49 ` Björn Steinbrink
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091120090529.GM17748@machine.or.cz \
--to=pasky@suse.cz \
--cc=bain@devslashzero.com \
--cc=git@vger.kernel.org \
--cc=teamgit@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).