summaryrefslogtreecommitdiff
path: root/contrib
AgeCommit message (Collapse)AuthorFilesLines
2021-05-22Merge branch 'jh/simple-ipc-sans-pthread'Libravatar Junio C Hamano1-1/+9
The "simple-ipc" did not compile without pthreads support, but the build procedure was not properly account for it. * jh/simple-ipc-sans-pthread: simple-ipc: correct ifdefs when NO_PTHREADS is defined
2021-05-21simple-ipc: correct ifdefs when NO_PTHREADS is definedLibravatar Jeff Hostetler1-1/+9
Simple IPC always requires threads (in addition to various platform-specific IPC support). Fix the ifdefs in the Makefile to define SUPPORTS_SIMPLE_IPC when appropriate. Previously, the Unix version of the code would only verify that Unix domain sockets were available. This problem was reported here: https://lore.kernel.org/git/YKN5lXs4AoK%2FJFTO@coredump.intra.peff.net/T/#m08be8f1942ea8a2c36cfee0e51cdf06489fdeafc Reported-by: Randall S. Becker <rsbecker@nexbridge.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-20Merge branch 'en/prompt-under-set-u'Libravatar Junio C Hamano1-3/+3
The bash prompt script (in contrib/) did not work under "set -u". * en/prompt-under-set-u: git-prompt: work under set -u
2021-05-16Merge branch 'dd/mailinfo-quoted-cr'Libravatar Junio C Hamano1-0/+5
"git mailinfo" (hence "git am") learned the "--quoted-cr" option to control how lines ending with CRLF wrapped in base64 or qp are handled. * dd/mailinfo-quoted-cr: am: learn to process quoted lines that ends with CRLF mailinfo: allow stripping quoted CR without warning mailinfo: allow squelching quoted CRLF warning mailinfo: warn if CRLF found in decoded base64/QP email mailinfo: stop parsing options manually mailinfo: load default metainfo_charset lazily
2021-05-13git-prompt: work under set -uLibravatar Elijah Newren1-3/+3
Commit afda36dbf3 ("git-prompt: include sparsity state as well", 2020-06-21) added the use of some variables to control how to show sparsity state in the git prompt, but implicitly assumed that undefined variables would be treated as the empty string. This breaks users who run under 'set -u'; fix the code to be more explicit. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-10Merge branch 'ls/subtree'Libravatar Junio C Hamano4-866/+1424
"git subtree" updates. * ls/subtree: (30 commits) subtree: be stricter about validating flags subtree: push: allow specifying a local rev other than HEAD subtree: allow 'split' flags to be passed to 'push' subtree: allow --squash to be used with --rejoin subtree: give the docs a once-over subtree: have $indent actually affect indentation subtree: don't let debug and progress output clash subtree: add comments and sanity checks subtree: remove duplicate check subtree: parse revs in individual cmd_ functions subtree: use "^{commit}" instead of "^0" subtree: don't fuss with PATH subtree: use "$*" instead of "$@" as appropriate subtree: use more explicit variable names for cmdline args subtree: use git-sh-setup's `say` subtree: use `git merge-base --is-ancestor` subtree: drop support for git < 1.7 subtree: more consistent error propagation subtree: don't have loose code outside of a function subtree: t7900: add porcelain tests for 'pull' and 'push' ...
2021-05-10am: learn to process quoted lines that ends with CRLFLibravatar Đoàn Trần Công Danh1-0/+5
In previous changes, mailinfo has learnt to process lines that decoded from base64 or quoted-printable, and ends with CRLF. Let's teach "am" that new trick, too. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-07Merge branch 'si/zsh-complete-comment-fix'Libravatar Junio C Hamano1-2/+3
Portability fix for command line completion script (in contrib/). * si/zsh-complete-comment-fix: work around zsh comment in __git_complete_worktree_paths
2021-05-07Merge branch 'dl/complete-stash-updates'Libravatar Junio C Hamano1-47/+51
Further update the command line completion (in contrib/) for "git stash". * dl/complete-stash-updates: git-completion.bash: consolidate cases in _git_stash() git-completion.bash: use $__git_cmd_idx in more places git-completion.bash: rename to $__git_cmd_idx git-completion.bash: separate some commands onto their own line
2021-05-07Merge branch 'dl/complete-stash'Libravatar Junio C Hamano1-62/+60
The command line completion (in contrib/) for "git stash" has been updated. * dl/complete-stash: git-completion.bash: use __gitcomp_builtin() in _git_stash() git-completion.bash: extract from else in _git_stash() git-completion.bash: pass $__git_subcommand_idx from __git_main()
2021-05-04work around zsh comment in __git_complete_worktree_pathsLibravatar Sardorbek Imomaliev1-2/+3
[PATCH]: contrib/completion/git-completion.bash, there is a construct where comment lines are placed between the command that is on the upstream of a pipe and the command that is on the downstream of a pipe in __git_complete_worktree_paths function. Unfortunately, this script is also used by Zsh completion, but Zsh mishandles this construct when "interactive_comments" option is not set (by default it is off on macOS), resulting in a breakage: $ git worktree remove [TAB] $ git worktree remove __git_complete_worktree_paths:7: command not found: # Move the comment, even though it explains what happens on the downstream of the pipe and logically belongs where it is right now, before the entire pipeline, to work around this problem. Signed-off-by: Sardorbek Imomaliev <sardorbek.imomaliev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-30Merge branch 'vs/completion-with-set-u'Libravatar Junio C Hamano1-1/+1
Effort to make the command line completion (in contrib/) safe with "set -u" continues. * vs/completion-with-set-u: completion: avoid aliased command lookup error in nounset mode
2021-04-28subtree: be stricter about validating flagsLibravatar Luke Shumaker2-25/+175
Don't silently ignore a flag that's invalid for a given subcommand. The user expected it to do something; we should tell the user that they are mistaken, instead of surprising the user. It could be argued that this change might break existing users. I'd argue that those existing users are already broken, and they just don't know it. Let them know that they're broken. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: push: allow specifying a local rev other than HEADLibravatar Luke Shumaker3-13/+47
'git subtree split' lets you specify a rev other than HEAD. 'git push' lets you specify a mapping between a local thing and a remot ref. So smash those together, and have 'git subtree push' let you specify which local thing to run split on and push the result of that split to the remote ref. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: allow 'split' flags to be passed to 'push'Libravatar Luke Shumaker3-12/+223
'push' does a 'split' internally, but it doesn't pass flags through to the 'split'. This is silly, if you need to pass flags to 'split', then it means that you can't use 'push'! So, have 'push' accept 'split' flags, and pass them through to 'split'. Add tests for this by copying split's tests with minimal modification. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: allow --squash to be used with --rejoinLibravatar Luke Shumaker3-24/+96
Besides being a genuinely useful thing to do, this also just makes sense and harmonizes which flags may be used when. `git subtree split --rejoin` amounts to "automatically go ahead and do a `git subtree merge` after doing the main `git subtree split`", so it's weird and arbitrary that you can't pass `--squash` to `git subtree split --rejoin` like you can `git subtree merge`. It's weird that `git subtree split --rejoin` inherits `git subtree merge`'s `--message` but not `--squash`. Reconcile the situation by just having `split --rejoin` actually just call `merge` internally (or call `add` instead, as appropriate), so it can get access to the full `merge` behavior, including `--squash`. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-27git-completion.bash: consolidate cases in _git_stash()Libravatar Denton Liu1-19/+2
The $subcommand case statement in _git_stash() is quite repetitive. Consolidate the cases together into one catch-all case to reduce the repetition. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-27git-completion.bash: use $__git_cmd_idx in more placesLibravatar Denton Liu1-12/+14
With the introduction of the $__git_cmd_idx variable in e94fb44042 (git-completion.bash: pass $__git_subcommand_idx from __git_main(), 2021-03-24), completion functions were able to know the index at which the git command is listed, allowing them to skip options that are given to the underlying git itself, not the corresponding command (e.g. `-C asdf` in `git -C asdf branch`). While most of the changes here are self-explanatory, some bear further explanation. For the __git_find_on_cmdline() and __git_find_last_on_cmdline() pair of functions, these functions are only ever called in the context of a git command completion function. These functions will only care about words after the command so we can safely ignore the words before this. For _git_worktree(), this change is technically a no-op (once the __git_find_last_on_cmdline change is also applied). It was in poor style to have hard-coded on the index right after `worktree`. In case `git worktree` were to ever learn to accept options, the current situation would be inflexible. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-27git-completion.bash: rename to $__git_cmd_idxLibravatar Denton Liu1-10/+10
In e94fb44042 (git-completion.bash: pass $__git_subcommand_idx from __git_main(), 2021-03-24), the $__git_subcommand_idx variable was introduced. Naming it after the index of the subcommand is needlessly confusing as, when this variable is used, it is in the completion functions for commands (e.g. _git_remote()) where for `git remote add`, the `remote` is referred to as the command and `add` is referred to as the subcommand. Rename this variable so that it's obvious it's about git commands. While we're at it, shorten up its name so that it's still readable without being a handful to type. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-20git-completion.bash: separate some commands onto their own lineLibravatar Denton Liu1-9/+28
In e94fb44042 (git-completion.bash: pass $__git_subcommand_idx from __git_main(), 2021-03-24), a line was introduced which contained multiple statements. This is difficult to read so break it into multiple lines. While we're at it, follow this convention for the rest of the __git_main() and break up lines that contain multiple statements. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-16completion: avoid aliased command lookup error in nounset modeLibravatar Ville Skyttä1-1/+1
Aliased command lookup accesses the `list` variable before it has been set, causing an error in "nounset" mode. Initialize to an empty string to avoid that. $ git nonexistent-command <Tab>bash: list: unbound variable Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> 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