git/git.c, branch v2.28.1

Merge branch 'ta/wait-on-aliased-commands-upon-signal' into master

2020-07-15T23:29:43Z

When an aliased command, whose output is piped to a pager by git, gets killed by a signal, the pager got into a funny state, which has been corrected (again). * ta/wait-on-aliased-commands-upon-signal: Wait for child on signal death for aliases to externals Wait for child on signal death for aliases to builtins

Wait for child on signal death for aliases to externals

2020-07-07T20:15:13Z

When we are running an alias to an external command, we want to wait for that process to exit even after receiving ^C which normally kills the git process. This is useful when the process is ignoring SIGINT (which e.g. pagers often do), and then we don't want it to be killed. Having an alias which invokes a pager is probably not common, but it can be useful e.g. if you have an alias to a git command which uses a subshell as one of the arguments (in which case you have to use an external command, not an alias to a builtin). This patch is similar to the previous commit, but the previous commit fixed this only for aliases to builtins, while this commit does the same for aliases to external commands. In addition to waiting after clean like the previous commit, this also enables cleaning the child (that was already enabled for aliases to builtins before the previous commit), because wait_after_clean relies on it. Lastly, while the previous commit fixed a regression, I don't think this has ever worked properly. Signed-off-by: Trygve Aaberge Signed-off-by: Junio C Hamano

Wait for child on signal death for aliases to builtins

2020-07-07T20:14:05Z

When you hit ^C all the processes in the tree receives it. When a git command uses a pager, git ignores this and waits until the pager quits. However, when using an alias there is an additional process in the tree which didn't ignore the signal. That caused it to exit which in turn caused the pager to exit. This fixes that for aliases to builtins. This was originally fixed in 46df6906 (execv_dashed_external: wait for child on signal death, 2017-01-06), but was broken by ee4512ed (trace2: create new combined trace facility, 2019-02-22) and then b9140840 (git: avoid calling aliased builtins via their dashed form, 2019-07-29). Signed-off-by: Trygve Aaberge Signed-off-by: Junio C Hamano

Merge branch 'bc/sha-256-part-2'

2020-07-07T05:09:13Z

SHA-256 migration work continues. * bc/sha-256-part-2: (44 commits) remote-testgit: adapt for object-format bundle: detect hash algorithm when reading refs t5300: pass --object-format to git index-pack t5704: send object-format capability with SHA-256 t5703: use object-format serve option t5702: offer an object-format capability in the test t/helper: initialize the repository for test-sha1-array remote-curl: avoid truncating refs with ls-remote t1050: pass algorithm to index-pack when outside repo builtin/index-pack: add option to specify hash algorithm remote-curl: detect algorithm for dumb HTTP by size builtin/ls-remote: initialize repository based on fetch t5500: make hash independent serve: advertise object-format capability for protocol v2 connect: parse v2 refs with correct hash algorithm connect: pass full packet reader when parsing v2 refs Documentation/technical: document object-format for protocol v2 t1302: expect repo format version 1 for SHA-256 builtin/show-index: provide options to determine hash algo t5302: modernize test formatting ...

builtin/show-index: provide options to determine hash algo

2020-05-27T17:07:07Z

show-index is capable of reading any possible index file whether or not the index is inside a repository. However, because our index files lack metadata about the hash algorithm in use, it's not possible to autodetect the algorithm that a particular index file is using. In order to allow us to read index files of any algorithm, let's set up the .git directory gently so that we default to the algorithm for the current repository, and add an --object-format option to allow users to override this setting and continue to run show-index outside of a repository altogether. Let's also document this new option so that people can find it and use it. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

Merge branch 'tb/shallow-cleanup'

2020-05-13T19:19:18Z

Code cleanup. * tb/shallow-cleanup: shallow: use struct 'shallow_lock' for additional safety shallow.h: document '{commit,rollback}_shallow_file' shallow: extract a header file for shallow-related functions commit: make 'commit_graft_pos' non-static

shallow: extract a header file for shallow-related functions

2020-04-30T21:19:13Z

There are many functions in commit.h that are more related to shallow repositories than they are to any sort of generic commit machinery. Likely this began when there were only a few shallow-related functions, and commit.h seemed a reasonable enough place to put them. But, now there are a good number of shallow-related functions, and placing them all in 'commit.h' doesn't make sense. This patch extracts a 'shallow.h', which takes all of the declarations from 'commit.h' for functions which already exist in 'shallow.c'. We will bring the remaining shallow-related functions defined in 'commit.c' in a subsequent patch. For now, move only the ones that already are implemented in 'shallow.c', and update the necessary includes. Signed-off-by: Taylor Blau Signed-off-by: Junio C Hamano

Merge branch 'js/trace2-env-vars'

2020-04-22T20:42:44Z

Trace2 enhancement to allow logging of the environment variables. * js/trace2-env-vars: trace2: teach Git to log environment variables

trace2: teach Git to log environment variables

2020-03-23T20:14:53Z

Via trace2, Git can already log interesting config parameters (see the trace2_cmd_list_config() function). However, this can grant an incomplete picture because many config parameters also allow overrides via environment variables. To allow for more complete logs, we add a new trace2_cmd_list_env_vars() function and supporting implementation, modeled after the pre-existing config param logging implementation. Signed-off-by: Josh Steadmon Acked-by: Jeff Hostetler Signed-off-by: Junio C Hamano

stash: remove the stash.useBuiltin setting

2020-03-05T20:50:28Z

Remove the stash.useBuiltin setting which was added as an escape hatch to disable the builtin version of stash first released with Git 2.22. Carrying the legacy version is a maintenance burden, and has in fact become out of date failing a test since the 2.23 release, without anyone noticing until now. So users would be getting a hint to fall back to a potentially buggy version of the tool. We used to shell out to git config to get the useBuiltin configuration to avoid changing any global state before spawning legacy-stash. However that is no longer necessary, so just use the 'git_config' function to get the setting instead. Similar to what we've done in d03ebd411c ("rebase: remove the rebase.useBuiltin setting", 2019-03-18), where we remove the corresponding setting for rebase, we leave the documentation in place, so people can refer back to it when searching for it online, and so we can refer to it in the commit message. Signed-off-by: Thomas Gummerer Signed-off-by: Junio C Hamano