From: Rustom Mody <rustompmody@gmail.com>
To: Git Mailing List <git@vger.kernel.org>
Subject: Re: git workflow for fully distributed mini-teams
Date: Thu, 17 Sep 2009 12:33:49 +0530 [thread overview]
Message-ID: <f46c52560909170003l61a2e1a3kf62c94ffd7ed9710@mail.gmail.com> (raw)
In-Reply-To: <20090916164356.GB24893@vidovic>
Rustom Mody wrote:
> By fully distributed I mean theres no central repo -- not for pushing
> or even pulling; all communication is by email.
> By mini-team I mean: Not more than 5 programmers.
On Wed, Sep 16, 2009 at 10:13 PM, Nicolas Sebrecht <nicolas.s.dev@gmx.fr> wrote:
>
>
> Also, I see a duplication of the same work for all the developers in a
> team: "merge my topics with topics from others". This could be solved
> with one more common repository wich could stand as a "virtual
> maintainer repository" where each developer could release any topic.
> Topics that don't need any more work would have to be merged in a
> dedicated public branch ("next"?) for testing, and topics that aren't
> good enough into another dedicated branch ("pu"?). So, each developer
> would have to push publishable merges into this repository. This way,
> everyone could use the merges done by another developer (by doing a
> fetch and rebasing of his current work on top of it).
Push? Fetch? How without a common repo? [Sorry if this is totally noob!]
>
> Notice that this is all about "everybody uses the same base for his
> current work" (to avoid per-developer scratch on merges) and "don't let
> everyone do the same work on his own" (to avoid duplicate work).
>
>> What about checkpointing and restoring from botches?
>
> I think this is be easily doable (against your described workflow) with
> good conventions in branch names. Topics like "pending-topicA",
> "pending-topicB", etc that would have to be merged (using a script) into
> a "all pending topics" branch should do what you want, no? Restoring
> from botches would mean removing the crappy branch and re-execute the
> script.
I am really concerned about things like:
A commited something on the B branch, received a patch from B. That
patch did not apply (or worse it applied -- on top of A's!)
So ideally there should be an option that says (when A is on B branch
and tries to commit) "Sorry buddy -- No commits here!"
next prev parent reply other threads:[~2009-09-17 7:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-16 7:35 git workflow for fully distributed mini-teams Rustom Mody
2009-09-16 16:43 ` Nicolas Sebrecht
2009-09-17 7:03 ` Rustom Mody [this message]
2009-09-17 7:28 ` Johannes Sixt
2009-09-17 12:38 ` Rustom Mody
2009-09-17 13:52 ` Rustom Mody
2009-09-17 14:47 ` Johannes Sixt
2009-09-18 7:01 ` Rustom Mody
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=f46c52560909170003l61a2e1a3kf62c94ffd7ed9710@mail.gmail.com \
--to=rustompmody@gmail.com \
--cc=git@vger.kernel.org \
/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).