What's cooking in git.git (Mar 2018, #02; Tue, 6)
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. I haven't seen enough reviews (nor I had chance to sufficiently review them myself) to comfortably decide what to do with them on a handful of new topics that appeared in the past week or two, so the ones in the new topics section may not have any description yet in this issue. 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"] * ab/fetch-prune (2018-02-09) 17 commits (merged to 'next' on 2018-02-27 at eafb648dd9) + fetch: make the --prune-tags work with + fetch: add a --prune-tags option and fetch.pruneTags config + fetch tests: add scaffolding for the new fetch.pruneTags + git-fetch & config doc: link to the new PRUNING section + git remote doc: correct dangerous lies about what prune does + git fetch doc: add a new section to explain the ins & outs of pruning + fetch tests: fetch as well as fetch [] + fetch tests: expand case/esac for later change + fetch tests: double quote a variable for interpolation + fetch tests: test --prune and refspec interaction + fetch tests: add a tag to be deleted to the pruning tests + fetch tests: re-arrange arguments for future readability + fetch tests: refactor in preparation for testing tag pruning + remote: add a macro for "refs/tags/*:refs/tags/*" + fetch: stop accessing "remote" variable indirectly + fetch: trivially refactor assignment to ref_nr + fetch: don't redundantly NULL something calloc() gave us "git fetch --prune-tags" may be used as a handy short-hand for getting rid of stale tags that are locally held. * ab/simplify-perl-makefile (2018-02-15) 1 commit (merged to 'next' on 2018-02-27 at b0d68a2013) + Makefile: generate Git(3pm) as dependency of the 'doc' and 'man' targets Hotfix for a topic already in 'master'. * bw/c-plus-plus (2018-02-22) 37 commits (merged to 'next' on 2018-02-27 at daf85c03de) + replace: rename 'new' variables + trailer: rename 'template' variables + tempfile: rename 'template' variables + wrapper: rename 'template' variables + environment: rename 'namespace' variables + diff: rename 'template' variables + environment: rename 'template' variables + init-db: rename 'template' variables + unpack-trees: rename 'new' variables + trailer: rename 'new' variables + submodule: rename 'new' variables + split-index: rename 'new' variables + remote: rename 'new' variables + ref-filter: rename 'new' variables + read-cache: rename 'new' variables + line-log: rename 'new' variables + imap-send: rename 'new' variables + http: rename 'new' variables + entry: rename 'new' variables + diffcore-delta: rename 'new' variables + diff: rename 'new' variables + diff-lib: rename 'new' variable + commit: rename 'new' variables + combine-diff: rename 'new' variables + remote: rename 'new' variables + reflog: rename 'new' variables + pack-redundant: rename 'new' variables + help: rename 'new' variables + checkout: rename 'new' variables + apply: rename 'new' variables + apply: rename 'try' variables + diff: rename 'this' variables + rev-parse: rename 'this' variable + pack-objects: rename 'this' variables + blame: rename 'this' variables + object: rename function 'typename' to 'type_name' + object_info: change member name from 'typename' to 'type_name' We now avoid using identifiers that clash with C++ keywords. Even though it is not a goal to compile Git with C++ compilers, changes like this help use of code analysis tools that targets C++ on our codebase. * bw/doc-submodule-recurse-config-with-clone (2018-02-21) 1 commit (merged to 'next' on 2018-02-27 at 5b12841508) + submodule: indicate that 'submodule.recurse' doesn't apply to clone Doc update. * bw/perl-timegm-timelocal-fix (2018-02-23) 1 commit (merged to 'next' on 2018-02-27 at 565a3141ce) + perl: call timegm and timelocal with 4-digit year Y2k20 fix ;-) for our perl scripts. * jc/allow-ff-merging-kept-tags (2018-02-16) 1 commit (merged to 'next' on 2018-02-27 at 8b03610d2b) + merge: allow fast-forward when merging a tracked tag Since Git 1.7.9, "git merge" defaulted to --no-ff (i.e. even when the side branch being merged is a descendant of the current commit, create a merge commit instead of fast-forwarding) when merging a tag object. This was appropriate default for integrators who pull signed tags from their downstream contributors, but caused an unnecessary merges when used by downstream contributors who habitually "catch up" their topic branches with tagged releases from the upstream. Update "git merge" to default to --no-ff only when merging a
Re: What's cooking in git.git (Mar 2018, #02; Tue, 6)
Hi Dan, On Tue, 6 Mar 2018, Junio C Hamano wrote: > * dj/runtime-prefix (2017-12-05) 4 commits > . exec_cmd: RUNTIME_PREFIX on some POSIX systems > . Makefile: add Perl runtime prefix support > . Makefile: add support for "perllibdir" > . Makefile: generate Perl header from template file > > A build-time option has been added to allow Git to be told to refer > to its associated files relative to the main binary, in the same > way that has been possible on Windows for quite some time, for > Linux, BSDs and Darwin. > > Perhaps it is about time to reboot the effort? You probably missed this in the huge "What's cooking" mail. Are you game? Ciao, Johannes
Re: What's cooking in git.git (Mar 2018, #02; Tue, 6)
On Wed, Mar 07 2018, Johannes Schindelin jotted: > Hi Dan, > > On Tue, 6 Mar 2018, Junio C Hamano wrote: > >> * dj/runtime-prefix (2017-12-05) 4 commits >> . exec_cmd: RUNTIME_PREFIX on some POSIX systems >> . Makefile: add Perl runtime prefix support >> . Makefile: add support for "perllibdir" >> . Makefile: generate Perl header from template file >> >> A build-time option has been added to allow Git to be told to refer >> to its associated files relative to the main binary, in the same >> way that has been possible on Windows for quite some time, for >> Linux, BSDs and Darwin. >> >> Perhaps it is about time to reboot the effort? > > You probably missed this in the huge "What's cooking" mail. Are you game? It would be great to have this rebooted now that my perl cleanup efforts have un-blocked this. Will be happy to help review & test the next iteration.
Re: What's cooking in git.git (Mar 2018, #02; Tue, 6)
> It would be great to have this rebooted now that my perl cleanup efforts > have un-blocked this. Will be happy to help review & test the next > iteration. Yes, I was just thinking the same thing. I wanted to make sure the Perl changes had landed, and I'm pleased to see that they have. I should have time in the next few days to rebase and put up a new version of the patch series. I'll keep you in the loop, and thanks for pinging!
Re: What's cooking in git.git (Mar 2018, #02; Tue, 6)
On 7 March 2018 at 00:34, Junio C Hamano wrote: > * ma/config-page-only-in-list-mode (2018-02-21) 3 commits > - config: change default of `pager.config` to "on" > - config: respect `pager.config` in list/get-mode only > - t7006: add tests for how git config paginates > > In a way similar to how "git tag" learned to honor the pager > setting only in the list mode, "git config" learned to ignore the > pager setting when it is used for setting values (i.e. when the > purpose of the operation is not to "show"). > > Is this ready for 'next'? I am not aware of any open questions or issues. You thought out loud about how the series was structured, in particular about introducing a successful test, then redefining it, as opposed to introducing it as a failing test, then making it succeed. I hope I managed to motivate my choice better in v2 (which is what you have picked up). Duy wondered if it was sane to use a pager when we know that we are "--get"-ing at most one config item. In v2, I addressed this by turning on paging for a more careful selection of "--get"-ters. Martin
Re: What's cooking in git.git (Mar 2018, #02; Tue, 6)
On Fri, Mar 9, 2018 at 1:15 PM, Martin Ågren wrote: > On 7 March 2018 at 00:34, Junio C Hamano wrote: > >> * ma/config-page-only-in-list-mode (2018-02-21) 3 commits >> - config: change default of `pager.config` to "on" >> - config: respect `pager.config` in list/get-mode only >> - t7006: add tests for how git config paginates >> >> In a way similar to how "git tag" learned to honor the pager >> setting only in the list mode, "git config" learned to ignore the >> pager setting when it is used for setting values (i.e. when the >> purpose of the operation is not to "show"). >> >> Is this ready for 'next'? > > I am not aware of any open questions or issues. You thought out loud > about how the series was structured, in particular about introducing a > successful test, then redefining it, as opposed to introducing it as a > failing test, then making it succeed. I hope I managed to motivate my > choice better in v2 (which is what you have picked up). > > Duy wondered if it was sane to use a pager when we know that we are > "--get"-ing at most one config item. In v2, I addressed this by turning > on paging for a more careful selection of "--get"-ters. Yeah I got busy with stuff and didn't look at it. I've just checked what's in 'pu'. Looks good to me. -- Duy
Re: What's cooking in git.git (Mar 2018, #02; Tue, 6)
Martin Ågren writes: >> Is this ready for 'next'? > > I am not aware of any open questions or issues. You thought out loud > about how the series was structured, in particular about introducing a > successful test, then redefining it, as opposed to introducing it as a > failing test, then making it succeed. I hope I managed to motivate my > choice better in v2 (which is what you have picked up). > > Duy wondered if it was sane to use a pager when we know that we are > "--get"-ing at most one config item. In v2, I addressed this by turning > on paging for a more careful selection of "--get"-ters. Yeah, I am aware of these exchanges, and they are resolved nicely, I think. I was mostly asking if other people have concerns we haven't thought of yet. Let's merge this to 'next', then. Thanks.