kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Ryan Zoeller	c099f579b9	completion: add GIT_COMPLETION_SHOW_ALL env var When set to 1, GIT_COMPLETION_SHOW_ALL causes --git-completion-helper-all to be passed instead of --git-completion-helper. Signed-off-by: Ryan Zoeller <rtzoeller@rtzoeller.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Danny Lin	ce820cbd58	contrib/subtree: document 'push' does not take '--squash' git subtree push does not support --squash, as previously illustrated in `6ccc71a9` (contrib/subtree: there's no push --squash, 2015-05-07) Signed-off-by: Danny Lin <danny0838@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Danny Lin	f99c0c996b	contrib/subtree: fix "unsure" for --message in the document Revise the documentation and remove previous "unsure" after making sure that --message supports only 'add', 'merge', 'pull', and 'split --rejoin'. Signed-off-by: Danny Lin <danny0838@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Emily Shaffer	b87528c4d7	Revert "contrib: subtree: adjust test to change in fmt-merge-msg" This reverts commit `508fd8e8ba`. In `6e6029a8` (fmt-merge-msg: allow merge destination to be omitted again) we get back the behavior where merges against 'master', by default, do not include "into 'master'" at the end of the merge message. This test fix is no longer needed. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
pudinha	11868978c7	mergetools: add support for nvimdiff (neovim) family Signed-off-by: pudinha <rogi@skylittlesystem.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
David J. Malan	e8882a87d9	git-prompt: change == to = for zsh's sake When using git-prompt.sh with zsh, __git_ps1 currently errs when inside a repo with: __git_ps1:96: = not found Avoid using non-portable "==" that is only understood by bash and not zsh. Change to "=" so that the prompt script becomes usable with zsh again. Signed-off-by: David J. Malan <malan@harvard.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Michal Privoznik	688b87c81b	completion: add show --color-moved[-ws] The completion for diff command was added in `fd0bc17557` but missed the show command which also supports --color-moved[-ws]. This suffers from the very same problem [1] as the referenced commit: no comma-separated list completion for --color-moved-ws. [1]: https://github.com/scop/bash-completion/issues/240 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Ville Skyttä	c2dbcd206d	completion: nounset mode fixes Accessing unset variables results an errors when the shell is in nounset/-u mode. This fixes the cases I've come across while using git completion in a shell running in that mode for a while. It's hard to tell if this is the complete set, but at least it improves things. Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Đoàn Trần Công Danh	508fd8e8ba	contrib: subtree: adjust test to change in fmt-merge-msg We're starting to stop treating `master' specially in fmt-merge-msg. Adjust the test to reflect that change. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Sibi Siddharthan	7f475e2780	cmake: support for building git on windows with msvc and clang. This patch adds support for Visual Studio and Clang builds The minimum required version of CMake is upgraded to 3.15 because this version offers proper support for Clang builds on Windows. Libintl is not searched for when building with Visual Studio or Clang because there is no binary compatible version available yet. NOTE: In the link options invalidcontinue.obj has to be included. The reason for this is because by default, Windows calls abort()'s instead of setting errno=EINVAL when invalid arguments are passed to standard functions. This commit explains it in detail: `4b623d80f7` On Windows the default generator is Visual Studio,so for Visual Studio builds do this: cmake `relative-path-to-srcdir` NOTE: Visual Studio generator is a multi config generator, which means that Debug and Release builds can be done on the same build directory. For Clang builds do this: On bash CC=clang cmake `relative-path-to-srcdir` -G Ninja -DCMAKE_BUILD_TYPE=[Debug or Release] On cmd set CC=Clang cmake `relative-path-to-srcdir` -G Ninja -DCMAKE_BUILD_TYPE=[Debug or Release] Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Sibi Siddharthan	f7adba4182	cmake: support for building git on windows with mingw This patch facilitates building git on Windows with CMake using MinGW NOTE: The funtions unsetenv and hstrerror are not checked in Windows builds. Reasons NO_UNSETENV is not compatible with Windows builds. lines 262-264 compat/mingw.h compat/mingw.h(line 25) provides a definition of hstrerror which conflicts with the definition provided in git-compat-util.h(lines 733-736). To use CMake on Windows with MinGW do this: cmake `relative-path-to-srcdir` -G "MinGW Makefiles" Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Sibi Siddharthan	7f5397a07c	cmake: support for testing git when building out of the source tree This patch allows git to be tested when performin out of source builds. This involves changing GIT_BUILD_DIR in t/test-lib.sh to point to the build directory. Also some miscellaneous copies from the source directory to the build directory. The copies are: t/chainlint.sed needed by a bunch of test scripts po/is.po needed by t0204-gettext-rencode-sanity mergetools/tkdiff needed by t7800-difftool contrib/completion/git-prompt.sh needed by t9903-bash-prompt contrib/completion/git-completion.bash needed by t9902-completion contrib/svn-fe/svnrdump_sim.py needed by t9020-remote-svn NOTE: t/test-lib.sh is only modified when tests are run not during the build or configure. The trash directory is still srcdir/t Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Sibi Siddharthan	c4b2f41b5f	cmake: support for testing git with ctest This patch provides an alternate way to test git using ctest. CTest ships with CMake, so there is no additional dependency being introduced. To perform the tests with ctest do this after building: ctest -j[number of jobs] NOTE: -j is optional, the default number of jobs is 1 Each of the jobs does this: cd t/ && sh t[something].sh The reason for using CTest is that it logs the output of the tests in a neat way, which can be helpful during diagnosis of failures. After the tests have run ctest generates three log files located in `build-directory`/Testing/Temporary/ These log files are: CTestCostData.txt: This file contains the time taken to complete each test. LastTestsFailed.log: This log file contains the names of the tests that have failed in the run. LastTest.log: This log file contains the log of all the tests that have run. A snippet of the file is given below. 10/901 Testing: D:/my/git-master/t/t0009-prio-queue.sh 10/901 Test: D:/my/git-master/t/t0009-prio-queue.sh Command: "sh.exe" "D:/my/git-master/t/t0009-prio-queue.sh" Directory: D:/my/git-master/t "D:/my/git-master/t/t0009-prio-queue.sh" Output: ---------------------------------------------------------- ok 1 - basic ordering ok 2 - mixed put and get ok 3 - notice empty queue ok 4 - stack order passed all 4 test(s) 1..4 <end of output> Test time = 1.11 sec NOTE: Testing only works when building in source for now. Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Sibi Siddharthan	f1f5dff9e7	cmake: installation support for git Install the built binaries and scripts using CMake This is very similar to `make install`. By default the destination directory(DESTDIR) is /usr/local/ on Linux To set a custom installation path do this: cmake `relative-path-to-srcdir` -DCMAKE_INSTALL_PREFIX=`preferred-install-path` Then run `make install` Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Sibi Siddharthan	afa45fe5c0	cmake: generate the shell/perl/python scripts and templates, translations Implement the placeholder substitution to generate scripted Porcelain commands, e.g. git-request-pull out of git-request-pull.sh Generate shell/perl/python scripts and template using CMake instead of using sed like the build procedure in the Makefile does. The text translations are only build if `msgfmt` is found in your path. NOTE: The scripts and templates are generated during configuration. Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Elijah Newren	afda36dbf3	git-prompt: include sparsity state as well git-prompt includes the current branch, a bunch of single character mini-state displayers, and some much longer in-progress state notifications. The current branch is always shown. The single character mini-state displayers are all off by default (they are not self explanatory) but each has an environment variable for turning it on. The in-progress state notifications provide no configuration options for turning them off, and can be up to 15 characters long (e.g. "\|REBASE (12/18)" or "\|CHERRY-PICKING"). The single character mini-state tends to be used for things like "Do you have any stashes in refs/stash?" or "Are you ahead or behind of upstream?". These are things which users can take advantage of but do not affect most normal git operations. The in-progress states, by contrast, suggest the user needs to interact differently and may also prevent some normal operations from succeeding (e.g. git switch may show an error instead of switching branches). Sparsity is like the in-progress states in that it suggests a fundamental different interaction with the repository (many of the files from the repository are not present in your working copy!). A few commits ago added sparsity information to wt_longstatus_print_state(), grouping it with other in-progress state displays. We do similarly here with the prompt and show the extra state, by default, with an extra \|SPARSE This state can be present simultaneously with the in-progress states, in which case it will appear before the other states; for example, (branchname\|SPARSE\|REBASE 6/10) The reason for showing the "\|SPARSE" substring before other states is to emphasize those other states. Sparsity is probably not going to change much within a repository, while temporary operations will. So we want the state changes related to temporary operations to be listed last, to make them appear closer to where the user types and make them more likely to be noticed. The fact that sparsity isn't just cached metadata or additional information is what leads us to show it more similarly to the in-progress states, but the fact that sparsity is not transient like the in-progress states might cause some users to want an abbreviated notification of sparsity state or perhaps even be able to turn it off. Allow GIT_PS1_COMPRESSSPARSESTATE to be set to request that it be shortened to a single character ('?'), and GIT_PS1_OMITSPARSESTATE to be set to request that sparsity state be omitted from the prompt entirely. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Elijah Newren	30b00f009c	git-prompt: document how in-progress operations affect the prompt Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Abhishek Kumar	c49c82aa4c	commit: move members graph_pos, generation to a slab We remove members `graph_pos` and `generation` from the struct commit. The default assignments in init_commit_node() are no longer valid, which is fine as the slab helpers return appropriate default values and the assignments are removed. We will replace existing use of commit->generation and commit->graph_pos by commit_graph_data_slab helpers using `contrib/coccinelle/commit.cocci'. Signed-off-by: Abhishek Kumar <abhishekkumar8222@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Sibi Siddharthan	061c2240b1	Introduce CMake support for configuring Git At the moment, the recommended way to configure Git's builds is to simply run `make`. If that does not work, the recommended strategy is to look at the top of the `Makefile` to see whether any "Makefile knob" has to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`. Alternatively, Git also has an `autoconf` setup which allows configuring builds via `./configure [<option>...]`. Both of these options are fine if the developer works on Unix or Linux. But on Windows, we have to jump through hoops to configure a build (read: we force the user to install a full Git for Windows SDK, which occupies around two gigabytes (!) on disk and downloads about three quarters of a gigabyte worth of Git objects). The build infrastructure for Git is written around being able to run make, which is not supported natively on Windows. To help Windows developers a CMake build script is introduced here. With a working support CMake, developers on Windows need only install CMake, configure their build, load the generated Visual Studio solution and immediately start modifying the code and build their own version of Git. Likewise, developers on other platforms can use the convenient GUI tools provided by CMake to configure their build. So let's start building CMake support for Git. This is only the first step, and to make it easier to review, it only allows for configuring builds on the platform that is easiest to configure for: Linux. The CMake script checks whether the headers are present(eg. libgen.h), whether the functions are present(eg. memmem), whether the funtions work properly (eg. snprintf) and generate the required compile definitions for the platform. The script also searches for the required libraries, if it fails to find the required libraries the respective executables won't be built.(eg. If libcurl is not found then git-remote-http won't be built). This will help building Git easier. With a CMake script an out of source build of git is possible resulting in a clean source tree. Note: this patch asks for the minimum version v3.14 of CMake (which is not all that old as of time of writing) because that is the first version to offer a platform-independent way to generate hardlinks as part of the build. This is needed to generate all those hardlinks for the built-in commands of Git. Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jacob Keller	91439928ec	completion: improve handling of --orphan option of switch/checkout The --orphan option is used to create a local branch which is detached from the current history. In git switch, it always resets to the empty tree, and thus the only completion we can provide is a branch name. Follow the same rules for -c/-C (and -b/-B) when completing the argument to --orphan. In the case of git switch, after we complete the argument, there is nothing more we can complete for git switch, so do not even try. Nothing else would be valid. In the case of git checkout, --orphan takes a start point which it uses to determine the checked out tree, even though it created orphaned history. Update the previously added test cases as they are now passing. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jacob Keller	acb658fe7d	completion: improve handling of -c/-C and -b/-B in switch/checkout A previous commit added several test cases highlighting the subpar completion logic for -c/-C and -b/-B when completing git switch and git checkout. In order to distinguish completing the argument vs the start-point for this option, we now use the wordlist to determine the previous full word on the command line. If it's -c or -C (-b/-B for checkout), then we know that we are completing the argument for the branch name. Given that a user who already knows the branch name they want to complete will simply not use completion, it makes sense to complete the small subset of local branches when completing the argument for -c/-C. In all other cases, if -c/-C are on the command line but are not the most recent option, then we must be completing a start-point, and should allow completing against all references. Update the -c/-C and -b/-B tests to indicate they now pass. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jacob Keller	00e7bd2b00	completion: improve handling of --track in switch/checkout Current completion for the --track option of git switch and git checkout is sub par. In addition to the DWIM logic of a bare branch name, --track has DWIM logic to convert specified remote/branch names into a local branch tracking that remote. For example $git switch --track origin/master This will create a local branch name master, that tracks the master branch of the origin remote. In fact, git switch --track on its own will not accept other forms of references. These must instead be specified manually via the -c/-C/-b/-B options. Introduce __git_remote_heads() and the "remote-heads" mode for __git_complete_refs. Use this when the --track option is provided while completing in _git_switch and _git_checkout. Just as in the --detach case, we never enable DWIM mode for --track, because it doesn't make sense. It should be noted that completion support is still a bit sub par when it comes to handling -c/-C and --orphan. This will be resolved in a future change. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jacob Keller	6d76a5cc7f	completion: improve handling of --detach in checkout Just like git switch, we should not complete DWIM remote branch names if --detach has been specified. To avoid this, refactor _git_checkout in a similar way to _git_switch. Note that we don't simply clear dwim_opt when we find -d or --detach, as we will be adding other modes and checks, making this flow easier to follow. Update the previously failing tests to show that the breakage has been resolved. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jacob Keller	68d97c7fdd	completion: improve completion for git switch with no options Add a new --mode option to __git_complete_refs, which allows changing the behavior to call __git_heads instead of __git_refs. By passing --mode=heads, __git_complete_refs will only output local branches. This enables using "--mode=heads --dwim" to enable listing local branches and the remote unique branch names for DWIM. Refactor completion support to use the new mode option, rather than calling __git_heads directly. This has the advantage that we can now correctly allow local branches along with suitable DWIM refs, rather than only allowing DWIM when we complete all references. Choose what mode it uses when calling __git_complete_refs. If -d or --detach have been provided, then simply complete all refs, but without the DWIM option as these DWIM names won't work properly in --detach mode. Otherwise, call __git_complete_refs with the default dwim_opt value and use the new "heads" mode. In this way, the basic support for completing just "git switch <TAB>" will result in only local branches and remote unique names for DWIM. The basic no-options tests for git switch, as well as several of the -c/-C tests now pass, so remove the known breakage tags. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jacob Keller	4e79adf4e5	completion: improve handling of DWIM mode for switch/checkout A new helper, __git_find_last_on_cmdline is introduced, similar to the already existing __git_find_on_cmdline, but which operates in reverse, finding the last matching word of the provided wordlist. Use this in a new __git_checkout_default_dwim_mode() function that will determine when to enable listing of DWIM remote branches. The __git_find_last_on_cmdline() function is used to determine which --guess or --no-guess is in effect. If either one is provided, then we unconditionally enable or disable the DWIM mode based on the last provided option. If neither --guess nor --no-guess is provided, then we check for --no-track, and finally for GIT_COMPLETION_CHECKOUT_NO_GUESS=1. This function is then used in _git_switch and _git_checkout to improve the handling for when we enable listing of these DWIM remote branches. This new logic is more robust, as we will correctly identify superseded options, and ensure that both _git_switch and _git_checkout enable DWIM in similar ways. We can now update a few tests to indicate they pass. A few of the tests previously added to highlight issues with the old DWIM logic still fail. This is because of a separate issue related to the default completion behavior of git switch, which will be addressed in a future change. Additionally, due to this change, a few tests for the -b/-B handling of git checkout now fail. This is a minor regression, and will be fixed by a following change that improves the overall handling of -b/-B. Mark these tests as known breakages for now. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jacob Keller	688077910b	completion: perform DWIM logic directly in __git_complete_refs __git_complete_refs is the main function used for completing references. It is primarily used as a wrapper around __git_refs, and is easier to extend since its arguments are option-like. One major downside of __git_complete_refs and __git_refs currently, is the lack of ability to complete only a subset of refs such as branches (refs/heads) or tags (refs/tags). Normally, a caller might just decide to use __git_heads() or __git_tags(). However, in the case of git-switch, it is useful to complete both branches and DWIM remote branch names. Due to the complexity and implementation of __git_refs, it is not easy to extend it to support listing only a subset of references. Instead, we can extend __git_complete_refs to do this. For this to be done, we must first ensure that "--dwim" support is not tied to calling __git_refs. Instead of passing $dwim into __git_refs, we can implement a __gitcomp_direct_append function which can append to COMPREPLY after a call to __gitcomp_direct. If --dwim is passed to __git_complete_refs, use __gitcomp_direct_append to add the output of __git_dwim_remote_heads to the completion list. In this way, --dwim support is now independent of calling __git_refs. A future change will add an additional option to control what set of references __git_complete_refs will output. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jacob Keller	58a2ca37a1	completion: extract function __git_dwim_remote_heads __git_refs() has the ability to report unique remote names for supporting completion of remote branch names for the DWIMery of git checkout and git switch. For git checkout, this is fine, because it always supports completing all local references. However, git switch by default only supports either switching branches or using this DWIMery to create a local branch tracking the remote branch. Future work to cleanup and improve completion support for git switch will be aided if the remote branch names can be completed separately from __git_refs. Extract this logic to a function __git_dwim_remote_heads(), and use it in __git_refs. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jacob Keller	0408c6b412	completion: replace overloaded track term for __git_complete_refs The __git_complete_refs uses the "--track" option to specify when to enable listing of unique remote branches which are used by the DWIM logic of git checkout and git switch. Using the term '--track' here is confusing because the git commands themselves have '--track' as an argument. Additionally, the completion logic for _git_switch also checks for --track. Keeping the meaning of track_opt and --track for __git_complete_refs straight from the --track git switch and git checkout option is difficult when reading this code. Use the option '--dwim' instead, indicating this is about enabling or disabling logic related to DWIM mode. Also rename the local variable track_opt to dwim_opt to further reduce the confusion when reading the completion code for _git_switch. Because it is plausible for users to have developed their own completions which rely on __git_complete_ref, keep --track as a synonym for --dwim, even though we no longer use it in any of the core git completion logic. Add a comment explaining why it remains as an alternative spelling for --dwim. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Marco Trevisan (Treviño)	a44a0a9fc4	completion: use native ZSH array pattern matching When clearing the builtin operations on re-sourcing in the ZSH case we can use the native ${parameters} associative array keys values to get the currently `__gitcomp_builtin_*` operations using pattern matching instead of using sed. As also stated in commit `94408dc7`, introducing this change the usage of sed has some overhead implications, while ZSH can do this check just using its native syntax. Signed-off-by: Marco Trevisan (Treviño) <mail@3v1n0.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Ville Skyttä	fffd0cf520	completion: don't override given stash subcommand with -p `df70b190` (completion: make stash -p and alias for stash push -p, 2018-04-20) wanted to make sure "git stash -p <TAB>" offers the same completion as "git stash push -p <TAB>", but it did so by forcing the $subcommand to be "push" whenever then "-p" option is found on the command line. This harms any subcommand that can take the "-p" option---even when the subcommand is explicitly given, e.g. "git stash show -p", the code added by the change would overwrite the $subcommand the user gave us. Fix it by making sure that the defaulting to "push" happens only when there is no $subcommand given yet. Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
SZEDER Gábor	b928e488bd	completion: offer '--(no-)patch' among 'git log' options Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Terry Moschou	051cc54941	complete: zsh: add missing sub cmd completion candidates Add missing 'restore' and 'switch' sub commands to zsh completion candidate output. E.g. $ git re<tab> rebase -- forward-port local commits to the updated upstream head reset -- reset current HEAD to the specified state restore -- restore working tree files $ git s<tab> show -- show various types of objects status -- show the working tree status switch -- switch branches Signed-off-by: Terry Moschou <tmoschou@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Johannes Schindelin	826f0c0df2	subtree: fix build with AsciiDoctor 2 This is a (late) companion for `f6461b82b9` (Documentation: fix build with Asciidoctor 2, 2019-09-15). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Elijah Newren	c0af173a13	completion: fix 'git add' on paths under an untracked directory As reported on the git mailing list, since git-2.25, git add untracked-dir/ has been tab completing to git add untracked-dir/./ The cause for this was that with commit `b9670c1f5e` (dir: fix checks on common prefix directory, 2019-12-19), git ls-files -o --directory untracked-dir/ (or the equivalent `git -C untracked-dir ls-files -o --directory`) began reporting untracked-dir/ instead of listing paths underneath that directory. It may also be worth noting that the real command in question was git -C untracked-dir ls-files -o --directory '' which is equivalent to git ls-files -o --directory 'untracked-dir/' which behaves the same for the purposes of this issue (the '' can match the empty string), but becomes relevant for the proposed fix. At first, based on the report, I decided to try to view this as a regression and tried to find a way to recover the old behavior without breaking other stuff, or at least breaking as little as possible. However, in the end, I couldn't figure out a way to do it that wouldn't just cause lots more problems than it solved. The old behavior was a bug: Although older git would avoid cleaning anything with `git clean -f .git`, it would wipe out everything under that direcotry with `git clean -f .git/`. Despite the difference in command used, this is relevant because the exact same change that fixed clean changed the behavior of ls-files. * Older git would report different results based solely on presence or absence of a trailing slash for $SUBDIR in the command `git ls-files -o --directory $SUBDIR`. * Older git violated the documented behavior of not recursing into directories that matched the pathspec when --directory was specified. * And, after all, commit `b9670c1f5e` (dir: fix checks on common prefix directory, 2019-12-19) didn't overlook this issue; it explicitly stated that the behavior of the command was being changed to bring it inline with the docs. (Also, if it helps, despite that commit being merged during the 2.25 series, this bug was not reported during the 2.25 cycle, nor even during most of the 2.26 cycle -- it was reported a day before 2.26 was released. So the impact of the change is at least somewhat small.) Instead of relying on a bug of ls-files in reporting the wrong content, change the invocation of ls-files used by git-completion to make it grab paths one depth deeper. Do this by changing '$DIR/' (match $DIR/ plus 0 or more characters) into '$DIR/?' (match $DIR/ plus 1 or more characters). Note that the '?' character should not be added when trying to complete a filename (e.g. 'git ls-files -o --directory "merge.c?*"' would not correctly return "merge.c" when such a file exists), so we have to make sure to add the '?' character only in cases where the path specified so far is a directory. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Johannes Schindelin	c839fcff65	import-tars: ignore the global PAX header The tar importer in `contrib/fast-import/import-tars.perl` has a very convenient feature: if _all_ paths stored in the imported `.tar` start with a common prefix, e.g. `git-2.26.0/` in the tar at https://github.com/git/git/archive/v2.26.0.tar.gz, then this prefix is stripped. This feature makes a ton of sense because it is relatively common to import two or more revisions of the same project into Git, and obviously we don't want all files to live in a tree whose name changes from revision to revision. Now, the problem with that feature is that it breaks down if there is a `pax_global_header` "file" located outside of said prefix, at the top of the tree. This is the case for `.tar` files generated by Git's very own `git archive` command: it inserts that header, and `git archive` allows specifying a common prefix (that the header does _not_ share with the other files contained in the archive) via `--prefix=my-project-1.0.0/`. Let's just skip any global header when importing `.tar` files into Git. Note: this global header might contain useful information. For example, in the output of `git archive`, it lists the original commit, which _is_ useful information. A future improvement to the `import-tars.perl` script might be to include that information in the commit message, or do other things with the information (e.g. use `mtime` information contained in the global header as date of the commit). This patch does not prevent any future patch from making that happen, it only prevents the header from being treated as if it was a regular file. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Kir Kolyshkin	fd0bc17557	completion: add diff --color-moved[-ws] These options are available since git v2.15, but somehow eluded from the completion script. Note that while --color-moved-ws= accepts comma-separated list of values, there is no (easy?) way to make it work with completion (see e.g. [1]). [1]: https://github.com/scop/bash-completion/issues/240 Acked-by: Matheus Tavares Bernardino <matheus.bernardino@usp.br> Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Paolo Bonzini	aa416b22ea	am: support --show-current-patch=diff to retrieve .git/rebase-apply/patch When "git am --show-current-patch" was added in commit `984913a210` ("am: add --show-current-patch", 2018-02-12), "git am" started recommending it as a replacement for .git/rebase-merge/patch. Unfortunately the suggestion is somewhat misguided; for example, the output of "git am --show-current-patch" cannot be passed to "git apply" if it is encoded as quoted-printable or base64. Add a new mode to "git am --show-current-patch" in order to straighten the suggestion. Reported-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Paolo Bonzini	f3b4822899	am: support --show-current-patch=raw as a synonym for--show-current-patch When "git am --show-current-patch" was added in commit `984913a210` ("am: add --show-current-patch", 2018-02-12), "git am" started recommending it as a replacement for .git/rebase-merge/patch. Unfortunately the suggestion is somewhat misguided; for example, the output "git am --show-current-patch" cannot be passed to "git apply" if it is encoded as quoted-printable or base64. To simplify worktree operations and to avoid that users poke into .git, it would be better if "git am" also provided a mode that copies .git/rebase-merge/patch to stdout. One possibility could be to have completely separate options, introducing for example --show-current-message (for .git/rebase-apply/NNNN) and --show-current-diff (for .git/rebase-apply/patch), while possibly deprecating --show-current-patch. That would even remove the need for the first two patches in the series. However, the long common prefix would have prevented using an abbreviated option such as "--show". Therefore, I chose instead to add a string argument to --show-current-patch. The new argument is optional, so that "git am --show-current-patch"'s behavior remains backwards-compatible. The next choice to make is how to handle multiple --show-current-patch options. Right now, something like "git am --abort --show-current-patch" is rejected, and the previous suggestion would likewise have naturally rejected a command line like git am --show-current-message --show-current-diff Therefore, I decided to also reject for example git am --show-current-patch=diff --show-current-patch=raw In other words the whole of --show-current-patch=xxx (including the optional argument) is treated as the command mode. I found this to be more consistent and intuitive, even though it differs from the usual "last one wins" semantics of the git command line. Add the code to parse submodes based on the above design, where for now "raw" is the only valid submode. "raw" prints the full e-mail message just like "git am --show-current-patch". Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Elijah Newren	6d04ce75c4	git-prompt: change the prompt for interactive-based rebases In the past, we had different prompts for different types of rebases: REBASE: for am-based rebases REBASE-m: for merge-based rebases REBASE-i: for interactive-based rebases It's not clear why this distinction was necessary or helpful; when the prompt was added in commit `e75201963f` ("Improve bash prompt to detect various states like an unfinished merge", 2007-09-30), it simply added these three different types. Perhaps there was a useful purpose back then, but there have been some changes: * The merge backend was deleted after being implemented on top of the interactive backend, causing the prompt for merge-based rebases to change from REBASE-m to REBASE-i. * The interactive backend is used for multiple different types of non-interactive rebases, so the "-i" part of the prompt doesn't really mean what it used to. * Rebase backends have gained more abilities and have a great deal of overlap, sometimes making it hard to distinguish them. * Behavioral differences between the backends have also been ironed out. * We want to change the default backend from am to interactive, which means people would get "REBASE-i" by default if we didn't change the prompt, and only if they specified --am or --whitespace or -C would they get the "REBASE" prompt. * In the future, we plan to have "--whitespace", "-C", and even "--am" run the interactive backend once it can handle everything the am-backend can. For all these reasons, make the prompt for any type of rebase just be "REBASE". Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Matheus Tavares	d031049da3	completion: add support for sparse-checkout Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Acked-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Johannes Schindelin	b6d4d82bd5	msvc: accommodate for vcpkg's upgrade to OpenSSL v1.1.x With the upgrade, the library names changed from libeay32/ssleay32 to libcrypto/libssl. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
SZEDER Gábor	7d5ecd775d	completion: list paths and refs for 'git worktree add' Complete paths after 'git worktree add <TAB>' and refs after 'git worktree add -b <TAB>' and 'git worktree add some/dir <TAB>'. Uncharacteristically for a Git command, 'git worktree add' takes a mandatory path parameter before a commit-ish as its optional last parameter. In addition, it has both standalone --options and options with a mandatory unstuck parameter ('-b <new-branch>'). Consequently, trying to complete refs for that last optional commit-ish parameter resulted in a more convoluted than usual completion function, but hopefully all the included comments will make it not too hard to digest. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
SZEDER Gábor	3027e4f9a8	completion: list existing working trees for 'git worktree' subcommands Complete the paths of existing working trees for 'git worktree's 'move', 'remove', 'lock', and 'unlock' subcommands. Note that 'git worktree list --porcelain' shows absolute paths, so for simplicity's sake we'll complete full absolute paths as well (as opposed to turning them into relative paths by finding common leading directories between $PWD and the working tree's path and removing them, risking trouble with symbolic links or Windows drive letters; or completing them one path component at a time). Never list the path of the main working tree, as it cannot be moved, removed, locked, or unlocked. Ideally we would only list unlocked working trees for the 'move', 'remove', and 'lock' subcommands, and only locked ones for 'unlock'. Alas, 'git worktree list --porcelain' doesn't indicate which working trees are locked, so for now we'll complete the paths of all existing working trees. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
SZEDER Gábor	3c86f6cde8	completion: simplify completing 'git worktree' subcommands and options The completion function for 'git worktree' uses separate but very similar case arms to complete --options for each subcommand. Combine these into a single case arm to avoid repetition. Note that after this change we won't complete 'git worktree remove's '--force' option, but that is consistent with our general stance on not offering '--force', as it should be used with care. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
SZEDER Gábor	367efd54b3	completion: return the index of found word from __git_find_on_cmdline() When using the __git_find_on_cmdline() helper function so far we've only been interested in which one of a set of words appear on the command line. To complete options for some of 'git worktree's subcommands in the following patches we'll need not only that, but the index of that word on the command line as well. Extend __git_find_on_cmdline() to optionally show the index of the found word on the command line (IOW in the $words array) when the '--show-idx' option is given. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
SZEDER Gábor	d447fe2bfe	completion: clean up the __git_find_on_cmdline() helper function The __git_find_on_cmdline() helper function started its life as __git_find_subcommand() [1], but it served a more general purpose than looking for subcommands, so later it was renamed accordingly [2]. However, that rename didn't touch the body of the function, and left the $subcommand local variable behind, still reminiscent of the function's original purpose. Let's clean up the names of __git_find_on_cmdline()'s local variables and get rid of that $subcommand variable name. While at it, add a short comment describing the function's purpose. [1] `3ff1320d4b` (bash: refactor searching for subcommands on the command line, 2008-03-10), [2] `918c03c2a7` (bash: rename __git_find_subcommand() to __git_find_on_cmdline(), 2009-09-15) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Denton Liu	6579d93a97	contrib/credential/netrc: work outside a repo Currently, git-credential-netrc does not work outside of a git repository. It fails with the following error: fatal: Not a git repository: . at /usr/share/perl5/Git.pm line 214. There is no real reason why need to be within a repository, though. Credential helpers should be able to work just fine outside the repository as well. Call the non-self version of config() so that git-credential-netrc no longer needs to be run within a repository. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Denton Liu	1c78c78d25	contrib/credential/netrc: make PERL_PATH configurable The shebang path for the Perl interpreter in git-credential-netrc was hardcoded. However, some users may have it located at a different location and thus, would have had to manually edit the script. Add a .perl prefix to the script to denote it as a template and ignore the generated version. Augment the Makefile so that it generates git-credential-netrc from git-credential-netrc.perl, just like other Perl scripts. The Makefile recipes were shamelessly stolen from contrib/mw-to-git/Makefile. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Denton Liu	1f0fc1db85	pretty: implement 'reference' format The standard format for referencing other commits within some projects (such as git.git) is the reference format. This is described in Documentation/SubmittingPatches as If you want to reference a previous commit in the history of a stable branch, use the format "abbreviated hash (subject, date)", like this: .... Commit `f86a374` (pack-bitmap.c: fix a memleak, 2015-03-30) noticed that ... .... Since this format is so commonly used, standardize it as a pretty format. The tests that are implemented essentially show that the format-string does not change in response to various log options. This is useful because, for future developers, it shows that we've considered the limitations of the "canned format-string" approach and we are fine with them. Based-on-a-patch-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Denton Liu	f0f9de2bd7	completion: complete `tformat:` pretty format Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago

1 2 3 4 5 ...

3096 Commits (6ddd76fd6c356c037b5d5272732900f1f952721e)