git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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!"

  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).