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

Re: [PATCH v2 00/22] i18n and test updates

From
Vasco Almeida <vascomalmeida@sapo.pt>
Date
May 28, 2016, 08:18 UTC
Message-ID
<57495473.2010903@sapo.pt>
In-Reply-To
<xmqq8tyvs9xf.fsf@gitster.mtv.corp.google.com>
Às 17:11 de 27-05-2016, Junio C Hamano escreveu:
Show 9 quoted lines
> Vasco Almeida <vascomalmeida@sapo.pt> writes:
> 
>> Marks several messages for translation and updates tests to pass under
>> GETTEXT_POISON. Some tests were updated to fit previous i18n marks, others
>> were updated to fit marks made by these patches. Patches that only touch
>> test file refer to marks done in commits previous to these ones.
> 
> Whew, this series is quite a lot of work.
> 

Do you mean review work? Submitting patches is still a new thing for me. I don't know how to organize or split well the patch series, if they're too long, in order to make other's work easier and the patches themselves more appealing.

I have got other patches that I've made on top of these ones, but don't know whether I should 1) rebase them on top of master, if they apply cleanly, and send them in a new patch series, or just 2) send them together in the next re-roll. New patches are also about i18n.

I've tried scavenging mailing list and documentation (not too hard, I confess) for a explicit hint on this and eventually other best/desired practices but found nothing so far, beside the content of Documentation/SubmittingPatches of course. If somebody could point me to something like that, that would be great.

I also naturally expect that, if I'm doing something wrong or lesser, someone will bring it to my attention so I can correct.

(The first time I've sent patches here, I then sent 2 more patches alone in their own series [1], but Junio Hamano put them together in one va/i18n-misc-updates branch, reasonable decision since that and the previous series were all i18n patches, hence all related. That made me suspect that option 2) is better. After that, I've sent a re-roll of first series, and Junio Hamano thought for a moment that I had dropped the 2 patches from the second one [2]. So it seems that, at least in this case, option 1) can confuse people.)

[1] http://thread.gmane.org/gmane.comp.version-control.git/291386 [2] http://thread.gmane.org/gmane.comp.version-control.git/291860/focus=291914

Previous: Junio C HamanoNext: Junio C Hamano
Message 37 of 38 in “i18n and test updates”
  1. 00/22 i18n and test updatesVasco Almeida, May 23, 2016
  2. 01/22 i18n: builtin/remote.c: fix mark for translationVasco Almeida, May 23, 2016
  3. 02/22 i18n: advice: mark string about detached head for translationVasco Almeida, May 23, 2016
  4. Vasco AlmeidaMay 30, 2016
  5. 03/22 i18n: advice: internationalize message for conflictsVasco Almeida, May 23, 2016
  6. 04/22 i18n: transport: mark strings for translationVasco Almeida, May 23, 2016
  7. 05/22 i18n: sequencer: mark entire sentences for translationVasco Almeida, May 23, 2016
  8. 06/22 i18n: sequencer: mark string for translationVasco Almeida, May 23, 2016
  9. 07/22 i18n: merge-octopus: mark messages for translationVasco Almeida, May 23, 2016
  10. 08/22 merge-octupus: use die shell function from git-sh-setup.shVasco Almeida, May 23, 2016
  11. 09/22 i18n: rebase: fix marked string to use eval_gettext variantVasco Almeida, May 23, 2016
  12. 10/22 i18n: rebase: mark placeholder for translationVasco Almeida, May 23, 2016
  13. 11/22 i18n: bisect: simplify error message for i18nVasco Almeida, May 23, 2016
  14. 12/22 t6030: update to use test_i18ncmpVasco Almeida, May 23, 2016
  15. 13/22 i18n: git-sh-setup.sh: mark strings for translationVasco Almeida, May 23, 2016
  16. Junio C HamanoMay 26, 2016
  17. Vasco AlmeidaMay 27, 2016
  18. 14/22 i18n: rebase-interactive: mark strings for translationVasco Almeida, May 23, 2016
  19. Junio C HamanoMay 26, 2016
  20. Vasco AlmeidaMay 27, 2016
  21. Junio C HamanoMay 27, 2016
  22. 15/22 i18n: rebase-interactive: mark here-doc strings for translationVasco Almeida, May 23, 2016
  23. Vasco AlmeidaMay 25, 2016
  24. 16/22 i18n: rebase-interactive: mark comments of squash for translationVasco Almeida, May 23, 2016
  25. Junio C HamanoMay 26, 2016
  26. Vasco AlmeidaMay 27, 2016
  27. 17/22 i18n: setup: mark strings for translationVasco Almeida, May 23, 2016
  28. 18/22 tests: use test_i18n* functions to suppress false positivesVasco Almeida, May 23, 2016
  29. Junio C HamanoMay 27, 2016
  30. Vasco AlmeidaMay 27, 2016
  31. Junio C HamanoMay 27, 2016
  32. 19/22 tests: unpack-trees: update to use test_i18n* functionsVasco Almeida, May 23, 2016
  33. 20/22 t9003: become resilient to GETTEXT_POISONVasco Almeida, May 23, 2016
  34. 21/22 t4153: fix negated test_i18ngrep callVasco Almeida, May 23, 2016
  35. 22/22 t5523: use test_i18ngrep for negationVasco Almeida, May 23, 2016
  36. Junio C HamanoMay 27, 2016
  37. Vasco AlmeidaMay 28, 2016
  38. Junio C HamanoMay 30, 2016

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.