Re: What's cooking in git.git (Mar 2018, #06; Fri, 30)
On Sat, Mar 31, 2018 at 08:41:11PM +0200, Ævar Arnfjörð Bjarmason wrote: > > [...] > > * jk/drop-ancient-curl (2017-08-09) 5 commits > > - http: #error on too-old curl > > - curl: remove ifdef'd code never used with curl >=7.19.4 > > - http: drop support for curl < 7.19.4 > > - http: drop support for curl < 7.16.0 > > - http: drop support for curl < 7.11.1 > > > > Some code in http.c that has bitrot is being removed. > > > > Expecting a reroll. > > This has been idle for a long time. Peff: What's left to be done for it? It wasn't clear to me we actually wanted to do this. It got some complaints, and then somebody showed up to actually fix the compilation problems with the old versions. It also isn't that much of a burden to carry the #ifdefs. The main question is whether we're doing a disservice to users, since those old setups likely aren't well tested. Even if we do proceed, I'm not sure if we'd want the top #error patch, given the reports that distros will sometimes backport features. -Peff
Re: js/runtime-prefix-windows, was Re: What's cooking in git.git (Mar 2018, #06; Fri, 30)
Am 03.04.2018 um 15:12 schrieb Johannes Schindelin: On Fri, 30 Mar 2018, Junio C Hamano wrote: * js/runtime-prefix-windows (2018-03-27) 2 commits - mingw/msvc: use the new-style RUNTIME_PREFIX helper - exec_cmd: provide a new-style RUNTIME_PREFIX helper for Windows (this branch uses dj/runtime-prefix.) The Windows port was the first that allowed Git to be installed anywhere by having its components refer to each other with relative pathnames. The recent dj/runtime-prefix topic extends the idea to other platforms, and its approach has been adopted back in the Windows port. Is this, together with the dj/runtime-prefix topic, ready for 'next'? As far as I am concerned: yes! Works in my environment, too. No objections. -- Hannes
js/runtime-prefix-windows, was Re: What's cooking in git.git (Mar 2018, #06; Fri, 30)
Hi Junio, On Fri, 30 Mar 2018, Junio C Hamano wrote: > * js/runtime-prefix-windows (2018-03-27) 2 commits > - mingw/msvc: use the new-style RUNTIME_PREFIX helper > - exec_cmd: provide a new-style RUNTIME_PREFIX helper for Windows > (this branch uses dj/runtime-prefix.) > > The Windows port was the first that allowed Git to be installed > anywhere by having its components refer to each other with relative > pathnames. The recent dj/runtime-prefix topic extends the idea to > other platforms, and its approach has been adopted back in the > Windows port. > > Is this, together with the dj/runtime-prefix topic, ready for > 'next'? As far as I am concerned: yes! Ciao, Dscho
Re: What's cooking in git.git (Mar 2018, #06; Fri, 30)
On Fri, Mar 30 2018, Junio C. Hamano wrote: > [...] > * jk/drop-ancient-curl (2017-08-09) 5 commits > - http: #error on too-old curl > - curl: remove ifdef'd code never used with curl >=7.19.4 > - http: drop support for curl < 7.19.4 > - http: drop support for curl < 7.16.0 > - http: drop support for curl < 7.11.1 > > Some code in http.c that has bitrot is being removed. > > Expecting a reroll. This has been idle for a long time. Peff: What's left to be done for it? > [...] > * dj/runtime-prefix (2018-03-25) 3 commits > - exec_cmd: RUNTIME_PREFIX on some POSIX systems > - Makefile: add Perl runtime prefix support > - Makefile: generate Perl header from template file > (this branch is used by js/runtime-prefix-windows.) > > 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. > > Is this, together with the js/runtime-prefix-windows topic, ready > for 'next'? dj/runtime-prefix look good to me (and I've been the reviewing it the most it seems), I don't see any problems with js/runtime-prefix-windows from peeking at it, but I haven't run it for obvious reasons.
Re: What's cooking in git.git (Mar 2018, #06; Fri, 30)
On Fri, Mar 30, 2018 at 10:38 PM, Junio C Hamano wrote: > * nd/repack-keep-pack (2018-03-26) 7 commits > - pack-objects: show some progress when counting kept objects > - gc --auto: exclude base pack if not enough mem to "repack -ad" > - gc: handle a corner case in gc.bigPackThreshold > - gc: add gc.bigPackThreshold config > - gc: add --keep-largest-pack option > - repack: add --keep-pack option > - t7700: have closing quote of a test at the beginning of line > > "git gc" in a large repository takes a lot of time as it considers > to repack all objects into one pack by default. The command has > been taught to pretend as if the largest existing packfile is > marked with ".keep" so that it is left untouched while objects in > other packs and loose ones are repacked. > > Reroll exists, but it seems to be still slushy. > cf. <20180316192745.19557-1-pclo...@gmail.com> The next one v4 [1] should be less slushy. [1] https://public-inbox.org/git/20180324072507.21059-1-pclo...@gmail.com/#t -- Duy
Re: What's cooking in git.git (Mar 2018, #06; Fri, 30)
On 3/30/2018 4:38 PM, Junio C Hamano wrote: * jh/json-writer (2018-03-28) 1 commit - json_writer: new routines to create data in JSON format Is this ready for 'next'? Yes, I believe it is. This has the V6 fixup for the HEREDOC with leading whitespace, so I think we're good. Thanks Jeff
Re: What's cooking in git.git (Mar 2018, #06; Fri, 30)
Junio C Hamano writes:
> --
> [Graduated to "master"]
>
> * jh/partial-clone (2018-03-25) 1 commit
> (merged to 'next' on 2018-03-28 at 2a0a7aef8e)
> + unpack-trees: release oid_array after use in check_updates()
>
> Hotfix.
Not listed in the above, but this round also merges the hotfix
c7620bd0 ("upload-pack: disable object filtering when disabled by
config", 2018-03-28) from Jonathan Nieder that makes sure that
"uploadpack.allowfilter" does disable the feature even when the
client makes an unsolicited request to trigger the "filter" feature.
It is not (yet) clear how I screwed up this report; sorry about
that.
Re: What's cooking in git.git (Mar 2018, #06; Fri, 30)
On 03/30, Junio C Hamano wrote: > * tg/worktree-add-existing-branch (2018-03-27) 6 commits > - t2025: rename now outdated branch name > - worktree: teach "add" to check out existing branches > - worktree: factor out dwim_branch function > - worktree: remove force_new_branch from struct add_opts > - worktree: be clearer when "add" dwim-ery kicks in > - worktree: improve message when creating a new worktree > > "git worktree add" learned to check out an existing branch. > > Is this ready for 'next'? Not quite yet. Eric spotted some UI deficiencies which I'm currently trying to address. I hope to re-roll this in a few days with those deficiencies fixed.
What's cooking in git.git (Mar 2018, #06; Fri, 30)
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.
Git 2.17 final is expected to be tagged by early next week.
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"]
* jh/partial-clone (2018-03-25) 1 commit
(merged to 'next' on 2018-03-28 at 2a0a7aef8e)
+ unpack-trees: release oid_array after use in check_updates()
Hotfix.
--
[New Topics]
* rs/status-with-removed-submodule (2018-03-28) 1 commit
(merged to 'next' on 2018-03-30 at 8a7b618bc1)
+ submodule: check for NULL return of get_submodule_ref_store()
"git submodule status" misbehaved on a submodule that has been
removed from the working tree.
Will cook in 'next'.
* lv/tls-1.3 (2018-03-29) 1 commit
(merged to 'next' on 2018-03-30 at 4f13731408)
+ http: allow use of TLS 1.3
When built with more recent cURL, GIT_SSL_VERSION can now specify
"tlsv1.3" as its value.
Will cook in 'next'.
* nd/warn-more-for-devs (2018-03-29) 3 commits
- Makefile: add EAGER_DEVELOPER mode
- Makefile: detect compiler and enable more warnings in DEVELOPER=1
- connect.c: mark die_initial_contact() NORETURN
The build procedure "make DEVELOPER=YesPlease" learned to enable a
bit more warning options depending on the compiler used to help
developers more. There also is "make EAGER_DEVELOPER=YesPlease"
available now, for those who want to help fixing warnings we
usually ignore.
Will merge to 'next'.
* sb/submodule-move-nested (2018-03-29) 6 commits
- submodule: fixup nested submodules after moving the submodule
- submodule-config: remove submodule_from_cache
- submodule-config: add repository argument to submodule_from_{name, path}
- submodule-config: allow submodule_free to handle arbitrary repositories
- grep: remove "repo" arg from non-supporting funcs
- submodule.h: drop declaration of connect_work_tree_and_git_dir
(this branch uses nd/remove-ignore-env-field and sb/object-store; is tangled
with sb/packfiles-in-repository.)
Moving a submodule that itself has submodule in it with "git mv"
forgot to make necessary adjustment to the nested sub-submodules;
now the codepath learned to recurse into the submodules.
* tb/config-type (2018-03-29) 1 commit
- builtin/config.c: prefer `--type=bool` over `--bool`, etc.
(this branch is used by tb/config-default.)
The "git config" command uses separate options e.g. "--int",
"--bool", etc. to specify what type the caller wants the value to
be interpreted as. A new "--type=" option has been
introduced, which would make it cleaner to define new types.
Will merge to 'next'.
* tb/config-default (2018-03-29) 3 commits
- builtin/config: introduce `color` type specifier
- config.c: introduce 'git_config_color' to parse ANSI colors
- builtin/config: introduce `--default`
(this branch uses tb/config-type.)
"git config --get" learned the "--default" option, to help the
calling script. Building on top of the tb/config-type topic, the
"git config" learns "--type=color" type. Taken together, you can
do things like "git config --get foo.color --default blue" and get
the ANSI color sequence for the color given to foo.color variable,
or "blue" if the variable does not exist.
* eb/cred-helper-ignore-sigpipe (2018-03-29) 1 commit
(merged to 'next' on 2018-03-30 at c48e98c1b1)
+ credential: ignore SIGPIPE when writing to credential helpers
When credential helper exits very quickly without reading its
input, it used to cause Git to die with SIGPIPE, which has been
fixed.
Will cook in 'next'.
* jk/flockfile-stdio (2018-03-30) 1 commit
- config: move flockfile() closer to unlocked functions
* jk/relative-directory-fix (2018-03-30) 5 commits
- refs: use chdir_notify to update cached relative paths
- set_work_tree: use chdir_notify
- add chdir-notify API
- trace.c: export trace_setup_key
- set_git_dir: die when setenv() fails
--
[Stalled]
* sb/blame-color (2018-02-13) 3 commits
- builtin/blame: highlight recently changed lines
- builtin/blame: add option to color metadata fields separately
- builtin/blame: dim uninteresting metadata
Expecting a reroll.
cf. https://public-inbox.org/git/20171110011002.10179-1-sbel...@google.com/#t
error messages are funny, can segfault, ...
* av/fsmonitor-updates (2018-01-04) 6 commits
- fsmonitor: use fsmonitor data in `git diff`
- fsmonitor: remove debugging lines from t/t7519-status-fsmonitor.sh
- fsmonitor: make output of test-dump-fsmonitor more concise
- fsmonitor: update helper tool, now that flags are filled later
- fsmonitor: sto
