Re: master updated? (was Re: What's cooking in git.git (Nov 2018, #01; Thu, 1))
Derrick Stolee writes: > On 11/1/2018 5:59 AM, Junio C Hamano wrote: >> -- >> [Graduated to "master"] > > I see that several topics graduated, but it appears the master branch > was not updated at https://github.com/gister/git. Was this > intentional? The "Nov #1" issue of "What's cooking" report lists various topics including ah/doc-updates, ..., uk/merge- subtree-doc-update in the "Graduated" section by mistake (probably due to crossing month boundary); they already were listed in the previous "Oct #6" issue. Hopefully we'll have the following topics graduate to 'master' today, as part of the Eighth batch of the cycle. js/rebase-i-shortopt js/rebase-i-break js/rebase-autostash-fix cb/printf-empty-format jc/rebase-in-c-5-test-typofix pk/rebase-in-c-6-final js/rebase-in-c-5.5-work-with-rebase-i-in-c pk/rebase-in-c-5-test pk/rebase-in-c-4-opts pk/rebase-in-c-3-acts pk/rebase-in-c-2-basic ag/rebase-i-in-c pk/rebase-in-c Thanks.
master updated? (was Re: What's cooking in git.git (Nov 2018, #01; Thu, 1))
On 11/1/2018 5:59 AM, Junio C Hamano wrote:
--
[Graduated to "master"]
I see that several topics graduated, but it appears the master branch
was not updated at https://github.com/gister/git. Was this intentional?
I noticed because the test-coverage build [1] using the previous master
as master@{1} reported no uncovered code into master (because no new
commits exist on master).
Thanks,
-Stolee
[1] https://git.visualstudio.com/git/_build/results?buildId=237=log
Re: ab/* topics (was: Re: What's cooking in git.git (Nov 2018, #01; Thu, 1))
On Thu, Nov 01, 2018 at 02:46:41PM +0100, Ævar Arnfjörð Bjarmason wrote: > > However, if you push that patch with 'sh-i18n--helper' as-is, then I > > do object now: parsing a boolean in shell is not at all that difficult > > to justify this new command. > > So instead of calling a helper (which is undocumented, and only used by > git itself internally) you'd instead like to have some shellscript > thingy like: > > if test $value = 'true' -o $value = '1' [] > then > exit 0 > elif test $value = 'false' -o $value = '0' [...] Yes, but more like: case "$GIT_TEST_GETTEXT_POISON" in yes|true|on|1) GIT_INTERNAL_GETTEXT_SH_SCHEME=poison ;; esac There is no need to check for 'false', 0, etc. Yes, I know that this is not as fully-fledged as git_env_bool(), e.g. it won't recognize 'TrUe' and '42' as true, but since this is "merely" a testing aid, I think it's sufficient. > Sure, if that's the consensus I can change that, but it seems like the > opposite of the direction we're moving with the general *.sh -> *.c > migration. I.e. implementing helpers whenever possible instead of adding > new shellscript-only logic. I doubt that we really want to implement helpers "whenever possible", i.e. even instead of such a rather trivial piece of shell code. In the discusson of v1 of that patch there were suggestions on how to turn an environment variable into a boolean in a more proper way, e.g. by extending 'git var', but I agree with Peff that "we should do nothing for now and see how often this comes up" [1]. In the meantime this builtin seems to be the worse direction of all. [1] https://public-inbox.org/git/20181025212358.ga23...@sigill.intra.peff.net/
Re: ab/* topics (was: Re: What's cooking in git.git (Nov 2018, #01; Thu, 1))
On Thu, Nov 01 2018, SZEDER Gábor wrote: > On Thu, Nov 01, 2018 at 12:02:01PM +0100, Ævar Arnfjörð Bjarmason wrote: >> Could you please pick up >> https://public-inbox.org/git/20181024114725.3927-1-ava...@gmail.com/ ? >> It seems to have fallen between the cracks and addressed the feedback on >> v1, and looks good to me (and nobody's objected so far...). > > I didn't object, because in > > https://public-inbox.org/git/87muqzllh0@evledraar.gmail.com/ > > you asked for "a more general review than just the problem of how > we turn an env variable into a boolean". > > However, if you push that patch with 'sh-i18n--helper' as-is, then I > do object now: parsing a boolean in shell is not at all that difficult > to justify this new command. So instead of calling a helper (which is undocumented, and only used by git itself internally) you'd instead like to have some shellscript thingy like: if test $value = 'true' -o $value = '1' [] then exit 0 elif test $value = 'false' -o $value = '0' [...] Sure, if that's the consensus I can change that, but it seems like the opposite of the direction we're moving with the general *.sh -> *.c migration. I.e. implementing helpers whenever possible instead of adding new shellscript-only logic.
Re: ab/* topics (was: Re: What's cooking in git.git (Nov 2018, #01; Thu, 1))
On Thu, Nov 01, 2018 at 12:02:01PM +0100, Ævar Arnfjörð Bjarmason wrote: > Could you please pick up > https://public-inbox.org/git/20181024114725.3927-1-ava...@gmail.com/ ? > It seems to have fallen between the cracks and addressed the feedback on > v1, and looks good to me (and nobody's objected so far...). I didn't object, because in https://public-inbox.org/git/87muqzllh0@evledraar.gmail.com/ you asked for "a more general review than just the problem of how we turn an env variable into a boolean". However, if you push that patch with 'sh-i18n--helper' as-is, then I do object now: parsing a boolean in shell is not at all that difficult to justify this new command.
ab/* topics (was: Re: What's cooking in git.git (Nov 2018, #01; Thu, 1))
On Thu, Nov 01 2018, Junio C Hamano wrote: > * ab/push-dwim-dst (2018-10-29) 9 commits > - SQUASH??? > - push doc: document the DWYM behavior pushing to unqualified > - push: add DWYM support for "git push refs/remotes/...:" > - push: test that doesn't DWYM if is unqualified > - push: add an advice on unqualified push > - push: move unqualified refname error into a function > - push: improve the error shown on unqualified push > - i18n: remote.c: mark error(...) messages for translation > - remote.c: add braces in anticipation of a follow-up change > > "git push $there $src:$dst" rejects when $dst is not a fully > qualified refname and not clear what the end user meant. The > codepath has been taught to give a clearer error message, and also > guess where the push should go by taking the type of the pushed > object into account (e.g. a tag object would want to go under > refs/tags/). > > The last few steps are questionable. > cf. <87in1lkw54@evledraar.gmail.com> Will send an update to this soon. > * ab/pack-tests-cleanup (2018-10-31) 3 commits > - index-pack tests: don't leave test repo dirty at end > - pack-objects tests: don't leave test .git corrupt at end > - pack-objects test: modernize style > > A couple of tests used to leave the repository in a state that is > deliberately corrupt, which have been corrected. > > Will merge to 'next'. Thanks! > * ab/reject-alias-loop (2018-10-19) 1 commit > (merged to 'next' on 2018-10-26 at bc213f1bef) > + alias: detect loops in mixed execution mode > > Two (or more) aliases that mutually refer to each other can form an > infinite loop; we now attempt to notice and stop. > > Discarded. > Reverted out of 'next'. > cf. <87sh0slvxm@evledraar.gmail.com> *nod* will try to find time to work on this soon, but treating it as non-urgent. Could you please pick up https://public-inbox.org/git/20181024114725.3927-1-ava...@gmail.com/ ? It seems to have fallen between the cracks and addressed the feedback on v1, and looks good to me (and nobody's objected so far...).
What's cooking in git.git (Nov 2018, #01; Thu, 1)
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. Two groups of "rewrite rebase/rebase-i in C" topics, together with a handful of associated fix-up topics to them, will all be merged to 'master' tomorrow. Some of them haven't spent as much time as usual in 'next', so there still may be rough edges, but let's make sure we find them and smooth them out before the release. 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 -- [Graduated to "master"] * ah/doc-updates (2018-10-23) 6 commits (merged to 'next' on 2018-10-26 at b0bb46a602) + doc: fix formatting in git-update-ref + doc: fix indentation of listing blocks in gitweb.conf.txt + doc: fix descripion for 'git tag --format' + doc: fix inappropriate monospace formatting + doc: fix ASCII art tab spacing + doc: clarify boundaries of 'git worktree list --porcelain' Doc updates. * bc/hash-transition-part-15 (2018-10-15) 15 commits (merged to 'next' on 2018-10-26 at 4ff8111b4b) + rerere: convert to use the_hash_algo + submodule: make zero-oid comparison hash function agnostic + apply: rename new_sha1_prefix and old_sha1_prefix + apply: replace hard-coded constants + tag: express constant in terms of the_hash_algo + transport: use parse_oid_hex instead of a constant + upload-pack: express constants in terms of the_hash_algo + refs/packed-backend: express constants using the_hash_algo + packfile: express constants in terms of the_hash_algo + pack-revindex: express constants in terms of the_hash_algo + builtin/fetch-pack: remove constants with parse_oid_hex + builtin/mktree: remove hard-coded constant + builtin/repack: replace hard-coded constants + pack-bitmap-write: use GIT_MAX_RAWSZ for allocation + object_id.cocci: match only expressions of type 'struct object_id' More codepaths are moving away from hardcoded hash sizes. * cb/compat-mmap-is-private-read-only (2018-10-25) 1 commit (merged to 'next' on 2018-10-26 at d3bfab3034) + compat: make sure git_mmap is not expected to write Code tightening. * cb/khash-maybe-unused-function (2018-10-24) 2 commits (merged to 'next' on 2018-10-26 at 17fc4e55a0) + khash: silence -Wunused-function for delta-islands + commit-slabs: move MAYBE_UNUSED out Build fix. * cb/remove-dead-init (2018-10-19) 2 commits (merged to 'next' on 2018-10-26 at ba725a64ad) + multi-pack-index: avoid dead store for struct progress + unpack-trees: avoid dead store for struct progress Code clean-up. * ch/subtree-build (2018-10-18) 3 commits (merged to 'next' on 2018-10-18 at f89fd5e6aa) + Revert "subtree: make install targets depend on build targets" (merged to 'next' on 2018-10-16 at 919599cc37) + subtree: make install targets depend on build targets (merged to 'next' on 2018-10-12 at 4ed9ff6300) + subtree: add build targets 'man' and 'html' Build update for "git subtree" (in contrib/) documentation pages. * dl/mergetool-gui-option (2018-10-25) 3 commits (merged to 'next' on 2018-10-26 at 2c46355e81) + doc: document diff/merge.guitool config keys + completion: support `git mergetool --[no-]gui` + mergetool: accept -g/--[no-]gui as arguments "git mergetool" learned to take the "--[no-]gui" option, just like "git difftool" does. * ds/ci-commit-graph-and-midx (2018-10-19) 1 commit (merged to 'next' on 2018-10-26 at a13664e49a) + ci: add optional test variables One of our CI tests to run with "unusual/experimental/random" settings now also uses commit-graph and midx. * ds/reachable (2018-10-23) 1 commit (merged to 'next' on 2018-10-26 at 76b5fc9a46) + commit-reach: fix cast in compare_commits_by_gen() Trivial bugfix. * ds/reachable-first-parent-fix (2018-10-19) 1 commit (merged to 'next' on 2018-10-26 at 076442d512) + commit-reach: fix first-parent heuristic Correct performance regression in commit ancestry computation when generation numbers are involved. * jc/cocci-preincr (2018-10-24) 2 commits (merged to 'next' on 2018-10-26 at cbd98b44e2) + fsck: s/++i > 1/i++/ + cocci: simplify "if (++u > 1)" to "if (u++)" Code cleanup. * jc/receive-deny-current-branch-fix (2018-10-19) 1 commit (merged to 'next' on 2018-10-26 at 2975c42215) + receive: denyCurrentBranch=updateinstead should not blindly update The receive.denyCurrentBranch=updateInstead codepath kicked in even when the push should have been rejected due to other reasons, such as it does not fast-forward or the update-hook rejects it, which has been corrected. * jk/run-command-notdot (2018-10-25) 2 commits (merged to 'next' on 2018-10-26 at 9d9335b23f) + t0061: adjust to test-tool transition + run-command:
