Re: [PATCH v2 0/6] Support triangular workflows

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH v2 0/6] Support triangular workflows

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:56:29

"Philip Oakley" [off-list ref] writes:
Shouldn't Documentation/gitworkflows.txt also be updated with the
triangular workflow and its configuration?
What is missing from gitworkflows documentation is actually a
non-triangular workflow, where people pull from and push into the
same central repository.

The "merge workflow" part in the "distributed workflows" section
teaches:

 * fetching others' work from <remote> and merging it to yours;
 * publishing your work to <remote>; and
 * advertising your work.

and it is written for the triangular workflow.

Two triangles are involved.  The maintainer may pull from you but
pushes to her own, which is one triangle, and you pull from the
maintainer and push to your own, which is another.

As to your suggestion, I do think it is reasonable to clarify these
triangles with an illustration, and to even add descriptions for
short-cut configurations as a side note.

Re: [PATCH v2 0/6] Support triangular workflows

From: Ramkumar Ramachandra <hidden>
Date: 2016-06-15 22:56:29

Junio C Hamano wrote:
"Philip Oakley" [off-list ref] writes:
quoted
Shouldn't Documentation/gitworkflows.txt also be updated with the
triangular workflow and its configuration?
What is missing from gitworkflows documentation is actually a
non-triangular workflow, where people pull from and push into the
same central repository.

The "merge workflow" part in the "distributed workflows" section
teaches:

 * fetching others' work from <remote> and merging it to yours;
 * publishing your work to <remote>; and
 * advertising your work.

and it is written for the triangular workflow.

Two triangles are involved.  The maintainer may pull from you but
pushes to her own, which is one triangle, and you pull from the
maintainer and push to your own, which is another.

As to your suggestion, I do think it is reasonable to clarify these
triangles with an illustration, and to even add descriptions for
short-cut configurations as a side note.
I think the gitworkflows document should be rewritten with focus on
setting up remotes and configuration variables for specific workflows.
 Once these are set up, pushing/ pulling (git pull is currently
broken, although I'm working on fixing it) should Just Work.  To push
to a different remote/ refspec, the user can read the manpage of git
push/ git pull.  A workflow is about setting up good defaults that
work 90% of the time with no additional effort.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help