summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-02-19doc: stash: split options from description (2)Libravatar Alexandr Miloslavskiy1-35/+57
Together with the previous patch, this brings docs for `git stash` to the common layout used for most other commands (see for example docs for `git add`, `git commit`, `git checkout`, `git reset`) where all options are documented in a separate list. After some thinking and having a look at docs for `git svn` and `git `submodule`, I have arrived at following conclusions: * Options should be described in a list rather then text to facilitate lookup for user. * Single list is better then multiple lists because it avoids copy&pasting descriptions between subcommands (or, without copy&pasting, user will have to look up missing options in other subcommands). * As a consequence, commands section should only give brief info and list possible options. Since options have good enough names, user will only need to look up the "interesting" options. * Every option should list which subcommands support it. I have decided to use alphabetical sorting in the list of options to facilitate lookup for user. There is some text editing done to make old descriptions better fit into the list-style format. Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-19doc: stash: split options from description (1)Libravatar Alexandr Miloslavskiy1-33/+35
This patch moves blocks of text as-is to make it easier to review the next patch. Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-19rm: support the --pathspec-from-file optionLibravatar Alexandr Miloslavskiy3-7/+117
Decisions taken for simplicity: 1) It is not allowed to pass pathspec in both args and file. Adjustments were needed for `if (!argc)` block: This code actually means "pathspec is not present". Previously, pathspec could only come from commandline arguments, so testing for `argc` was a valid way of testing for the presence of pathspec. But this is no longer true with `--pathspec-from-file`. During the entire `--pathspec-from-file` story, I tried to keep its behavior very close to giving pathspec on commandline, so that switching from one to another doesn't involve any surprises. However, throwing usage at user in the case of empty `--pathspec-from-file` would puzzle because there's nothing wrong with "usage" (that is, argc/argv array). On the other hand, throwing usage in the old case also feels bad to me. While it's less of a puzzle, I (as user) never liked the experience of comparing my commandline to "usage", trying to spot a difference. Since it's already known what the error is, it feels a lot better to give that specific error to user. Judging from [1] it doesn't seem that showing usage in this case was important (the patch was to avoid segfault), and it doesn't fit into how other commands react to empty pathspec (see for example `git add` with a custom message). Therefore, I decided to show new error text in both cases. In order to continue testing for error early, I moved `parse_pathspec()` higher. Now it happens before `read_cache()` / `hold_locked_index()` / `setup_work_tree()`, which shouldn't cause any issues. [1] Commit 7612a1ef ("git-rm: honor -n flag" 2006-06-09) Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-21doc: rm: synchronize <pathspec> descriptionLibravatar Alexandr Miloslavskiy1-29/+21
This patch continues the effort that is already applied to `git commit`, `git reset`, `git checkout` etc. 1) Changed outdated descriptions to mention pathspec instead. 2) Added reference to 'linkgit:gitglossary[7]'. 3) Removed content that merely repeated gitglossary. 4) Merged the remainder of "discussion" into `<patchspec>`. Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-16Sync with maintLibravatar Junio C Hamano2-4/+4
* maint: msvc: accommodate for vcpkg's upgrade to OpenSSL v1.1.x
2020-01-16msvc: accommodate for vcpkg's upgrade to OpenSSL v1.1.xLibravatar Johannes Schindelin2-4/+4
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>
2020-01-13Git 2.25Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-12Merge tag 'l10n-2.25.0-rnd1' of git://github.com/git-l10n/git-poLibravatar Junio C Hamano12-24312/+53740
l10n-2.25.0-rnd1 * tag 'l10n-2.25.0-rnd1' of git://github.com/git-l10n/git-po: l10n: zh_CN: for git v2.25.0 l10n round 1 l10n: Update Catalan translation l10n: de.po: Update German translation v2.25.0 round 1 l10n: de.po: Reword generation numbers l10n: bg.po: Updated Bulgarian translation (4800t) l10n: es: 2.25.0 round #1 l10n: sv.po: Update Swedish translation (4800t0f0u) l10n: fr.po v2.25.0 rnd 1 l10n: vi(4800t): Updated Vietnamese translation v2.25.0 l10n: zh_TW.po: update translation for v2.25.0 round 1 l10n: it.po: update the Italian translation for Git 2.25.0 l10n: git.pot: v2.25.0 round 1 (119 new, 13 removed) l10n: Update Catalan translation l10n: zh_TW: add translation for v2.24.0
2020-01-12Revert "Merge branch 'ra/rebase-i-more-options'"Libravatar Junio C Hamano7-327/+28
This reverts commit 5d9324e0f4210bb7d52bcb79efe3935703083f72, reversing changes made to c58ae96fc4bb11916b62a96940bb70bb85ea5992. The topic turns out to be too buggy for real use. cf. <f2fe7437-8a48-3315-4d3f-8d51fe4bb8f1@gmail.com>
2020-01-12l10n: zh_CN: for git v2.25.0 l10n round 1Libravatar Jiang Xin1-2275/+2807
Translate 119 new messages (4800t0f0u) for git 2.25.0. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2020-01-11Merge branch 'master' of github.com:Softcatala/git-po into git-po-masterLibravatar Jiang Xin1-3757/+4260
* 'master' of github.com:Softcatala/git-po: l10n: Update Catalan translation
2020-01-10Merge branch 'js/mingw-loosen-overstrict-tree-entry-checks'Libravatar Junio C Hamano2-7/+7
Further tweak to a "no backslash in indexed paths" for Windows port we applied earlier. * js/mingw-loosen-overstrict-tree-entry-checks: mingw: safeguard better against backslashes in file names
2020-01-10Merge branch 'ma/config-advice-markup-fix'Libravatar Junio C Hamano1-1/+1
Documentation markup fix. * ma/config-advice-markup-fix: config/advice.txt: fix description list separator
2020-01-10l10n: Update Catalan translationLibravatar Jordi Mas1-3757/+4260
Signed-off-by: Jordi Mas <jmas@softcatala.org>
2020-01-10mingw: safeguard better against backslashes in file namesLibravatar Johannes Schindelin via GitGitGadget2-7/+7
In 224c7d70fa1 (mingw: only test index entries for backslashes, not tree entries, 2019-12-31), we relaxed the check for backslashes in tree entries to check only index entries. However, the code change was incorrect: it was added to `add_index_entry_with_check()`, not to `add_index_entry()`, so under certain circumstances it was possible to side-step the protection. Besides, the description of that commit purported that all index entries would be checked when in fact they were only checked when being added to the index (there are code paths that do not do that, constructing "transient" index entries). In any case, it was pointed out in one insightful review at https://github.com/git-for-windows/git/pull/2437#issuecomment-566771835 that it would be a much better idea to teach `verify_path()` to perform the check for a backslash. This is safer, even if it comes with two notable drawbacks: - `verify_path()` cannot say _what_ is wrong with the path, therefore the user will no longer be told that there was a backslash in the path, only that the path was invalid. - The `git apply` command also calls the `verify_path()` function, and might have been able to handle Windows-style paths (i.e. with backslashes instead of forward slashes). This will no longer be possible unless the user (temporarily) sets `core.protectNTFS=false`. Note that `git add <windows-path>` will _still_ work because `normalize_path_copy_len()` will convert the backslashes to forward slashes before hitting the code path that creates an index entry. The clear advantage is that `verify_path()`'s purpose is to check the validity of the file name, therefore we naturally tap into all the code paths that need safeguarding, also implicitly into future code paths. The benefits of that approach outweigh the downsides, so let's move the check from `add_index_entry_with_check()` to `verify_path()`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-10l10n: de.po: Update German translation v2.25.0 round 1Libravatar Matthias Rüster1-2282/+2844
Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com> Reviewed-by: Ralf Thielow <ralf.thielow@gmail.com> Reviewed-by: Phillip Szelat <phillip.szelat@gmail.com>
2020-01-10l10n: de.po: Reword generation numbersLibravatar Thomas Braun1-1/+1
The english term generation is here not used in the sense of "to generate" but in the sense of "generations of beings". This corrects the initial translation from cf4c0c25 (l10n: update German translation, 2018-12-06). Fixed-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
2020-01-09l10n: bg.po: Updated Bulgarian translation (4800t)Libravatar Alexander Shopov1-2353/+2905
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2020-01-08config/advice.txt: fix description list separatorLibravatar Martin Ågren1-1/+1
The whole submoduleAlternateErrorStrategyDie item is interpreted as being part of the supporting content of the preceding item. This is because we don't give a double-colon "::" for the separator, but just a single colon, ":". Let's fix that. There are a few other matches for [^:]:\s*$ in Documentation/config, but I didn't spot any similar bugs among them. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-08Git 2.25-rc2Libravatar Junio C Hamano2-1/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-08Merge branch 'ds/graph-assert-fix'Libravatar Junio C Hamano2-8/+80
Since recent updates to the log graph rendering code, drawing certain merges started triggering an assert on a condition that would no longer hold true, which has been corrected. * ds/graph-assert-fix: graph: fix lack of color in horizontal lines graph: drop assert() for merge with two collapsing parents
2020-01-08Merge branch 'tm/doc-submodule-absorb-fix'Libravatar Junio C Hamano1-1/+1
Typofix. * tm/doc-submodule-absorb-fix: doc: submodule: fix typo for command absorbgitdirs
2020-01-08Merge branch 'pm/am-in-body-header-doc-update'Libravatar Junio C Hamano1-2/+2
Doc update. * pm/am-in-body-header-doc-update: am: document that Date: can appear as an in-body header
2020-01-08Merge branch 'jb/doc-multi-pack-idx-fix'Libravatar Junio C Hamano1-1/+1
Typofix. * jb/doc-multi-pack-idx-fix: multi-pack-index: correct configuration in documentation
2020-01-08Merge branch 'do/gitweb-typofix-in-comments'Libravatar Junio C Hamano1-2/+2
Typofix. * do/gitweb-typofix-in-comments: gitweb: fix a couple spelling errors in comments
2020-01-08Merge https://github.com/prati0100/git-guiLibravatar Junio C Hamano10-232/+920
* https://github.com/prati0100/git-gui: git-gui: allow opening currently selected file in default app git-gui: allow closing console window with Escape git gui: fix branch name encoding error git-gui: revert untracked files by deleting them git-gui: update status bar to track operations git-gui: consolidate naming conventions
2020-01-08graph: fix lack of color in horizontal linesLibravatar Derrick Stolee2-4/+38
In some cases, horizontal lines in rendered graphs can lose their coloring. This is due to a use of graph_line_addch() instead of graph_line_write_column(). Using a ternary operator to pick the character is nice for compact code, but we actually need a column to provide the color. Add a test to t4215-log-skewed-merges.sh to prevent regression. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-08graph: drop assert() for merge with two collapsing parentsLibravatar Derrick Stolee2-4/+42
When "git log --graph" shows a merge commit that has two collapsing lines, like: | | | | * | |_|_|/| |/| | |/ | | |/| | |/| | | * | | * | | | we trigger an assert(): graph.c:1228: graph_output_collapsing_line: Assertion `graph->mapping[i - 3] == target' failed. The assert was introduced by eaf158f8 ("graph API: Use horizontal lines for more compact graphs", 2009-04-21), which is quite old. This assert is trying to say that when we complete a horizontal line with a single slash, it is because we have reached our target. It is actually the _second_ collapsing line that hits this assert. The reason we are in this code path is because we are collapsing the first line, and in that case we are hitting our target now that the horizontal line is complete. However, the second line cannot be a horizontal line, so it will collapse without horizontal lines. In this case, it is inappropriate to assert that we have reached our target, as we need to continue for another column before reaching the target. Dropping the assert is safe here. The new behavior in 0f0f389f12 (graph: tidy up display of left-skewed merges, 2019-10-15) caused the behavior change that made this assertion failure possible. In addition to making the assert possible, it also changed how multiple edges collapse. In a larger example, the current code will output a collapse as follows: | | | | | | * | |_|_|_|_|/|\ |/| | | | |/ / | | | | |/| / | | | |/| |/ | | |/| |/| | |/| |/| | | | |/| | | | | * | | | However, the intended collapse should allow multiple horizontal lines as follows: | | | | | | * | |_|_|_|_|/|\ |/| | | | |/ / | | |_|_|/| / | |/| | | |/ | | | |_|/| | | |/| | | | | * | | | This behavior is not corrected by this change, but is noted for a later update. Helped-by: Jeff King <peff@peff.net> Reported-by: Bradley Smith <brad@brad-smith.co.uk> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-06The final batch before -rc2Libravatar Junio C Hamano1-2/+18
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-06Merge branch 'ds/sparse-cone'Libravatar Junio C Hamano2-3/+3
Code cleanup. * ds/sparse-cone: Documentation/git-sparse-checkout.txt: fix a typo sparse-checkout: use extern for global variables
2020-01-06Merge branch 'ds/commit-graph-set-size-mult'Libravatar Junio C Hamano2-4/+4
The code to write split commit-graph file(s) upon fetching computed bogus value for the parameter used in splitting the resulting files, which has been corrected. * ds/commit-graph-set-size-mult: commit-graph: prefer default size_mult when given zero
2020-01-06Merge branch 'en/merge-recursive-oid-eq-simplify'Libravatar Junio C Hamano1-22/+11
Code cleanup. * en/merge-recursive-oid-eq-simplify: merge-recursive: remove unnecessary oid_eq function
2020-01-06Merge branch 'ds/sparse-list-in-cone-mode'Libravatar Junio C Hamano3-1/+80
"git sparse-checkout list" subcommand learned to give its output in a more concise form when the "cone" mode is in effect. * ds/sparse-list-in-cone-mode: sparse-checkout: document interactions with submodules sparse-checkout: list directories in cone mode
2020-01-06Merge branch 'js/mingw-loosen-overstrict-tree-entry-checks'Libravatar Junio C Hamano3-9/+9
An earlier update to Git for Windows declared that a tree object is invalid if it has a path component with backslash in it, which was overly strict, which has been corrected. The only protection the Windows users need is to prevent such path (or any path that their filesystem cannot check out) from entering the index. * js/mingw-loosen-overstrict-tree-entry-checks: mingw: only test index entries for backslashes, not tree entries
2020-01-06Merge branch 'pb/clarify-line-log-doc'Libravatar Junio C Hamano2-4/+12
Doc update. * pb/clarify-line-log-doc: doc: log, gitk: line-log arguments must exist in starting revision doc: log, gitk: document accepted line-log diff formats
2020-01-06Merge branch 'ew/packfile-syscall-optim'Libravatar Junio C Hamano1-14/+2
Code cleanup. * ew/packfile-syscall-optim: packfile: replace lseek+read with pread packfile: remove redundant fcntl F_GETFD/F_SETFD
2020-01-06doc: submodule: fix typo for command absorbgitdirsLibravatar Thomas Menzel1-1/+1
The sentence wants to talk about the superproject's possesive, not plural form. Signed-off-by: Thomas Menzel <dev@tomsit.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-06l10n: es: 2.25.0 round #1Libravatar Christopher Diaz Riveros1-2282/+2838
Signed-off-by: Christopher Diaz Riveros <christopher.diaz.riv@gmail.com>
2020-01-04am: document that Date: can appear as an in-body headerLibravatar Paul Menzel1-2/+2
Similar to "From:" and "Subject:" already mentioned in the documentation, "Date:" can also appear as an in-body header to override the value in the e-mail headers. Document it. Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-04gitweb: fix a couple spelling errors in commentsLibravatar Denis Ovsienko1-2/+2
Signed-off-by: Denis Ovsienko <denis@ovsienko.info> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-04multi-pack-index: correct configuration in documentationLibravatar Johannes Berg1-1/+1
It's core.multiPackIndex, not pack.multiIndex. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-04Documentation/git-sparse-checkout.txt: fix a typoLibravatar Taylor Blau1-1/+1
This typo was introduced in 94c0956b60 (sparse-checkout: create builtin with 'list' subcommand, 2019-11-21). Signed-off-by: Taylor Blau <me@ttaylorr.com> Acked-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-05Merge branch 'zs/open-current-file'Libravatar Pratyush Yadav1-5/+24
Allow opening the currently selected file in its default app by clicking on its name. * zs/open-current-file: git-gui: allow opening currently selected file in default app
2020-01-04l10n: sv.po: Update Swedish translation (4800t0f0u)Libravatar Peter Krefting1-2282/+2825
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2020-01-04Merge branch 'fr_v2.25.0_rnd1' of github.com:jnavila/git into masterLibravatar Jiang Xin1-2271/+2800
* 'fr_v2.25.0_rnd1' of github.com:jnavila/git: l10n: fr.po v2.25.0 rnd 1
2020-01-03l10n: fr.po v2.25.0 rnd 1Libravatar Jean-Noël Avila1-2271/+2800
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2020-01-03l10n: vi(4800t): Updated Vietnamese translation v2.25.0Libravatar Tran Ngoc Quan1-2273/+2839
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2020-01-02commit-graph: prefer default size_mult when given zeroLibravatar Derrick Stolee2-4/+4
In 50f26bd ("fetch: add fetch.writeCommitGraph config setting", 2019-09-02), the fetch builtin added the capability to write a commit-graph using the "--split" feature. This feature creates multiple commit-graph files, and those can merge based on a set of "split options" including a size multiple. The default size multiple is 2, which intends to provide a log_2 N depth of the commit-graph chain where N is the number of commits. However, I noticed during dogfooding that my commit-graph chains were becoming quite large when left only to builds by 'git fetch'. It turns out that in split_graph_merge_strategy(), we default the size_mult variable to 2 except we override it with the context's split_opts if they exist. In builtin/fetch.c, we create such a split_opts, but do not populate it with values. This problem is due to two failures: 1. It is unclear that we can add the flag COMMIT_GRAPH_WRITE_SPLIT with a NULL split_opts. 2. If we have a non-NULL split_opts, then we override the default values even if a zero value is given. Correct both of these issues. First, do not override size_mult when the options provide a zero value. Second, stop creating a split_opts in the fetch builtin. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-02mingw: only test index entries for backslashes, not tree entriesLibravatar Johannes Schindelin3-9/+9
During a clone of a repository that contained a file with a backslash in its name in the past, as of v2.24.1(2), Git for Windows prints errors like this: error: filename in tree entry contains backslash: '\' The idea is to prevent Git from even trying to write files with backslashes in their file names: while these characters are valid in file names on other platforms, on Windows it is interpreted as directory separator (which would obviously lead to ambiguities, e.g. when there is a file `a\b` and there is also a file `a/b`). Arguably, this is the wrong layer for that error: As long as the user never checks out the files whose names contain backslashes, there should not be any problem in the first place. So let's loosen the requirements: we now leave tree entries with backslashes in their file names alone, but we do require any entries that are added to the Git index to contain no backslashes on Windows. Note: just as before, the check is guarded by `core.protectNTFS` (to allow overriding the check by toggling that config setting), and it is _only_ performed on Windows, as the backslash is not a directory separator elsewhere, even when writing to NTFS-formatted volumes. An alternative approach would be to try to prevent creating files with backslashes in their file names. However, that comes with its own set of problems. For example, `git config -f C:\ProgramData\Git\config ...` is a very valid way to specify a custom config location, and we obviously do _not_ want to prevent that. Therefore, the approach chosen in this patch would appear to be better. This addresses https://github.com/git-for-windows/git/issues/2435 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-02Git 2.25-rc1Libravatar Junio C Hamano2-1/+14
Signed-off-by: Junio C Hamano <gitster@pobox.com>