Re: [RFC/PATCH] Triangular Workflow UI improvement: Documentation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: "Matthieu Moy" <Matthieu.Moy@xxxxxxxxxxxxxxx>
"Philip Oakley" <philipoakley@xxxxxxx> writes:

From: "Matthieu Moy" <Matthieu.Moy@xxxxxxxxxxxxxxx>

But then the maintainer is not the one picking changes from it (you're
sending them by email), so the "maintainer" label is not really accurate
in the diagram:

+------------               -----------
+| UPSTREAM |  maintainer   | ORIGIN  |
+|  git/git |- - - - - - - -|  me/git |
+------------       ←       -----------
+         \                   /
+          \                 /
+     fetch↓\               /↑push
+            \             /
+             \           /
+             -------------
+             |   LOCAL   |
+             -------------

Ahh, that's a useful clarification. I use my git repo both for the G4W
(which does take pull requests) and for Junio's Git.

The use of the 'home-vault' fork as being for
(a) backup,
(b) open viewing, and
(c) sending pull requests
are subtle distinctions for the naming (of both the forked repo, and
the workflow).

It's probably even worse in a corporate environment as to how personal
the personal home vault is, as compared to just having a namespace in
a centralised dev server/repo. (the question of how to make such
arrangements seems to come up moderately often on the various lists)

Yes, but again, the point of this thread is to document *one* workflow,

I'd agree here.

not all possible uses of pushRemote. It's much easier to describe "one
typical triangular workflow" in a concrete way

That *one* workflow would be a _specific_ flow - I'm reading 'typical' as
implying common/general workflow(s), which may not be what you hoped to
convey.

  than to try to be
completely general and end up with a description that average users
would just not understand.

I do think that the description of the one specific flow should include the
clarifications that discriminate it from other, potentially mistakenly
confused with this one, flows. It would be that disambiguation that would
clear up the misunderstanding.


It would be different to me if we were writting the pushRemote part of
config.txt, where we have to be as general as possible.

As an aside, the discussion has indicated that the documentation may be a
bit light on describing (and referencing) how multi-user server set-ups can
be arranged to faciltate (or may hinder) the different flows.
--
Philip
(mail delayed by lack of wifi)
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]