Udyzr ch5 integration mgr wflw #1255
Conversation
* Fix: Inspecting commits made on topic branch since... common ancestor with main branch. Issue detected and fixed by consulting git-revisions manual page (used git version is 2.21.0): <rev1>...<rev2> - Include commits that are reachable from either <rev1> or <rev2> but exclude those that are reachable from both... <rev1>..<rev2> - Include commits that are reachable from <rev2> but exclude those that are reachable from <rev1>... * Fix referring to * Fix reference to 'double-dot'
* mention explicitly existence and usage of developer private / local repository * match possesive to used personal pronounce * fill small gaps in description
| @@ -39,15 +39,16 @@ With Git's branching model, it's possible for hundreds of developers to successf | |||
| (((workflows, integration manager))) | |||
| Because Git allows you to have multiple remote repositories, it's possible to have a workflow where each developer has write access to their own public repository and read access to everyone else's. | |||
| This scenario often includes a canonical repository that represents the ``official'' project. | |||
| To contribute to that project, you create your own public clone of the project and push your changes to it. | |||
| Each developer has also own private repository for conducting changes in workspace then committing. | |||
| To contribute to that project, you create your own public clone of the project and push your changes to it from your private repository. | |||
There was a problem hiding this comment.
Not exactly. If you fork a public repo, your fork is public as well. The "private repo" in the diagram is the one on your computer. At this point in the book the reader is familiar with making changes in a local repo and pushing to a remote, so there's no need to spell it out. IMO the original wording is more clear.
There was a problem hiding this comment.
Cit. "At this point in the book the reader is familiar with making changes in a local repo.." that's can be well true. Will it also be clear here for book reader private repositories are being used in workflow being elaborated? The more gaps the book's reader needs mentally to fill by themselves - while on journey with this book - the more distant reader's arrival at their destination.
There was a problem hiding this comment.
OK, how about this then:
Each developer has also their own private repository (on their own machine) for authoring commits.
To contribute to that project, you would create your own public clone of the project, and push your changes to it from your private repository.
| 2. A contributor clones that repository and makes changes. | ||
| 3. The contributor pushes to their own public copy. | ||
| 4. The contributor sends the maintainer an email asking them to pull changes. | ||
| 2. A contributor clones that repository and makes then commits changes. |
There was a problem hiding this comment.
| 2. A contributor clones that repository and makes then commits changes. | |
| 2. A contributor clones that repository and commits changes. |
There was a problem hiding this comment.
Text before PR mentions - in explicit way - making changes in point 2 so how about retaining it there?
Mental shortcuts are good when in circle of two or more of same knowledge / experience level. Here book's author(s) with deep Git expertise is(are) talking to Git newbies - one needs to be cautions with usage of mental shortcuts.
There was a problem hiding this comment.
By that logic, we should be including paragraphs with every numbered point here. This isn't meant to be an exhaustive list of commands the user needs to type in, and readers at this point should know that they can't make commits without making changes. Remember, this is chapter 5, and the reader should be pretty comfortable working with a local repository at this point.
| 3. The contributor pushes to their own public copy. | ||
| 4. The contributor sends the maintainer an email asking them to pull changes. | ||
| 4. The contributor sends the maintainer an email asking therein to pull changes. |
There was a problem hiding this comment.
This parses weirdly to a native English reader. Can I ask what you found objectionable about my suggestion?
The contributor sends an email asking the maintainer to pull changes.
No description provided.