| Message ID | pull.668.v3.git.1593087539.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Accommodate for pu having been renamed to seen | expand |
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes: > This patch series adjusts Git's own source code to reflect that change. > > Please note that even with these patches, there are still a couple places > where pu is used: > > * In the translations. These are legitimate words in languages that are not > English (as in "gpg n'a pas pu signer les données" where "pu" is French > for the English "could"). > * In upload-pack.c, where a variable named pu is short form for > "pack-objects updates". > > Changes since v2: > > * One accidental quoting change in v1 was reverted. Thanks for being thorough. You could have just told me that the fixup queued on 'seen' looks good to you and squash it in the first step instead to save one roundtrip, but replacing with a new set of three patches is not so bad, either ;-) Will replace.
On 25-06-2020 17:48, Johannes Schindelin via GitGitGadget wrote: > This patch series adjusts Git's own source code to reflect that change. > > Please note that even with these patches, there are still a couple places > where pu is used: > This reminds me. The ProGit book references the `pu` branch in several places in the text and images IIRC. Is it fine to change them now? Would it be premature? > * In the translations. These are legitimate words in languages that are not > English (as in "gpg n'a pas pu signer les données" where "pu" is French > for the English "could"). > * In upload-pack.c, where a variable named pu is short form for > "pack-objects updates".
Hi Junio, On Thu, 25 Jun 2020, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> > writes: > > > This patch series adjusts Git's own source code to reflect that change. > > > > Please note that even with these patches, there are still a couple places > > where pu is used: > > > > * In the translations. These are legitimate words in languages that are not > > English (as in "gpg n'a pas pu signer les données" where "pu" is French > > for the English "could"). > > * In upload-pack.c, where a variable named pu is short form for > > "pack-objects updates". > > > > Changes since v2: > > > > * One accidental quoting change in v1 was reverted. > > Thanks for being thorough. > > You could have just told me that the fixup queued on 'seen' looks > good to you and squash it in the first step instead to save one > roundtrip, but replacing with a new set of three patches is not so > bad, either ;-) To be honest, the GitGitGadget-based workflow makes it quicker for me to just submit a new iteration. In fact, I did not even see your fixup until I read your mail. Ciao, Dscho > > Will replace. > >
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> You could have just told me that the fixup queued on 'seen' looks >> good to you and squash it in the first step instead to save one >> roundtrip, but replacing with a new set of three patches is not so >> bad, either ;-) > > To be honest, the GitGitGadget-based workflow makes it quicker for me to > just submit a new iteration. I do not mind seeing a new iteration that gives easier time for others to comment on the version that is closer to the final than the previous round. The offer was only for contributors who find it easier to just say "yeah, I am happy with that change" than submitting a new round. > In fact, I did not even see your fixup until I read your mail. This I actually would mind a bit more. The reason why I publish 'seen' is to make it easier for authors of individual topics how their work would play with other topics in flight, and it diminishes the value of it if contributors do not pay attention to what is queued there. I expect contributors to fetch and look at what is queued in origin/seen. There may be evil merges that reveal subtle interactions between topics, some of which may involve the topic an author may care about. There may be fixups for problems that were not found during review but only found during the integration process. I try to communicate these back on the list when possible, but the thing is, a day does not have sufficient number of minutes for me to always do so. Thanks.
Hi Junio, On Tue, 30 Jun 2020, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > >> You could have just told me that the fixup queued on 'seen' looks > >> good to you and squash it in the first step instead to save one > >> roundtrip, but replacing with a new set of three patches is not so > >> bad, either ;-) > > > > To be honest, the GitGitGadget-based workflow makes it quicker for me to > > just submit a new iteration. > > I do not mind seeing a new iteration that gives easier time for > others to comment on the version that is closer to the final than > the previous round. The offer was only for contributors who find > it easier to just say "yeah, I am happy with that change" than > submitting a new round. > > > In fact, I did not even see your fixup until I read your mail. > > This I actually would mind a bit more. The reason why I publish > 'seen' is to make it easier for authors of individual topics how > their work would play with other topics in flight, and it diminishes > the value of it if contributors do not pay attention to what is > queued there. I expect contributors to fetch and look at what is > queued in origin/seen. > > There may be evil merges that reveal subtle interactions between > topics, some of which may involve the topic an author may care > about. There may be fixups for problems that were not found during > review but only found during the integration process. I try to > communicate these back on the list when possible, but the thing is, > a day does not have sufficient number of minutes for me to always do > so. I understand. And I am trying my best to accommodate. Ciao, Dscho > > Thanks. >
This patch series adjusts Git's own source code to reflect that change. Please note that even with these patches, there are still a couple places where pu is used: * In the translations. These are legitimate words in languages that are not English (as in "gpg n'a pas pu signer les données" where "pu" is French for the English "could"). * In upload-pack.c, where a variable named pu is short form for "pack-objects updates". Changes since v2: * One accidental quoting change in v1 was reverted. * Rebased onto maint (no merge conflicts, so it does not actually change anything). Changes since v1: * Rebased onto master (no conflicts, so it is safe, and it is more robust than basing the patches on seen which already contains v1 of these patches). * Adjusted the quoting to match https://lore.kernel.org/git/e250f1bb100aca94c914f1b2d38a3849c2566aea.1592909867.git.liu.denton@gmail.com/ . Johannes Schindelin (3): docs: adjust for the recent rename of `pu` to `seen` docs: adjust the technical overview for the rename `pu` -> `seen` tests: reference `seen` wherever `pu` was referenced Documentation/MyFirstContribution.txt | 4 +- Documentation/SubmittingPatches | 10 ++-- Documentation/git-fetch.txt | 8 +-- Documentation/git-ls-remote.txt | 4 +- Documentation/giteveryday.txt | 10 ++-- Documentation/gitworkflows.txt | 16 +++--- Documentation/howto/maintain-git.txt | 52 +++++++++---------- .../howto/rebase-from-internal-branch.txt | 32 ++++++------ Documentation/howto/revert-branch-rebase.txt | 32 ++++++------ Documentation/howto/update-hook-example.txt | 6 +-- Documentation/user-manual.txt | 2 +- t/t5505-remote.sh | 8 +-- t/t5516-fetch-push.sh | 16 +++--- t/t9902-completion.sh | 4 +- 14 files changed, 102 insertions(+), 102 deletions(-) base-commit: af6b65d45ef179ed52087e80cb089f6b2349f4ec Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-668%2Fdscho%2Faccommodate-for-pu-having-been-renamed-to-seen-v3 Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-668/dscho/accommodate-for-pu-having-been-renamed-to-seen-v3 Pull-Request: https://github.com/gitgitgadget/git/pull/668 Range-diff vs v2: 1: 35e3dafd6a ! 1: 13e03e0e65 docs: adjust for the recent rename of `pu` to `seen` @@ Documentation/gitworkflows.txt: As a given feature goes from experimental to sta -* 'pu' (proposed updates) is an integration branch for things that are - not quite ready for inclusion yet (see "Integration Branches" - below). -+* `seen` (patches seen by the maintainer) is an integration branch for ++* 'seen' (patches seen by the maintainer) is an integration branch for + things that are not quite ready for inclusion yet (see "Integration + Branches" below). 2: c2bcfdcb5b = 2: 13f3501c84 docs: adjust the technical overview for the rename `pu` -> `seen` 3: c8e356c02f = 3: e38ade2ee0 tests: reference `seen` wherever `pu` was referenced