summaryrefslogtreecommitdiff
path: root/contrib
AgeCommit message (Collapse)AuthorFilesLines
2021-04-28subtree: give the docs a once-overLibravatar Luke Shumaker3-93/+87
Just went through the docs looking for anything inaccurate or that can be improved. In the '-h' text, in the man page synopsis, and in the man page description: Normalize the ordering of the list of sub-commands: 'add', 'merge', 'split', 'pull', 'push'. This allows us to kinda separate the lower-level add/merge/split from the higher-level pull/push. '-h' text: - correction: Indicate that split's arg is optional. - clarity: Emphasize that 'pull' takes the 'add'/'merge' flags. man page: - correction: State that all subcommands take options (it seemed to indicate that only 'split' takes any options other than '-P'). - correction: 'split' only guarantees that the results are identical if the flags are identical. - correction: The flag is named '--ignore-joins', not '--ignore-join'. - completeness: Clarify that 'push' always operates on HEAD, and that 'split' operates on HEAD if no local commit is given. - clarity: In the description, when listing commands, repeat what their arguments are. This way the reader doesn't need to flip back and forth between the command description and the synopsis and the full description to understand what's being said. - clarity: In the <variables> used to give command arguments, give slightly longer, descriptive names. Like <local-commit> instead of just <commit>. - clarity: Emphasize that 'pull' takes the 'add'/'merge' flags. - style: In the synopsis, list options before the subcommand. This makes things line up and be much more readable when shown non-monospace (such as in `make html`), and also more closely matches other man pages (like `git-submodule.txt`). - style: Use the correct syntax for indicating the options ([<options>] instead of [OPTIONS]). - style: In the synopsis, separate 'pull' and 'push' from the other lower-level commands. I think this helps readability. - style: Code-quote things in prose that seem like they should be code-quoted, like '.gitmodules', flags, or full commands. - style: Minor wording improvements, like more consistent mood (many of the command descriptions start in the imperative mood and switch to the indicative mode by the end). That sort of thing. - style: Capitalize "ID". - style: Remove the "This option is only valid for XXX command" remarks from each option, and instead rely on the section headings. - style: Since that line is getting edited anyway, switch "behaviour" to American "behavior". - style: Trim trailing whitespace. `todo`: - style: Trim trailing whitespace. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: have $indent actually affect indentationLibravatar Luke Shumaker1-18/+24
Currently, the $indent variable is just used to track how deeply we're nested, and the debug log is indented by things like debug " foo" That is: The indentation-level is hard-coded. It used to be that the code couldn't recurse, so the indentation level could be known statically, so it made sense to just hard-code it in the output. However, since 315a84f9aa ("subtree: use commits before rejoins for splits", 2018-09-28), it can now recurse, and the debug log is misleading. So fix that. Indent according to $indent. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: don't let debug and progress output clashLibravatar Luke Shumaker1-1/+21
Currently, debug output (triggered by passing '-d') and progress output stomp on each other. The debug output is just streamed as lines to stderr, and the progress output is sent to stderr as '%s\r'. When writing to a file, it is awkward to read and difficult to distinguish between the debug output and a progress line. When writing to a terminal the debug lines hide progress lines. So, when '-d' has been passed, spit out progress as 'progress: %s\n', instead of as '%s\r', so that it can be detected, and so that the debug lines don't overwrite the progress when written to a terminal. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: add comments and sanity checksLibravatar Luke Shumaker1-3/+61
For each function in subtree, add a usage comment saying what the arguments are, and add an `assert` checking the number of arguments. In figuring out each thing's arguments in order to write those comments and assertions, it turns out that find_existing_splits is written as if it takes multiple 'revs', but it is in fact only ever passed a single 'rev': unrevs="$(find_existing_splits "$dir" "$rev")" || exit $? So go ahead and codify that by documenting and asserting that it takes exactly two arguments, one dir and one rev. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: remove duplicate checkLibravatar Luke Shumaker1-4/+0
`cmd_add` starts with a check that the directory doesn't yet exist. However, the `main` function performs the exact same check before calling `cmd_add`. So remove the check from `cmd_add`. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: parse revs in individual cmd_ functionsLibravatar Luke Shumaker1-38/+24
The main argument parser goes ahead and tries to parse revs to make things simpler for the sub-command implementations. But, it includes enough special cases for different sub-commands. And it's difficult having having to think about "is this info coming from an argument, or a global variable?". So the main argument parser's effort to make things "simpler" ends up just making it more confusing and complicated. Begone with the 'revs' global variable; parse 'rev=$(...)' as needed in individual 'cmd_*' functions. Begone with the 'default' global variable. Its would-be value is knowable just from which function we're in. Begone with the 'ensure_single_rev' function. Its functionality can be achieved by passing '--verify' to 'git rev-parse'. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: use "^{commit}" instead of "^0"Libravatar Luke Shumaker1-2/+2
They are synonyms. Both are used in the file. ^{commit} is clearer, so "standardize" on that. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: don't fuss with PATHLibravatar Luke Shumaker1-2/+16
Scripts needing to fuss with with adding $(git --exec-prefix) PATH before loading git-sh-setup is a thing of the past. As far as I can tell, it's been a thing of the past since since Git v1.2.0 (2006-02-12), or more specifically, since 77cb17e940 (Exec git programs without using PATH, 2006-01-10). However, it stuck around in contrib scripts and in third-party scripts for long enough that it wasn't unusual to see. Originally `git subtree` didn't fuss with PATH, but when people (including the original subtree author) had problems, because it was a common thing to see, it seemed that having subtree fuss with PATH was a reasonable solution. Here is an abridged history of fussing with PATH in subtree: 2987e6add3 (Add explicit path of git installation by 'git --exec-path', Gianluca Pacchiella, 2009-08-20) As pointed out by documentation, the correct use of 'git-sh-setup' is using $(git --exec-path) to avoid problems with not standard installations. -. git-sh-setup +. $(git --exec-path)/git-sh-setup 33aaa697a2 (Improve patch to use git --exec-path: add to PATH instead, Avery Pennarun, 2009-08-26) If you (like me) are using a modified git straight out of its source directory (ie. without installing), then --exec-path isn't actually correct. Add it to the PATH instead, so if it is correct, it'll work, but if it's not, we fall back to the previous behaviour. -. $(git --exec-path)/git-sh-setup +PATH=$(git --exec-path):$PATH +. git-sh-setup 9c632ea29c ((Hopefully) fix PATH setting for msysgit, Avery Pennarun, 2010-06-24) Reported by Evan Shaw. The problem is that $(git --exec-path) includes a 'git' binary which is incompatible with the one in /usr/bin; if you run it, it gives you an error about libiconv2.dll. +OPATH=$PATH PATH=$(git --exec-path):$PATH . git-sh-setup +PATH=$OPATH # apparently needed for some versions of msysgit df2302d774 (Another fix for PATH and msysgit, Avery Pennarun, 2010-06-24) Evan Shaw tells me the previous fix didn't work. Let's use this one instead, which he says does work. This fix is kind of wrong because it will run the "correct" git-sh-setup *after* the one in /usr/bin, if there is one, which could be weird if you have multiple versions of git installed. But it works on my Linux and his msysgit, so it's obviously better than what we had before. -OPATH=$PATH -PATH=$(git --exec-path):$PATH +PATH=$PATH:$(git --exec-path) . git-sh-setup -PATH=$OPATH # apparently needed for some versions of msysgit First of all, I disagree with Gianluca's reading of the documentation: - I haven't gone back to read what the documentation said in 2009, but in my reading of the 2021 documentation is that it includes "$(git --exec-path)/" in the synopsis for illustrative purposes, not to say it's the proper way. - After being executed by `git`, the git exec path should be the very first entry in PATH, so it shouldn't matter. - None of the scripts that are part of git do it that way. But secondly, the root reason for fussing with PATH seems to be that Avery didn't know that he needs to set GIT_EXEC_PATH if he's going to use git from the source directory without installing. And finally, Evan's issue is clearly just a bug in msysgit. I assume that msysgit has since fixed the issue, and also msysgit has been deprecated for 6 years now, so let's drop the workaround for it. So, remove the line fussing with PATH. However, since subtree *is* in 'contrib/' and it might get installed in funny ways by users after-the-fact, add a sanity check to the top of the script, checking that it is installed correctly. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: use "$*" instead of "$@" as appropriateLibravatar Luke Shumaker1-3/+3
"$*" is for when you want to concatenate the args together, whitespace-separated; and "$@" is for when you want them to be separate strings. There are several places in subtree that erroneously use $@ when concatenating args together into an error message. For instance, if the args are argv[1]="dead" and argv[2]="beef", then the line die "You must provide exactly one revision. Got: '$@'" surely intends to call 'die' with the argument argv[1]="You must provide exactly one revision. Got: 'dead beef'" however, because the line used $@ instead of $*, it will actually call 'die' with the arguments argv[1]="You must provide exactly one revision. Got: 'dead" argv[2]="beef'" This isn't a big deal, because 'die' concatenates its arguments together anyway (using "$*"). But that doesn't change the fact that it was a mistake to use $@ instead of $*, even though in the end $@ still ended up doing the right thing. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: use more explicit variable names for cmdline argsLibravatar Luke Shumaker1-66/+66
Make it painfully obvious when reading the code which variables are direct parsings of command line arguments. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: use git-sh-setup's `say`Libravatar Luke Shumaker1-15/+7
subtree currently defines its own `say` implementation, rather than using git-sh-setups's implementation. Change that, don't re-invent the wheel. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: use `git merge-base --is-ancestor`Libravatar Luke Shumaker1-15/+1
Instead of writing a slow `rev_is_descendant_of_branch $a $b` function in shell, just use the fast `git merge-base --is-ancestor $b $a`. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: drop support for git < 1.7Libravatar Luke Shumaker1-15/+4
Suport for Git versions older than 1.7.0 (older than February 2010) was nice to have when git-subtree lived out-of-tree. But now that it lives in git.git, it's not necessary to keep around. While it's technically in contrib, with the standard 'git' packages for common systems (including Arch Linux and macOS) including git-subtree, it seems vanishingly likely to me that people are separately installing git-subtree from git.git alongside an older 'git' install (although it also seems vanishingly likely that people are still using >11 year old git installs). Not that there's much reason to remove it either, it's not much code, and none of my changes depend on a newer git (to my knowledge, anyway; I'm not actually testing against older git). I just figure it's an easy piece of fat to trim, in the journey to making the whole thing easier to hack on. "Ignore space change" is probably helpful when viewing this diff. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: more consistent error propagationLibravatar Luke Shumaker1-14/+14
Ensure that every $(subshell) that calls a function (as opposed to an external executable) is followed by `|| exit $?`. Similarly, ensure that every `cmd | while read; do ... done` loop is followed by `|| exit $?`. Both of those constructs mean that it can miss `die` calls, and keep running when it shouldn't. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: don't have loose code outside of a functionLibravatar Luke Shumaker1-120/+125
Shove all of the loose code inside of a main() function. This comes down to personal preference more than anything else. A preference that I've developed over years of maintaining large Bash scripts, but still a mere personal preference. In this specific case, it's also moving the `set -- -h`, the `git rev-parse --parseopt`, and the `. git-sh-setup` to be closer to all the rest of the argument parsing, which is a readability win on its own, IMO. "Ignore space change" is probably helpful when viewing this diff. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: t7900: add porcelain tests for 'pull' and 'push'Libravatar Luke Shumaker1-0/+127
The 'pull' and 'push' subcommands deserve their own sections in the tests. Add some basic tests for them. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: t7900: add a test for the -h flagLibravatar Luke Shumaker1-0/+7
It's a dumb test, but it's surprisingly easy to break. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: t7900: rename last_commit_message to last_commit_subjectLibravatar Luke Shumaker1-13/+13
t7900-subtree.sh defines a helper function named last_commit_message. However, it only returns the subject line of the commit message, not the entire commit message. So rename it, to make the name less confusing. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: t7900: fix 'verify one file change per commit'Libravatar Luke Shumaker1-40/+6
As far as I can tell, this test isn't actually testing anything, because someone forgot to tack on `--name-only` to `git log`. This seems to have been the case since the test was first written, back in fa16ab36ad ("test.sh: make sure no commit changes more than one file at a time.", 2009-04-26), unless `git log` used to do that by default and didn't need the flag back then? Convincing myself that it's not actually testing anything was tricky, the code is a little hard to reason about. It can be made a lot simpler if instead of trying to parse all of the info from a single `git log`, we're OK calling `git log` from inside of a loop. And it's my opinion that tests are not the place for clever optimized code. So, fix and simplify the test, so that it's actually testing something and is simpler to reason about. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: t7900: delete some dead codeLibravatar Luke Shumaker1-11/+1
Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: t7900: use 'test' for string equalityLibravatar Luke Shumaker1-36/+24
t7900-subtree.sh defines its own `check_equal A B` function, instead of just using `test A = B` like all of the other tests. Don't be special, get rid of `check_equal` in favor of `test`. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: t7900: comment subtree_test_create_repoLibravatar Luke Shumaker1-6/+8
It's unclear what the purpose of t7900-subtree.sh's `subtree_test_create_repo` helper function is. It wraps test-lib.sh's, `test_create_repo` but follows that up by setting log.date=relative. Why does it set log.date=relative? My first guess was that at one point the tests required that, but no longer do, and that the function is now vestigial. I even wrote a patch to get rid of it and was moments away from `git send-email`ing it. However, by chance when looking for something else in the history, I discovered the true reason, from e7aac44ed2 (contrib/subtree: ignore log.date configuration, 2015-07-21). It's testing that setting log.date=relative doesn't break `git subtree`, as at one point in the past that did break `git subtree`. So, add a comment about this, to avoid future such confusion. And while at it, go ahead and (1) touch up the function to avoid a pointless subshell and (2) update the one test that didn't use it. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: t7900: use consistent formattingLibravatar Luke Shumaker1-35/+35
The formatting in t7900-subtree.sh isn't even consistent throughout the file. Fix that; make it consistent throughout the file. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: t7900: use test-lib.sh's test_countLibravatar Luke Shumaker1-336/+300
Use test-lib.sh's `test_count`, instead instead of having t7900-subtree.sh do its own book-keeping with `subtree_test_count` that has to be explicitly incremented by calling `next_test`. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: t7900: update for having the default branch name be 'main'Libravatar Luke Shumaker1-58/+59
Most of the tests had been converted to support `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main`, but `contrib/subtree/t/` hadn't. Convert it. Most of the mentions of 'master' can just be replaced with 'HEAD'. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-15Merge branch 'ab/complete-cherry-pick-head'Libravatar Junio C Hamano1-1/+1
The command line completion (in contrib/) has learned that CHERRY_PICK_HEAD is a possible pseudo-ref. * ab/complete-cherry-pick-head: bash completion: complete CHERRY_PICK_HEAD
2021-04-13Merge branch 'vs/completion-with-set-u'Libravatar Junio C Hamano1-3/+3
The command-line completion script (in contrib/) had a couple of references that would have given a warning under the "-u" (nounset) option. * vs/completion-with-set-u: completion: audit and guard $GIT_* against unset use
2021-04-08completion: audit and guard $GIT_* against unset useLibravatar Ville Skyttä1-3/+3
$GIT_COMPLETION_SHOW_ALL and $GIT_TESTING_ALL_COMMAND_LIST were used without guarding against them being unset, causing errors in nounset (set -u) mode. No other nounset-unsafe $GIT_* usages were found. While at it, remove a superfluous (duplicate) unset guard from $GIT_DIR in __git_find_repo_path. Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-07Merge branch 'js/cmake-vsbuild'Libravatar Junio C Hamano1-7/+19
CMake update for vsbuild. * js/cmake-vsbuild: cmake(install): include vcpkg dlls cmake: add a preparatory work-around to accommodate `vcpkg` cmake(install): fix double .exe suffixes cmake: support SKIP_DASHED_BUILT_INS
2021-04-07bash completion: complete CHERRY_PICK_HEADLibravatar Ævar Arnfjörð Bjarmason1-1/+1
When e.g. in a failed cherry pick we did not recognize CHERRY_PICK_HEAD as we do e.g. REBASE_HEAD in a failed rebase let's rectify that. When REBASE_HEAD was added in fbd7a232370 (rebase: introduce and use pseudo-ref REBASE_HEAD, 2018-02-11) a completion was added for it, but no corresponding completion existed for CHERRY_PICK_HEAD added in d7e5c0cbfb0 (Introduce CHERRY_PICK_HEAD, 2011-02-19). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-02Merge branch 'jh/simple-ipc'Libravatar Junio C Hamano1-1/+7
A simple IPC interface gets introduced to build services like fsmonitor on top. * jh/simple-ipc: t0052: add simple-ipc tests and t/helper/test-simple-ipc tool simple-ipc: add Unix domain socket implementation unix-stream-server: create unix domain socket under lock unix-socket: disallow chdir() when creating unix domain sockets unix-socket: add backlog size option to unix_stream_listen() unix-socket: eliminate static unix_stream_socket() helper function simple-ipc: add win32 implementation simple-ipc: design documentation for new IPC mechanism pkt-line: add options argument to read_packetized_to_strbuf() pkt-line: add PACKET_READ_GENTLE_ON_READ_ERROR option pkt-line: do not issue flush packets in write_packetized_*() pkt-line: eliminate the need for static buffer in packet_write_gently()
2021-03-29cmake(install): include vcpkg dllsLibravatar Dennis Ameling1-0/+4
Our CMake configuration generates not only build definitions, but also install definitions: After building Git using `msbuild git.sln`, the built artifacts can be installed via `msbuild INSTALL.vcxproj`. To specify _where_ the files should be installed, the `-DCMAKE_INSTALL_PREFIX=<path>` option can be used when running CMake. However, this process would really only install the files that were just built. On Windows, we need more than that: We also need the `.dll` files of the dependencies (such as libcurl). The `vcpkg` ecosystem, which we use to obtain those dependencies, can be asked to install said `.dll` files really easily, so let's do that. This requires more than just the built `vcpkg` artifacts in the CI build definition; We now clone the `vcpkg` repository so that the relevant CMake scripts are available, in particular the ones related to defining the toolchain. Signed-off-by: Dennis Ameling <dennis@dennisameling.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-29cmake: add a preparatory work-around to accommodate `vcpkg`Libravatar Johannes Schindelin1-5/+9
We are about to add support for installing the `.dll` files of Git's dependencies (such as libcurl) in the CMake configuration. The `vcpkg` ecosystem from which we get said dependencies makes that relatively easy: simply turn on `X_VCPKG_APPLOCAL_DEPS_INSTALL`. However, current `vcpkg` introduces a limitation if one does that: While it is totally cool with CMake to specify multiple targets within one invocation of `install(TARGETS ...) (at least according to https://cmake.org/cmake/help/latest/command/install.html#command:install), `vcpkg`'s parser insists on a single target per `install(TARGETS ...)` invocation. Well, that's easily accomplished: Let's feed the targets individually to the `install(TARGETS ...)` function in a `foreach()` look. This also has the advantage that we do not have to manually cull off the two entries from the `${PROGRAMS_BUILT}` array before scheduling the remainder to be installed into `libexec/git-core`. Instead, we iterate through the array and decide for each entry where it wants to go. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-27cmake(install): fix double .exe suffixesLibravatar Dennis Ameling1-2/+2
By mistake, the `.exe` extension is appended _twice_ when installing the dashed executables into `libexec/git-core/` on Windows (the extension is already appended when adding items to the `git_links` list in the `#Creating hardlinks` section). Signed-off-by: Dennis Ameling <dennis@dennisameling.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-27cmake: support SKIP_DASHED_BUILT_INSLibravatar Johannes Schindelin1-0/+4
Just like the Makefile-based build learned to skip hard-linking the dashed built-ins in 179227d6e21 (Optionally skip linking/copying the built-ins, 2020-09-21), this patch teaches the CMake-based build the same trick. Note: In contrast to the Makefile-based process, the built-ins would only be linked during installation, not already when Git is built. Therefore, the CMake-based build that we use in our CI builds _already_ does not link those built-ins (because the files are not installed anywhere, they are used to run the test suite in-place). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-22Merge branch 'dl/stash-show-untracked'Libravatar Junio C Hamano1-1/+1
"git stash show" learned to optionally show untracked part of the stash. * dl/stash-show-untracked: stash show: learn stash.showIncludeUntracked stash show: teach --include-untracked and --only-untracked
2021-03-22simple-ipc: add Unix domain socket implementationLibravatar Jeff Hostetler1-0/+2
Create Unix domain socket based implementation of "simple-ipc". A set of `ipc_client` routines implement a client library to connect to an `ipc_server` over a Unix domain socket, send a simple request, and receive a single response. Clients use blocking IO on the socket. A set of `ipc_server` routines implement a thread pool to listen for and concurrently service client connections. The server creates a new Unix domain socket at a known location. If a socket already exists with that name, the server tries to determine if another server is already listening on the socket or if the socket is dead. If socket is busy, the server exits with an error rather than stealing the socket. If the socket is dead, the server creates a new one and starts up. If while running, the server detects that its socket has been stolen by another server, it automatically exits. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-19Merge branch 'rs/xcalloc-takes-nelem-first'Libravatar Junio C Hamano1-0/+10
Code cleanup. * rs/xcalloc-takes-nelem-first: fix xcalloc() argument order
2021-03-15cocci: allow xcalloc(1, size)Libravatar Junio C Hamano1-1/+1
Allocating a pre-cleared single element is quite common and it is misleading to use CALLOC_ARRAY(); these allocations that would be affected without this change are not allocating an array. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-15unix-stream-server: create unix domain socket under lockLibravatar Jeff Hostetler1-1/+1
Create a wrapper class for `unix_stream_listen()` that uses a ".lock" lockfile to create the unix domain socket in a race-free manner. Unix domain sockets have a fundamental problem on Unix systems because they persist in the filesystem until they are deleted. This is independent of whether a server is actually listening for connections. Well-behaved servers are expected to delete the socket when they shutdown. A new server cannot easily tell if a found socket is attached to an active server or is leftover cruft from a dead server. The traditional solution used by `unix_stream_listen()` is to force delete the socket pathname and then create a new socket. This solves the latter (cruft) problem, but in the case of the former, it orphans the existing server (by stealing the pathname associated with the socket it is listening on). We cannot directly use a .lock lockfile to create the socket because the socket is created by `bind(2)` rather than the `open(2)` mechanism used by `tempfile.c`. As an alternative, we hold a plain lockfile ("<path>.lock") as a mutual exclusion device. Under the lock, we test if an existing socket ("<path>") is has an active server. If not, we create a new socket and begin listening. Then we use "rollback" to delete the lockfile in all cases. This wrapper code conceptually exists at a higher-level than the core unix_stream_connect() and unix_stream_listen() routines that it consumes. It is isolated in a wrapper class for clarity. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-15simple-ipc: add win32 implementationLibravatar Jeff Hostetler1-0/+4
Create Windows implementation of "simple-ipc" using named pipes. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-13use CALLOC_ARRAYLibravatar René Scharfe1-0/+8
Add and apply a semantic patch for converting code that open-codes CALLOC_ARRAY to use it instead. It shortens the code and infers the element size automatically. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-08fix xcalloc() argument orderLibravatar René Scharfe1-0/+10
Pass the number of elements first and ther size second, as expected by xcalloc(). Provide a semantic patch, which was actually used to generate the rest of this patch. The semantic patch would generate flip-flop diffs if both arguments are sizeofs. We don't have such a case, and it's hard to imagine the usefulness of such an allocation. If it ever occurs then we could deal with it by duplicating the rule in the semantic patch to make it cancel itself out, or we could change the code to use CALLOC_ARRAY. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-05stash show: teach --include-untracked and --only-untrackedLibravatar Denton Liu1-1/+1
Stash entries can be made with untracked files via `git stash push --include-untracked`. However, because the untracked files are stored in the third parent of the stash entry and not the stash entry itself, running `git stash show` does not include the untracked files as part of the diff. With --include-untracked, untracked paths, which are recorded in the third-parent if it exists, are shown in addition to the paths that have modifications between the stash base and the working tree in the stash. It is possible to manually craft a malformed stash entry where duplicate untracked files in the stash entry will mask tracked files. We detect and error out in that case via a custom unpack_trees() callback: stash_worktree_untracked_merge(). Also, teach stash the --only-untracked option which only shows the untracked files of a stash entry. This is similar to `git show stash^3` but it is nice to provide a convenient abstraction for it so that users do not have to think about the underlying implementation. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-12Merge branch 'jk/complete-branch-force-delete'Libravatar Junio C Hamano1-2/+4
The command line completion (in contrib/) completed "git branch -d" with branch names, but "git branch -D" offered tagnames in addition, which has been corrected. "git branch -M" had the same problem. * jk/complete-branch-force-delete: doc/git-branch: fix awkward wording for "-c" completion: handle other variants of "branch -m" completion: treat "branch -D" the same way as "branch -d"
2021-02-03completion: handle other variants of "branch -m"Libravatar Jeff King1-2/+4
We didn't special-case "branch -M" (with a capital M) the same as "branch -m", nor any of the "--copy" variants. As a result these offered any ref as the next candidate, and not just branch names. Note that I rewrapped case-arm line since it's now quite long, and likewise the one below it for consistency. I also re-ordered the existing "-D" to make it more obvious how the cases group together. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-02completion: treat "branch -D" the same way as "branch -d"Libravatar Jeff King1-1/+1
The former offers not just branches but tags as completion candidates. Mimic how "branch -d" limits its suggestion to branch names. Reported-by: Paul Jolly <paul@myitcv.io> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-23Remove support for v1 of the PCRE libraryLibravatar Ævar Arnfjörð Bjarmason1-4/+0
Remove support for using version 1 of the PCRE library. Its use has been discouraged by upstream for a long time, and it's in a bugfix-only state. Anyone who was relying on v1 in particular got a nudge to move to v2 in e6c531b808 (Makefile: make USE_LIBPCRE=YesPlease mean v2, not v1, 2018-03-11), which was first released as part of v2.18.0. With this the LIBPCRE2 test prerequisites is redundant to PCRE. But I'm keeping it for self-documentation purposes, and to avoid conflict with other in-flight PCRE patches. I'm also not changing all of our own "pcre2" names to "pcre", i.e. the inverse of 6d4b5747f0 (grep: change internal *pcre* variable & function names to be *pcre1*, 2017-05-25). I don't see the point, and it makes the history/blame harder to read. Maybe if there's ever a PCRE v3... Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-04completion: add proper public __git_completeLibravatar Felipe Contreras1-7/+33
When __git_complete was introduced, it was meant to be temporarily, while a proper guideline for public shell functions was established (tentatively _GIT_complete), but since that never happened, people in the wild started to use __git_complete, even though it was marked as not public. Eight years is more than enough wait, let's mark this function as public, and make it a bit more user-friendly. So that instead of doing: __git_complete gk __gitk_main The user can do: __git_complete gk gitk And instead of: __git_complete gf _git_fetch Do: __git_complete gf git_fetch Backwards compatibility is maintained. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-04completion: bash: improve function detectionLibravatar Felipe Contreras1-1/+1
1. We should quote the argument 2. We don't need two redirections 3. A safeguard for arguments (-a) would be good Suggested-by: René Scharfe <l.s.r@web.de> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>