Re: Suggestions for What's cooking
From: Junio C Hamano gits...@pobox.com Sent: Friday, September 14, 2012 3:29 AM Andrew Ardill andrew.ard...@gmail.com writes: On 14 September 2012 04:06, Junio C Hamano gits...@pobox.com wrote: Andrew Ardill andrew.ard...@gmail.com writes: short-branch-description long-branch-description notes next-steps * branch-name (creation-date) number-of-commits (merge-status) [list-of-commits] (branch-usage) I do not see how it makes any sense to have the This is where the section begins with, and its name is this line in the middle of a block indented in such a way. Care to explain? I'm not quite sure what aspect you are referring to,... Just this part, as I do not have much time. Here is your reordered one I will reject: A jc/maint-blame-no-such-path git blame MAKEFILE run in a history that has Makefile but not MAKEFILE should say No such file MAKEFILE in HEAD, but got confused on a case insensitive filesystem. B* jc/maint-blame-no-such-path (2012-09-10) 1 commit - blame $path: avoid getting fooled by case insensitive filesystems I was noting that B which *is* formatted as a header line (it EVEN has a leading asterisk to make it clear that it begins something new) is in the middle, and you added a redundant A that is not even marked clearly as a header line. Are we all working with Black text on a White background? (or is it vice versa) as this changes which bits of emphasis the eye will pick up. I'm reading the emails as black text against a white background. I find that for black text, in a block format, that one does not notice any special inital character, such as the '*', when it is part of a rectangular block. In fact I feel I tend to, if anything, down grade text begining with special characters as being bullet points below some main block text. Hence my suggestion to have either a visual break (extra line above), or a block indent (extra left hand space). Changing the contrast to white text on a black background totally changes what the eye/brain will see/notice [$dayjob is electro-optic vision systems where contrast inversion is a standard requirement for that reason]. It maybe that we are seeing different personal effects because of our set-ups. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suggestions for What's cooking
From: Junio C Hamano gits...@pobox.com Sent: Friday, September 14, 2012 5:47 AM Junio C Hamano gits...@pobox.com writes: I've played with both and have prepared patches to Reintegrate and cook (both in the 'todo' branch). Will play with the changes a bit more and then decide. So here is how tonight's What's cooking may look like with extra indentation and blank lines. The tools that read this file to help my workflow have been minimally adjusted. I am hoping that the updates to them I made were enough to make the format tweak not to negatively affect me, and so far things are going smoothly, but I may find some corner cases later. Knock wood... -- 8 -- snip +1. It looks good even when printed with a proportional width font. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suggestions for What's cooking
On 09/13/2012 12:49 AM, Philip Oakley wrote: My comment, as a simple reader, is that I misread the order of the items, in that I miss-associate the description paragraph with the * title _below_. That is, I see the description first and then read on... Thinking about it, if the description paragraph was indented by one space then the * title would create that obvious content indent that (I am) would be expected. +1. When I started reading the What's cooking, I found it hard to tell/remember whether text comments apply to the list of patches above them or below them. If you don't want to make bigger changes to the format, then even an extra blank line between the section about each patch series would remove the ambiguity. Otherwise, I think that What's cooking emails are a great service that you provide to the community. They help mitigate the inconvenience of using emails rather than pull requests for exchanging and managing patches :-) Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suggestions for What's cooking
From: Philip Oakley philipoak...@iee.org Sent: Wednesday, September 12, 2012 11:49 PM From: Jens Lehmann jens.lehm...@web.de Sent: Wednesday, September 12, 2012 8:21 PM Am 11.09.2012 21:41, schrieb Junio C Hamano: Thanks. I wish all others paid attention to What's cooking like you did here. And if it is hard to do so for whatever reason, suggest a better way for me to publish What's cooking or an equivalent (I am interested in finding the least bureaucratic way to help people and keep the balls rolling). I think What's cooking makes lots of sense in its current form as one gets a very good overview over current development tracks. Maybe in addition it would be nice to email the author(s) of a series when the state changes or new comments are added (and to only include the relevant part from What's cooking there). For me it's not a big problem as I just have to grep for submodule to get the bits I care about, but I suspect others might have to invest much more time to check the current state of their series and may appreciate being mailed directly when something happens. Opinions? My comment, as a simple reader, is that I misread the order of the items, in that I miss-associate the description paragraph with the * title _below_. That is, I see the description first and then read on... Thinking about it, if the description paragraph was indented by one space then the * title would create that obvious content indent that (I am) would be expected. Obviously only a useful suggestion if it's easy to implement... Philip Thinking overnight. One very simple option is to just add a double line spacing between items to give a clearer break. i.e. previous item ends.LF LF LF * Next Item -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suggestions for What's cooking
Andrew Ardill andrew.ard...@gmail.com writes: Currently, the output for each branch looks something like: * branch-name (creation-date) number-of-commits (merge-status) [list-of-commits] (branch-usage) long-description notes-and-memoranda next-steps and these are grouped by current integration status (new, graduated, stalled etc) Yes. Thanks for a concise summary. A format that would make this information easier for me to parse would be something like: short-branch-description long-branch-description notes next-steps * branch-name (creation-date) number-of-commits (merge-status) [list-of-commits] (branch-usage) I do not see how it makes any sense to have the This is where the section begins with, and its name is this line in the middle of a block indented in such a way. Care to explain? I can see some people may care more about the description than the list of commits [*1*], though. [Footnote] *1* It however is an indication that the title of each commit needs to be improved to convey enough information so that I do not have to write the branch description myself for them. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suggestions for What's cooking
Andrew Ardill andrew.ard...@gmail.com writes: On 14 September 2012 04:06, Junio C Hamano gits...@pobox.com wrote: Andrew Ardill andrew.ard...@gmail.com writes: short-branch-description long-branch-description notes next-steps * branch-name (creation-date) number-of-commits (merge-status) [list-of-commits] (branch-usage) I do not see how it makes any sense to have the This is where the section begins with, and its name is this line in the middle of a block indented in such a way. Care to explain? I'm not quite sure what aspect you are referring to,... Just this part, as I do not have much time. Here is your reordered one I will reject: A jc/maint-blame-no-such-path git blame MAKEFILE run in a history that has Makefile but not MAKEFILE should say No such file MAKEFILE in HEAD, but got confused on a case insensitive filesystem. B* jc/maint-blame-no-such-path (2012-09-10) 1 commit - blame $path: avoid getting fooled by case insensitive filesystems I was noting that B which *is* formatted as a header line (it EVEN has a leading asterisk to make it clear that it begins something new) is in the middle, and you added a redundant A that is not even marked clearly as a header line. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suggestions for What's cooking
On 14 September 2012 12:29, Junio C Hamano gits...@pobox.com wrote: Andrew Ardill andrew.ard...@gmail.com writes: On 14 September 2012 04:06, Junio C Hamano gits...@pobox.com wrote: Andrew Ardill andrew.ard...@gmail.com writes: short-branch-description long-branch-description notes next-steps * branch-name (creation-date) number-of-commits (merge-status) [list-of-commits] (branch-usage) I do not see how it makes any sense to have the This is where the section begins with, and its name is this line in the middle of a block indented in such a way. Care to explain? I'm not quite sure what aspect you are referring to,... Just this part, as I do not have much time. Here is your reordered one I will reject: A jc/maint-blame-no-such-path git blame MAKEFILE run in a history that has Makefile but not MAKEFILE should say No such file MAKEFILE in HEAD, but got confused on a case insensitive filesystem. B* jc/maint-blame-no-such-path (2012-09-10) 1 commit - blame $path: avoid getting fooled by case insensitive filesystems I was noting that B which *is* formatted as a header line (it EVEN has a leading asterisk to make it clear that it begins something new) is in the middle, and you added a redundant A that is not even marked clearly as a header line. The leading asterisk is actually not as useful to me, as indicating a header line, as the 'out-denting' I am proposing. I think this is due to the similarities between the asterisk and the other symbols used to indicate commits. This is maybe just a typographic issue, but I think in general the contrast between letters and spaces appearing in the first columns of text is stronger than either of characters and letters, or spaces and characters. A quick comparison of all three: --Letters and Spaces-- jc/maint-ident-missing-human-name git show --format='%ci' did not give timestamp correctly for... + split_ident_line(): make best effort when parsing author/committer line --Characters and Letters-- * jc/maint-ident-missing-human-name git show --format='%ci' did not give timestamp correctly for... + split_ident_line(): make best effort when parsing author/committer line --Characters and Spaces-- * jc/maint-ident-missing-human-name git show --format='%ci' did not give timestamp correctly for + split_ident_line(): make best effort when parsing author/committer line My preference would be first for letters and spaces, or if that is not good enough then characters and spaces. With regards to the comment that the old header line appears in the middle of the output, as I said earlier that was a consequence of reordering and indenting everything but otherwise leaving it as is. This should be changed, so how about: branch-name (creation-date) branch-description? notes-and-memoranda? next-steps? #-commits (merge-status?) [list-of-commits] (branch-usage?) eg: jc/maint-ident-missing-human-name (2012-08-31) git show --format='%ci' did not give timestamp correctly for commits created without human readable name on committer line. 1 commit (merged to 'next' on 2012-09-07 at 0e99b20) + split_ident_line(): make best effort when parsing author/committer line with no description: sl/autoconf (2012-09-11) 2 commits - build: don't duplicate substitution of make variables - build: improve GIT_CONF_SUBST signature Hopefully that makes more sense and addresses the concerns you raised. Adding an asterisk at the start is ok by me, if that is something you think is needed. One thing I did think about, when leaving the asterisk in the middle of the listing in the first version, was how machine readable the format was. I'm not sure if that is important, but the asterisk was a clear signal that what followed was a listing of commits. In any case, the new and revised format is perhaps slightly less machine readable as a result. I feel a little bit like I might be bikeshedding this, however I do think an improvement to the formatting of What's cooking is a meaningful one for the project! Regards, Andrew Ardill -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suggestions for What's cooking
Junio C Hamano gits...@pobox.com writes: I've played with both and have prepared patches to Reintegrate and cook (both in the 'todo' branch). Will play with the changes a bit more and then decide. So here is how tonight's What's cooking may look like with extra indentation and blank lines. The tools that read this file to help my workflow have been minimally adjusted. I am hoping that the updates to them I made were enough to make the format tweak not to negatively affect me, and so far things are going smoothly, but I may find some corner cases later. Knock wood... -- 8 -- To: git@vger.kernel.org Bcc: l...@lwn.net Subject: What's cooking in git.git (Sep 2012, #05; Thu, 13) X-master-at: ce5cf6ffc6feb9fb4f9a50cdfa2f527fa119c94f X-next-at: dd7cb6d65b94d88f3bfb9efefabd5818614bf587 What's cooking in git.git (Sep 2012, #05; Thu, 13) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. ***BLURB*** I'm planning to keep this cycle reasonably short and aim for tagging the result as 1.8.0 at the end of 9th week, on October 21st, after which I'd disappear for a few weeks. http://tinyurl.com/gitCal is where you can always find my rough tagging schedule at. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * jw/doc-commit-title (2012-09-13) 1 commit - Documentation: describe subject more precisely Update parts of document that talked about first line of commit log to say title of commit with definition of what that title is. Will merge to 'next' after eyeballing. * nd/maint-diffstat-summary (2012-09-13) 1 commit - Revert diffstat summary back to English Earlier we made the diffstat summary line that shows the number of lines added/deleted localizable, but it was found irritating having to see them in various languages on a list whose discussion language is English. Breaks many tests which need to be fixed before moving forward. * nd/fetch-status-alignment (2012-09-12) 2 commits - [FIXUP] %.*s width must be int, not size_t - fetch: align per-ref summary report in UTF-8 locales Will merge to 'next' after squashing the fix-up. * mv/cherry-pick-s (2012-09-13) 1 commit . cherry-pick: don't forget -s on failure * jc/maint-log-grep-all-match (2012-09-13) 3 commits - log: document use of multiple commit limiting options - log --grep/--author: honor --all-match honored for multiple --grep patterns - grep: teach --debug option to dump the parse tree Fix a long-standing bug in git log --grep when multiple --grep are used together with --all-match and --author or --committer. -- [Stalled] * ph/credential-refactor (2012-09-02) 5 commits - wincred: port to generic credential helper - Merge branch 'ef/win32-cred-helper' into ph/credential-refactor - osxkeychain: port to generic credential helper implementation - gnome-keyring: port to generic helper implementation - contrib: add generic credential helper Attempts to refactor to share code among OSX keychain, Gnome keyring and Win32 credential helpers. * jc/maint-name-rev (2012-09-04) 7 commits - describe --contains: use name-rev --weight - name-rev --weight: tests and documentation - name-rev --weight: cache the computed weight in notes - name-rev --weight: trivial optimization - name-rev: --weight option - name_rev: clarify the logic to assign a new tip-name to a commit - name-rev: lose unnecessary typedef git name-rev names the given revision based on a ref that can be reached in the smallest number of steps from the rev, but that is not useful when the caller wants to know which tag is the oldest one that contains the rev. This teaches a new mode to the command that uses the oldest ref among those which contain the rev. I am not sure if this is worth it; for one thing, even with the help from notes-cache, it seems to make the describe --contains even slower. Also the command will be unusably slow for a user who does not have a write access (hence unable to create or update the notes-cache). Needs another round to at least find a better name for the option, and possibly a cheaper but still better than the current close to the tip heuristics. * ms/contrib-thunderbird-updates (2012-08-31) 2 commits - [SQUASH] minimum fixup - Thunderbird: fix appp.sh format problems Update helper to send out format-patch output using Thunderbird. Seems to have design regression for silent users. * as/check-ignore (2012-09-02) 10 commits . fixup: decl-after-stmt etc. . Add git-check-ignore . Provide free_directory() for reclaiming dir_struct memory . Extract some useful pathspec handling code from builtin/add.c into a library .
Suggestions for What's cooking
Am 11.09.2012 21:41, schrieb Junio C Hamano: Thanks. I wish all others paid attention to What's cooking like you did here. And if it is hard to do so for whatever reason, suggest a better way for me to publish What's cooking or an equivalent (I am interested in finding the least bureaucratic way to help people and keep the balls rolling). I think What's cooking makes lots of sense in its current form as one gets a very good overview over current development tracks. Maybe in addition it would be nice to email the author(s) of a series when the state changes or new comments are added (and to only include the relevant part from What's cooking there). For me it's not a big problem as I just have to grep for submodule to get the bits I care about, but I suspect others might have to invest much more time to check the current state of their series and may appreciate being mailed directly when something happens. Opinions? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suggestions for What's cooking
On Wed, Sep 12, 2012 at 3:21 PM, Jens Lehmann jens.lehm...@web.de wrote: Am 11.09.2012 21:41, schrieb Junio C Hamano: Thanks. I wish all others paid attention to What's cooking like you did here. And if it is hard to do so for whatever reason, suggest a better way for me to publish What's cooking or an equivalent (I am interested in finding the least bureaucratic way to help people and keep the balls rolling). I think What's cooking makes lots of sense in its current form as one gets a very good overview over current development tracks. Maybe in addition it would be nice to email the author(s) of a series when the state changes or new comments are added (and to only include the relevant part from What's cooking there). For me it's not a big problem as I just have to grep for submodule to get the bits I care about, but I suspect others might have to invest much more time to check the current state of their series and may appreciate being mailed directly when something happens. Opinions? I was thinking about this earlier. I wondered if it might even be worth it just to CC the authors of all topics whose status has changed since the last what's cooking, to make sure that they see updates pertinent to them. I know that I at least have filters which catch emails which CC me and promote them to my inbox, so I would see them more readily. My normal mode of operation is that when I have a patch in I check all the What's cooking messages as if I was F5-ing a webpage, to follow its status. Were I CCd on the message, I would be updated whenever the mail was sent, which I would appreciate. This also has the nice side effect of updating patch authors who are not subscribed to the list. On the other hand, its possible some people would find that this generated lots of noise, and it might also cause unrelated replies to the What's Cooking message to CC all authors. -- -Dan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suggestions for What's cooking
From: Jens Lehmann jens.lehm...@web.de Sent: Wednesday, September 12, 2012 8:21 PM Am 11.09.2012 21:41, schrieb Junio C Hamano: Thanks. I wish all others paid attention to What's cooking like you did here. And if it is hard to do so for whatever reason, suggest a better way for me to publish What's cooking or an equivalent (I am interested in finding the least bureaucratic way to help people and keep the balls rolling). I think What's cooking makes lots of sense in its current form as one gets a very good overview over current development tracks. Maybe in addition it would be nice to email the author(s) of a series when the state changes or new comments are added (and to only include the relevant part from What's cooking there). For me it's not a big problem as I just have to grep for submodule to get the bits I care about, but I suspect others might have to invest much more time to check the current state of their series and may appreciate being mailed directly when something happens. Opinions? My comment, as a simple reader, is that I misread the order of the items, in that I miss-associate the description paragraph with the * title _below_. That is, I see the description first and then read on... Thinking about it, if the description paragraph was indented by one space then the * title would create that obvious content indent that (I am) would be expected. Obviously only a useful suggestion if it's easy to implement... Philip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suggestions for What's cooking
(sorry about double replying - html sub-part creeped in!) On 13 September 2012 08:49, Philip Oakley philipoak...@iee.org wrote: From: Jens Lehmann jens.lehm...@web.de Sent: Wednesday, September 12, 2012 8:21 PM Am 11.09.2012 21:41, schrieb Junio C Hamano: Thanks. I wish all others paid attention to What's cooking like you did here. And if it is hard to do so for whatever reason, suggest a better way for me to publish What's cooking or an equivalent (I am interested in finding the least bureaucratic way to help people and keep the balls rolling). I think What's cooking makes lots of sense in its current form as one gets a very good overview over current development tracks. Maybe in addition it would be nice to email the author(s) of a series when the state changes or new comments are added (and to only include the relevant part from What's cooking there). For me it's not a big problem as I just have to grep for submodule to get the bits I care about, but I suspect others might have to invest much more time to check the current state of their series and may appreciate being mailed directly when something happens. Opinions? My comment, as a simple reader, is that I misread the order of the items, in that I miss-associate the description paragraph with the * title _below_. That is, I see the description first and then read on... Thinking about it, if the description paragraph was indented by one space then the * title would create that obvious content indent that (I am) would be expected. Obviously only a useful suggestion if it's easy to implement... I can attest to the fact that the format can be at times difficult to parse, and I often find myself rereading sections to make sure I understood what each was referring to. As a casual reader, interested in the development that is going on, the things I am interested in for each branch/topic are like: - Branch/Topic description - Current integration status - Next steps required - Notes and memoranda I understand that references to where the branch is found (it's name) and what it includes (commit list) are important too, but these are less important for me. Currently, the output for each branch looks something like: * branch-name (creation-date) number-of-commits (merge-status) [list-of-commits] (branch-usage) long-description notes-and-memoranda next-steps and these are grouped by current integration status (new, graduated, stalled etc) A format that would make this information easier for me to parse would be something like: short-branch-description long-branch-description notes next-steps * branch-name (creation-date) number-of-commits (merge-status) [list-of-commits] (branch-usage) Essentially, shifting the details of the branch to the bottom, and adding a short description for the entire branch. Indent everything after the short description to make it clear that they belong together. The only real 'new' information required is the short description, but that could be replaced with the topic name if short description is not available (or the topic name is self explanatory). Most of the parsing benefit would come from the indentation, but having the 'summary' information near the top would let me skip things I am not interested in without having to scan the list of commits and other details. Regards, Andrew Ardill -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
