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@xxxxxx> 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!"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html