* [PATCH 0/4] Use oid_object_info() instead of read_object_file() @ 2018-07-09 8:27 Оля Тележная 2018-07-09 22:42 ` Junio C Hamano ` (2 more replies) 0 siblings, 3 replies; 6+ messages in thread From: Оля Тележная @ 2018-07-09 8:27 UTC (permalink / raw) To: git, Junio C Hamano, Jeff King, Christian Couder Hello everyone, This is my new attempt to start using oid_object_info_extended() in ref-filter. You could look at previous one [1] [2] but it is not necessary. The goal (still) is to improve performance by avoiding calling expensive functions when we don't need the information they provide or when we could get it by using a cheaper function. This patch is a middle step. In the end, I want to add new atoms ("objectsize:disk" and "deltabase") and reuse ref-filter logic in cat-file command. I also know about problems with memory leaks in ref-filter: that would be my next task that I will work on. Since I did not generate any new leaks in this patch (just use existing ones), I decided to put this part on a review and fix leaks as a separate task. Thank you! [1] https://github.com/git/git/pull/493 [2] https://public-inbox.org/git/010201637254c969-a346030e-0b75-41ad-8ef3-2ac7e04ba4fb-000000@eu-west-1.amazonses.com/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 0/4] Use oid_object_info() instead of read_object_file() 2018-07-09 8:27 [PATCH 0/4] Use oid_object_info() instead of read_object_file() Оля Тележная @ 2018-07-09 22:42 ` Junio C Hamano 2018-07-10 9:47 ` Johannes Schindelin 2018-07-13 12:46 ` Оля Тележная 2 siblings, 0 replies; 6+ messages in thread From: Junio C Hamano @ 2018-07-09 22:42 UTC (permalink / raw) To: Оля Тележная Cc: git, Jeff King, Christian Couder Оля Тележная <olyatelezhnaya@gmail.com> writes: > Hello everyone, > This is my new attempt to start using oid_object_info_extended() in > ref-filter. You could look at previous one [1] [2] but it is not > necessary. Yup, it sounds like a sensible thing to do to try asking object-info helper instead of reading the whole object in-core and inspecting it ourselves when we can avoid it. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 0/4] Use oid_object_info() instead of read_object_file() 2018-07-09 8:27 [PATCH 0/4] Use oid_object_info() instead of read_object_file() Оля Тележная 2018-07-09 22:42 ` Junio C Hamano @ 2018-07-10 9:47 ` Johannes Schindelin 2018-07-13 12:46 ` Оля Тележная 2 siblings, 0 replies; 6+ messages in thread From: Johannes Schindelin @ 2018-07-10 9:47 UTC (permalink / raw) To: Оля Тележная Cc: git, Junio C Hamano, Jeff King, Christian Couder [-- Attachment #1: Type: text/plain, Size: 2763 bytes --] Hi Olga, On Mon, 9 Jul 2018, Оля Тележная wrote: > [2] https://public-inbox.org/git/010201637254c969-a346030e-0b75-41ad-8ef3-2ac7e04ba4fb-000000@eu-west-1.amazonses.com/ This type of Message-Id makes me think that you used SubmitGit to send this patch series. The main problem I see here is that the patches are not sent as replies to this cover letter, and therefore they are seemingly disconnected on the mailing list. It was also my impression that SubmitGit started supporting sending cover letters, in which case you would not have to jump through hoops to thread the mails properly. But for that to work, the PR has to have a description which is then used as cover letter. I do not see any description in https://github.com/git/git/pull/520, though. Maybe provide one? Ciao, Johannes P.S.: You might have noticed that I am working (slowly, but steadily) on a contender for SubmitGit that I call GitGitGadget. Originally, I really wanted to enhance SubmitGit instead because I am a big believer of *not* reinventing the wheel (so much energy gets wasted that way). However, in this case the limitations of the chosen language (I do not want to learn Scala, I have absolutely zero need to know Scala in any of my other endeavors, and my time to learn new things is limited, so I spend it wisely) and the limitations of the design (the UI is completely separate from GitHub, you have to allow Amazon to send mails in your name, and SubmitGit's design makes it impossible to work bi-directionally, it is only GitHub -> mailing list, while I also want the option to add replies on the mailing list as comments to the GitHub PR in the future) made me reconsider. If you want to kick the tires, so to say, I welcome you to give GitGitGadget a try. It would require only a couple of things from you: - You would have to settle for a branch name, and then not open new PRs for every iteration you want to send, but force-push the branch instead. - You would have to open a PR at https://github.com/gitgitgadget/git. - You would have to provide the cover letter via the PR's description (and update that description before sending newer iterations). - I would have to add you to the list of users allowed to send patches via GitGitGadget (GitGitGadget has some really light-weight access control to prevent spamming). - You would then send a new iteration by simply adding a comment to your PR that contains this command: /submit - To integrate well with previous patch series iterations (i.e. to connect the threads), I would have to come up with a little bit of tooling to add some metadata that I have to reconstruct manually from your previously-sent iterations. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 0/4] Use oid_object_info() instead of read_object_file() 2018-07-09 8:27 [PATCH 0/4] Use oid_object_info() instead of read_object_file() Оля Тележная 2018-07-09 22:42 ` Junio C Hamano 2018-07-10 9:47 ` Johannes Schindelin @ 2018-07-13 12:46 ` Оля Тележная 2018-07-18 12:13 ` Johannes Schindelin 2 siblings, 1 reply; 6+ messages in thread From: Оля Тележная @ 2018-07-13 12:46 UTC (permalink / raw) To: git, Junio C Hamano, Jeff King, Christian Couder 2018-07-09 11:27 GMT+03:00 Оля Тележная <olyatelezhnaya@gmail.com>: > Hello everyone, > This is my new attempt to start using oid_object_info_extended() in > ref-filter. You could look at previous one [1] [2] but it is not > necessary. > > The goal (still) is to improve performance by avoiding calling expensive > functions when we don't need the information they provide > or when we could get it by using a cheaper function. > > This patch is a middle step. In the end, I want to add new atoms > ("objectsize:disk" and "deltabase") and reuse ref-filter logic in > cat-file command. > > I also know about problems with memory leaks in ref-filter: that would > be my next task that I will work on. Since I did not generate any new > leaks in this patch (just use existing ones), I decided to put this > part on a review and fix leaks as a separate task. UPDATES since v1: add init to eaten variable (thanks to Szeder Gabor, Johannes Schindelin) improve second commit message (thanks to Junio C Hamano) add static keyword (thanks to Ramsay Jones) > > Thank you! > > [1] https://github.com/git/git/pull/493 > [2] https://public-inbox.org/git/010201637254c969-a346030e-0b75-41ad-8ef3-2ac7e04ba4fb-000000@eu-west-1.amazonses.com/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 0/4] Use oid_object_info() instead of read_object_file() 2018-07-13 12:46 ` Оля Тележная @ 2018-07-18 12:13 ` Johannes Schindelin 2018-07-18 17:56 ` Junio C Hamano 0 siblings, 1 reply; 6+ messages in thread From: Johannes Schindelin @ 2018-07-18 12:13 UTC (permalink / raw) To: Оля Тележная Cc: git, Junio C Hamano, Jeff King, Christian Couder [-- Attachment #1: Type: text/plain, Size: 1523 bytes --] Hi Olga, On Fri, 13 Jul 2018, Оля Тележная wrote: > 2018-07-09 11:27 GMT+03:00 Оля Тележная <olyatelezhnaya@gmail.com>: > > Hello everyone, > > This is my new attempt to start using oid_object_info_extended() in > > ref-filter. You could look at previous one [1] [2] but it is not > > necessary. > > > > The goal (still) is to improve performance by avoiding calling expensive > > functions when we don't need the information they provide > > or when we could get it by using a cheaper function. > > > > This patch is a middle step. In the end, I want to add new atoms > > ("objectsize:disk" and "deltabase") and reuse ref-filter logic in > > cat-file command. > > > > I also know about problems with memory leaks in ref-filter: that would > > be my next task that I will work on. Since I did not generate any new > > leaks in this patch (just use existing ones), I decided to put this > > part on a review and fix leaks as a separate task. > > UPDATES since v1: > add init to eaten variable (thanks to Szeder Gabor, Johannes Schindelin) > improve second commit message (thanks to Junio C Hamano) > add static keyword (thanks to Ramsay Jones) > > > > > Thank you! > > > > [1] https://github.com/git/git/pull/493 Could you please populate the description of that PR so that SubmitGit picks it up as cover letter? Thanks, Johannes > > [2] https://public-inbox.org/git/010201637254c969-a346030e-0b75-41ad-8ef3-2ac7e04ba4fb-000000@eu-west-1.amazonses.com/ > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 0/4] Use oid_object_info() instead of read_object_file() 2018-07-18 12:13 ` Johannes Schindelin @ 2018-07-18 17:56 ` Junio C Hamano 0 siblings, 0 replies; 6+ messages in thread From: Junio C Hamano @ 2018-07-18 17:56 UTC (permalink / raw) To: Johannes Schindelin Cc: Оля Тележная, git, Jeff King, Christian Couder Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > Hi Olga, > > On Fri, 13 Jul 2018, Оля Тележная wrote: > >> 2018-07-09 11:27 GMT+03:00 Оля Тележная <olyatelezhnaya@gmail.com>: >> > Hello everyone, >> > This is my new attempt to start using oid_object_info_extended() in >> > ref-filter. You could look at previous one [1] [2] but it is not >> > necessary. >> > >> > The goal (still) is to improve performance by avoiding calling expensive >> > functions when we don't need the information they provide >> > or when we could get it by using a cheaper function. >> > >> > This patch is a middle step. In the end, I want to add new atoms >> > ("objectsize:disk" and "deltabase") and reuse ref-filter logic in >> > cat-file command. >> > >> > I also know about problems with memory leaks in ref-filter: that would >> > be my next task that I will work on. Since I did not generate any new >> > leaks in this patch (just use existing ones), I decided to put this >> > part on a review and fix leaks as a separate task. >> >> UPDATES since v1: >> add init to eaten variable (thanks to Szeder Gabor, Johannes Schindelin) >> improve second commit message (thanks to Junio C Hamano) >> add static keyword (thanks to Ramsay Jones) >> >> > >> > Thank you! >> > >> > [1] https://github.com/git/git/pull/493 > > Could you please populate the description of that PR so that SubmitGit > picks it up as cover letter? Thanks for suggesting that. Yes, an updated version of a series, even if it is a small one with just 4 or 5 patches, becomes much easier to read with a well-written cover letter. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-07-18 17:56 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-07-09 8:27 [PATCH 0/4] Use oid_object_info() instead of read_object_file() Оля Тележная 2018-07-09 22:42 ` Junio C Hamano 2018-07-10 9:47 ` Johannes Schindelin 2018-07-13 12:46 ` Оля Тележная 2018-07-18 12:13 ` Johannes Schindelin 2018-07-18 17:56 ` Junio C Hamano
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).