git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git workflow for fully distributed mini-teams

From
RMRustom Mody <rustompmody@gmail.com>
Date
Sep 17, 2009, 07:03 UTC
Message-ID
<f46c52560909170003l61a2e1a3kf62c94ffd7ed9710@mail.gmail.com>
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:
Show 12 quoted lines
>
>
> 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!]
Show 13 quoted lines
>
> 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!"

Previous: Nicolas SebrechtNext: Johannes Sixt
Message 3 of 8 in “git workflow for fully distributed mini-teams”
  1. Rustom ModySep 16, 2009
  2. Nicolas SebrechtSep 16, 2009
  3. Rustom ModySep 17, 2009
  4. Johannes SixtSep 17, 2009
  5. Rustom ModySep 17, 2009
  6. Rustom ModySep 17, 2009
  7. Johannes SixtSep 17, 2009
  8. Rustom ModySep 18, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.