Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)
Junio C Hamano writes: > The tip of 'next' hasn't been rewound yet, but the states of many > topics that were marked to "Cook in 'next'" read "Will merge to > 'master'" now. I'll probably start merging a handful of topics that > have been in 'next' down to 'master' tonight (they appear at the > bottom of "log --first-parent master..pu" output). A bunch of topics have been merged to 'master' and also to 'next' with today's update. The tip of 'next' hasn't been rewound. I am hoping that we can thin down the difference between 'master' and 'next' by merging a bit more topic from 'next' to 'master' without adding more topics to 'next' for a week or so, and then rebuild 'next' at the end of that period, and then start to accept more topics to 'next'.
Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)
Derrick Stolee writes: >> Replaced with a newer version. > > I think this has been the same note for a few weeks now. What does it > mean? Did I send a new version out that you haven't picked up? It just means that I didn't bother to look at the current status message for the topic that had no activity X-<. > Also, my "git log --topo-order" series was never picked up, but I see > it has conflicts with 'next' now, so I'll rebase to resolve conflicts > and send a v2. Good idea, as I do not recall anything about that series.
Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)
On 9/14/2018 5:56 PM, Junio C Hamano wrote: * ds/format-commit-graph-docs (2018-08-21) 2 commits - commit-graph.txt: improve formatting for asciidoc - Docs: Add commit-graph tech docs to Makefile Design docs for the commit-graph machinery is now made into HTML as well as text. Will discard. I am inclined to drop these, as I do not see much clarity in HTML output over the text source. Opinions? Discarding is fine. I originally created it because I thought we were supposed to mark all documents for HTML generation. You're right, the HTML doesn't add anything. * ds/commit-graph-with-grafts (2018-08-21) 8 commits - commit-graph: close_commit_graph before shallow walk - commit-graph: not compatible with uninitialized repo - commit-graph: not compatible with grafts - commit-graph: not compatible with replace objects - test-repository: properly init repo - commit-graph: update design document - refs.c: upgrade for_each_replace_ref to be a each_repo_ref_fn callback - refs.c: migrate internal ref iteration to pass thru repository argument The recently introduced commit-graph auxiliary data is incompatible with mechanisms such as replace & grafts that "breaks" immutable nature of the object reference relationship. Disable optimizations based on its use (and updating existing commit-graph) when these incompatible features are in use in the repository. Replaced with a newer version. I think this has been the same note for a few weeks now. What does it mean? Did I send a new version out that you haven't picked up? Also, my "git log --topo-order" series was never picked up, but I see it has conflicts with 'next' now, so I'll rebase to resolve conflicts and send a v2. Thanks, -Stolee
Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)
Jeff King wrote: > Let me inject some more uncertainty, then. ;) > > If we are not going to do 3/3, then should 2/3 simply avoid passing "-1" > back via return from main? I guess I don't have a strong opinion, but > one of the things I noted was that we converted those die() calls > introduced in 2/3 back into returns in 3/3. Do we want to leave it in > the state where we are calling die() a lot more? Would you mind replying in the patch thread instead of this what's cooking email? That way, I can understand your suggestion better in context, I can find it more easily later, I would feel less bad about adding noise by replying, etc. Thanks, Jonathan
Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)
On Mon, Sep 17, 2018 at 10:51:35AM -0700, Junio C Hamano wrote: > Jeff King writes: > > >> > What's the donness of this one? > >> > cf. <20180717201348.gd26...@sigill.intra.peff.net> > >> > >> This topic has stayed in 'pu' for a long time. I thought it was > >> concluded that this was a good change? Jeff, Jonathan? > > > > I read over the thread again. I don't think I actually have any > > complaints about the patches as-is. There was some discussion from Junio > > and Ævar about the third one. I don't have a strong opinion. My > > experience has been that "gc --auto" is garbage anyway on the server > > side, but I think Ævar's experience is that it's reasonable for small to > > medium sites (which seems plausible to me). > > > > The message-id quoted there is my "this looks good". I mentioned a few > > possible nits, but I think it would be OK with or without them > > addressed. > > That matches my reading of your position. I tend to agree with > Ævar's recommendation to postpone 3/3 and use 1 & 2 for now. Let me inject some more uncertainty, then. ;) If we are not going to do 3/3, then should 2/3 simply avoid passing "-1" back via return from main? I guess I don't have a strong opinion, but one of the things I noted was that we converted those die() calls introduced in 2/3 back into returns in 3/3. Do we want to leave it in the state where we are calling die() a lot more? -Peff
Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)
Jeff King writes: >> > What's the donness of this one? >> > cf. <20180717201348.gd26...@sigill.intra.peff.net> >> >> This topic has stayed in 'pu' for a long time. I thought it was >> concluded that this was a good change? Jeff, Jonathan? > > I read over the thread again. I don't think I actually have any > complaints about the patches as-is. There was some discussion from Junio > and Ævar about the third one. I don't have a strong opinion. My > experience has been that "gc --auto" is garbage anyway on the server > side, but I think Ævar's experience is that it's reasonable for small to > medium sites (which seems plausible to me). > > The message-id quoted there is my "this looks good". I mentioned a few > possible nits, but I think it would be OK with or without them > addressed. That matches my reading of your position. I tend to agree with Ævar's recommendation to postpone 3/3 and use 1 & 2 for now. By the way, people shouldn't read too much into the messages referred to in "What's cooking"; they are not "these messages point out all the issues that block the topic". It's just "I am aware of this thread, which readers would hopefully find a good starting point to form their opinions". Thanks.
Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)
Antonio Ospite writes: > I did send a v4 addressing this: > https://public-inbox.org/git/20180824132951.8000-1-...@ao2.it/ > > In case you missed it I might as well send a v5 with some minor > cosmetic touches suggested by Ævar: > https://public-inbox.org/git/87wosfesxl@evledraar.gmail.com/ Thanks, will take a look.
Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)
"brian m. carlson" writes: > On Fri, Sep 14, 2018 at 02:56:36PM -0700, Junio C Hamano wrote: >> * bc/hash-independent-tests (2018-09-13) 12 commits >> - t5318: use test_oid for HASH_LEN >> - t1407: make hash size independent >> - t1406: make hash-size independent >> - t1405: make hash size independent >> - t1400: switch hard-coded object ID to variable >> - t1006: make hash size independent >> - t0064: make hash size independent >> - t0027: make hash size independent > > Could you drop this particular patch (the t0027 fix)? I found an issue > with it that I'd like to address, and it would be easier for me to just > send a completely fixed version in the future since it doesn't have any > dependencies with the rest of the series. Thanks, will do.
Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)
On Sun, Sep 16, 2018 at 08:39:03AM +0200, Duy Nguyen wrote: > On Fri, Sep 14, 2018 at 11:56 PM Junio C Hamano wrote: > > * jn/gc-auto (2018-07-17) 3 commits > > - gc: do not return error for prior errors in daemonized mode > > - gc: exit with status 128 on failure > > - gc: improve handling of errors reading gc.log > > > > "gc --auto" ended up calling exit(-1) upon error, which has been > > corrected to use exit(1). Also the error reporting behaviour when > > daemonized has been updated to exit with zero status when stopping > > due to a previously discovered error (which implies there is no > > point running gc to improve the situation); we used to exit with > > failure in such a case. > > > > What's the donness of this one? > > cf. <20180717201348.gd26...@sigill.intra.peff.net> > > This topic has stayed in 'pu' for a long time. I thought it was > concluded that this was a good change? Jeff, Jonathan? I read over the thread again. I don't think I actually have any complaints about the patches as-is. There was some discussion from Junio and Ævar about the third one. I don't have a strong opinion. My experience has been that "gc --auto" is garbage anyway on the server side, but I think Ævar's experience is that it's reasonable for small to medium sites (which seems plausible to me). The message-id quoted there is my "this looks good". I mentioned a few possible nits, but I think it would be OK with or without them addressed. -Peff
Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)
On Sun, Sep 16 2018, Duy Nguyen wrote: > On Fri, Sep 14, 2018 at 11:56 PM Junio C Hamano wrote: >> * jn/gc-auto (2018-07-17) 3 commits >> - gc: do not return error for prior errors in daemonized mode >> - gc: exit with status 128 on failure >> - gc: improve handling of errors reading gc.log >> >> "gc --auto" ended up calling exit(-1) upon error, which has been >> corrected to use exit(1). Also the error reporting behaviour when >> daemonized has been updated to exit with zero status when stopping >> due to a previously discovered error (which implies there is no >> point running gc to improve the situation); we used to exit with >> failure in such a case. >> >> What's the donness of this one? >> cf. <20180717201348.gd26...@sigill.intra.peff.net> > > This topic has stayed in 'pu' for a long time. I thought it was > concluded that this was a good change? Jeff, Jonathan? There's still outstanding feedback on it, including my: https://public-inbox.org/git/878t69dgvx@evledraar.gmail.com/ I think it would be great to merge [12]/3 down, and have a re-submission of 3/3 stand-alone, once that's merged down, so we can untangle obviously correct bugfixes ([12]/3) with meaningful changes in exit code behavior (3/3).
Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)
On Fri, Sep 14, 2018 at 02:56:36PM -0700, Junio C Hamano wrote: > * bc/hash-independent-tests (2018-09-13) 12 commits > - t5318: use test_oid for HASH_LEN > - t1407: make hash size independent > - t1406: make hash-size independent > - t1405: make hash size independent > - t1400: switch hard-coded object ID to variable > - t1006: make hash size independent > - t0064: make hash size independent > - t0027: make hash size independent Could you drop this particular patch (the t0027 fix)? I found an issue with it that I'd like to address, and it would be easier for me to just send a completely fixed version in the future since it doesn't have any dependencies with the rest of the series. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)
On Fri, Sep 14, 2018 at 11:56 PM Junio C Hamano wrote: > * jn/gc-auto (2018-07-17) 3 commits > - gc: do not return error for prior errors in daemonized mode > - gc: exit with status 128 on failure > - gc: improve handling of errors reading gc.log > > "gc --auto" ended up calling exit(-1) upon error, which has been > corrected to use exit(1). Also the error reporting behaviour when > daemonized has been updated to exit with zero status when stopping > due to a previously discovered error (which implies there is no > point running gc to improve the situation); we used to exit with > failure in such a case. > > What's the donness of this one? > cf. <20180717201348.gd26...@sigill.intra.peff.net> This topic has stayed in 'pu' for a long time. I thought it was concluded that this was a good change? Jeff, Jonathan? -- Duy
Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)
On Fri, 14 Sep 2018 14:56:36 -0700 Junio C Hamano wrote: [...] > * ao/submodule-wo-gitmodules-checked-out (2018-08-14) 7 commits > - submodule: support reading .gitmodules even when it's not checked out > - t7506: clean up .gitmodules properly before setting up new scenario > - submodule: use the 'submodule--helper config' command > - submodule--helper: add a new 'config' subcommand > - t7411: be nicer to future tests and really clean things up > - submodule: factor out a config_set_in_gitmodules_file_gently function > - submodule: add a print_config_from_gitmodules() helper > > The submodule support has been updated to read from the blob at > HEAD:.gitmodules when the .gitmodules file is missing from the > working tree. > > Expecting a reroll. > > I find the design a bit iffy in that our usual "missing in the > working tree? let's use the latest blob" fallback is to take it > from the index, not from the HEAD. > Hi Junio, I did send a v4 addressing this: https://public-inbox.org/git/20180824132951.8000-1-...@ao2.it/ In case you missed it I might as well send a v5 with some minor cosmetic touches suggested by Ævar: https://public-inbox.org/git/87wosfesxl@evledraar.gmail.com/ Ciao, Antonio -- Antonio Ospite https://ao2.it https://twitter.com/ao2it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?
What's cooking in git.git (Sep 2018, #03; Fri, 14)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. The tip of 'next' hasn't been rewound yet, but the states of many topics that were marked to "Cook in 'next'" read "Will merge to 'master'" now. I'll probably start merging a handful of topics that have been in 'next' down to 'master' tonight (they appear at the bottom of "log --first-parent master..pu" output). The three GSoC "rewrite in C" topics are still unclassified in this "What's cooking" report, but I am hoping that we can have them in 'next' sooner rather than later. I got an impression that Dscho wanted a chance for the final clean-up on some of them, so I am not doing anything hasty yet at this moment, though. 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] * ab/fsck-skiplist (2018-09-12) 10 commits - fsck: support comments & empty lines in skipList - fsck: use oidset instead of oid_array for skipList - fsck: use strbuf_getline() to read skiplist file - fsck: add a performance test for skipList - fsck: add a performance test - fsck: document that skipList input must be unabbreviated - fsck: document and test commented & empty line skipList input - fsck: document and test sorted skipList input - fsck tests: add a test for no skipList input - fsck tests: setup of bogus commit object Update fsck.skipList implementation and documentation. Will merge to 'next'. * bc/hash-independent-tests (2018-09-13) 12 commits - t5318: use test_oid for HASH_LEN - t1407: make hash size independent - t1406: make hash-size independent - t1405: make hash size independent - t1400: switch hard-coded object ID to variable - t1006: make hash size independent - t0064: make hash size independent - t0027: make hash size independent - t0002: abstract away SHA-1 specific constants - t: update tests for SHA-256 - t: use hash translation table - t: add test functions to translate hash-related values Various tests have been updated to make it easier to swap the hash function used for object identification. Will merge to 'next'. * bp/mv-submodules-with-fsmonitor (2018-09-12) 1 commit - git-mv: allow submodules and fsmonitor to work together When fsmonitor is in use, after operation on submodules updates .gitmodules, we lost track of the fact that we did so and relied on stale fsmonitor data. Will merge to 'next'. * bp/read-cache-parallel (2018-09-13) 6 commits - SQUASH??? - read-cache: clean up casting and byte decoding - read-cache.c: optimize reading index format v4 - read-cache: load cache entries on worker threads - read-cache: load cache extensions on a worker thread - eoie: add End of Index Entry (EOIE) extension A new extension to the index file has been introduced, which allows the file to be read in parallel. Will merge to 'next' after squashing the fix in. * ds/coverage-diff (2018-09-12) 1 commit - contrib: add coverage-diff script The result of coverage test can be combined with "git blame" to check the test coverage of code introduced recently with a new 'coverage-diff' tool (in contrib/). Expecting a reroll. * ds/format-patch-range-diff-test (2018-09-12) 1 commit - t3206-range-diff.sh: cover single-patch case (this branch uses es/format-patch-interdiff and es/format-patch-rangediff.) Will merge to 'next'. * ds/multi-pack-verify (2018-09-13) 11 commits - fsck: verify multi-pack-index - multi-pack-index: report progress during 'verify' - multi-pack-index: verify object offsets - multi-pack-index: fix 32-bit vs 64-bit size check - multi-pack-index: verify oid lookup order - multi-pack-index: verify oid fanout order - multi-pack-index: verify missing pack - multi-pack-index: verify packname order - multi-pack-index: verify corrupt chunk lookup table - multi-pack-index: verify bad header - multi-pack-index: add 'verify' verb (this branch uses ds/multi-pack-index.) "git multi-pack-index" learned to detect corruption in the .midx file it uses, and this feature has been integrated into "git fsck". Will merge to 'next'. * en/sequencer-empty-edit-result-aborts (2018-09-13) 1 commit - sequencer: fix --allow-empty-message behavior, make it smarter "git rebase" etc. in Git 2.19 fails to abort when given an empty commit log message as result of editing, which has been corrected. Will merge to 'next'. * en/update-ref-no-deref-stdin (2018-09-12) 2 commits - update-ref: allow --no-deref with --stdin - update-ref: fix type of update_flags variable to match its usage "git update-ref" learned to make both "--no-deref" and "--stdin" work at the same time. Will merge to 'next'. * jt/l
