git workflow for fully distributed mini-teams

git workflow for fully distributed mini-teams

[Rustom Mody]

I am trying to formulate (and understand) what it means to have a
fully-distributed mini team workflow with git.

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.

Heres a typical scenario.

There are 3 programmers A B and C who communicate by email who have
started off from the same code base.

A's branches: dev, master, B, C
B's branches: dev, master, A, C
C's branches: dev, master, A, B

A's best practices (and invariants) are:
I (ie A) develop on dev (or other topic branches).
I only merge onto master; never commit.
I never work on nor merge onto B and C.
When B sends me patches I apply them to the B branch likewise for C.
Thereafter I merge that branch onto dev or master.
There are no tracking branches because there are no remotes -- no
central repo. [not clear about this]

B and C have corresponding practices/behavior.

So the questions...

Is there a better way of doing things?
Can some of these practices/invariants be enforced by scripts/options etc?
What about checkpointing and restoring from botches?

Re: git workflow for fully distributed mini-teams

[Nicolas Sebrecht]

The 16/09/09, Rustom Mody wrote:
> 
> A's best practices (and invariants) are:
> I (ie A) develop on dev (or other topic branches).
> I only merge onto master; never commit.
> I never work on nor merge onto B and C.
> When B sends me patches I apply them to the B branch likewise for C.
> Thereafter I merge that branch onto dev or master.
> There are no tracking branches because there are no remotes -- no
> central repo. [not clear about this]
> 
> B and C have corresponding practices/behavior.
> 
> So the questions...
> 
> Is there a better way of doing things?
> Can some of these practices/invariants be enforced by scripts/options etc?

What's may be hard here is about "releasing topic". With a "maintainer
oriented workflow", the status of each topic is clear (either "won't
merge as is, needs more work" or "should be good enough, is merged and
aims to be in the next release").

In the fully-distributed workflow you describe, the state of the topics
looks hard to know. Who releases what is not clear.

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

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.

Hope this helps.

-- 
Nicolas Sebrecht

Re: git workflow for fully distributed mini-teams

[Rustom Mody]

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!"

Re: git workflow for fully distributed mini-teams

[Johannes Sixt]

Rustom Mody schrieb:
> 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!"

I think the most important thing would be that you send bundles around,
not patches, so that you all can work with and talk about unique object names.

-- Hannes

Re: git workflow for fully distributed mini-teams

[Rustom Mody]

On Thu, Sep 17, 2009 at 12:58 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> I think the most important thing would be that you send bundles around,
> not patches, so that you all can work with and talk about unique object names.
>
> -- Hannes

Thats what we need -- thanks a  'bundle'!

Re: git workflow for fully distributed mini-teams

[Rustom Mody]

On Thu, Sep 17, 2009 at 6:08 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Thu, Sep 17, 2009 at 12:58 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> I think the most important thing would be that you send bundles around,
>> not patches, so that you all can work with and talk about unique object names.
>>
>> -- Hannes

I started looking at git bundle and find things like master\~10.
Whats the backslash doing?

Tried running git bundle create with and without the backslash -- it
produced the same bundle.

Looked up tilde-expansion in bash and I gather bash does things to the
~ only on beginning of words whereas as far as I can see git uses ~
only at the end of words like master.

What am I missing?

Re: git workflow for fully distributed mini-teams

[Johannes Sixt]

[On this list, we reply to all, so that the Cc list remains]

Rustom Mody schrieb:
> I started looking at git bundle and find things like master\~10.
> Whats the backslash doing?

It's intended as markup for the pipeline that generates the documentation
from git-bundle.txt. Either the markup is incorrect, or there is a bug in
the pipeline, because I only see it in the generated HTML. Ignore it.

-- Hannes

Re: git workflow for fully distributed mini-teams

[Rustom Mody]

On Thu, Sep 17, 2009 at 8:17 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> [On this list, we reply to all, so that the Cc list remains]
>
> Rustom Mody schrieb:
>> I started looking at git bundle and find things like master\~10.
>> Whats the backslash doing?
>
> It's intended as markup for the pipeline that generates the documentation
> from git-bundle.txt. Either the markup is incorrect, or there is a bug in
> the pipeline, because I only see it in the generated HTML. Ignore it.

Seems to be there in my git-bundle.txt as well as git-bundle.html.
So its probably the markup not the pipeline.