summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-02-16git-rebase.txt: add more details about behavioral differences of backendsLibravatar Elijah Newren1-5/+80
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16rebase: allow more types of rebases to fast-forwardLibravatar Elijah Newren2-4/+16
In the past, we dis-allowed rebases using the interactive backend from performing a fast-forward to short-circuit the rebase operation. This made sense for explicitly interactive rebases and some implicitly interactive rebases, but certainly became overly stringent when the merge backend was re-implemented via the interactive backend. Just as the am-based rebase has always had to disable the fast-forward based on a variety of conditions or flags (e.g. --signoff, --whitespace, etc.), we need to do the same but now with a few more options. However, continuing to use REBASE_FORCE for tracking this is problematic because the interactive backend used it for a different purpose. (When REBASE_FORCE wasn't set, the interactive backend would not fast-forward the whole series but would fast-forward individual "pick" commits at the beginning of the todo list, and then a squash or something would cause it to start generating new commits.) So, introduce a new allow_preemptive_ff flag contained within cmd_rebase() and use it to track whether we are going to allow a pre-emptive fast-forward that short-circuits the whole rebase. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16t3432: make these tests work with either am or merge backendsLibravatar Elijah Newren1-26/+22
t3432 had several stress tests for can_fast_forward(), whose intent was to ensure we were using the optimization of just fast forwarding when possible. However, these tests verified that fast forwards had happened based on the output that rebase printed to the terminal. We can instead test more directly that we actually fast-forwarded by checking the reflog, which also has the side effect of making the tests applicable for the merge/interactive backend. This change does lose the distinction between "noop" and "noop-force", but as stated in commit c9efc216830f ("t3432: test for --no-ff's interaction with fast-forward", 2019-08-27) which introduced that distinction: "These tests aren't supposed to endorse the status quo, just test for what we're currently doing.". This change does not actually run these tests with the merge/interactive backend; instead this is just a preparatory commit. A subsequent commit which fixes can_fast_forward() to work with that backend will then also change t3432 to add tests of that backend as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16rebase: fix handling of restrict_revisionLibravatar Elijah Newren2-3/+21
restrict_revision in the original shell script was an excluded revision range. It is also treated that way by the am-backend. In the conversion from shell to C (see commit 6ab54d17be3f ("rebase -i: implement the logic to initialize $revisions in C", 2018-08-28)), the interactive-backend accidentally treated it as a positive revision rather than a negated one. This was missed as there were no tests in the testsuite that tested an interactive rebase with fork-point behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16rebase: make sure to pass along the quiet flag to the sequencerLibravatar Elijah Newren2-2/+9
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16rebase, sequencer: remove the broken GIT_QUIET handlingLibravatar Elijah Newren2-8/+4
The GIT_QUIET environment variable was used to signal the non-am backends that the rebase should perform quietly. The preserve-merges backend does not make use of the quiet flag anywhere (other than to write out its state whenever it writes state), and this mechanism was broken in the conversion from shell to C. Since this environment variable was specifically designed for scripts and the only backend that would still use it is no longer a script, just gut this code. A subsequent commit will fix --quiet for the interactive/merge backend in a different way. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16t3406: simplify an already simple testLibravatar Elijah Newren1-5/+2
When the merge backend was re-implemented on top of the interactive backend, the output of rebase --merge changed a little. This change allowed this test to be simplified, though it wasn't noticed until now. Simplify the testcase a little. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16rebase (interactive-backend): fix handling of commits that become emptyLibravatar Elijah Newren6-23/+183
As established in the previous commit and commit b00bf1c9a8dd (git-rebase: make --allow-empty-message the default, 2018-06-27), the behavior for rebase with different backends in various edge or corner cases is often more happenstance than design. This commit addresses another such corner case: commits which "become empty". A careful reader may note that there are two types of commits which would become empty due to a rebase: * [clean cherry-pick] Commits which are clean cherry-picks of upstream commits, as determined by `git log --cherry-mark ...`. Re-applying these commits would result in an empty set of changes and a duplicative commit message; i.e. these are commits that have "already been applied" upstream. * [become empty] Commits which are not empty to start, are not clean cherry-picks of upstream commits, but which still become empty after being rebased. This happens e.g. when a commit has changes which are a strict subset of the changes in an upstream commit, or when the changes of a commit can be found spread across or among several upstream commits. Clearly, in both cases the changes in the commit in question are found upstream already, but the commit message may not be in the latter case. When cherry-mark can determine a commit is already upstream, then because of how cherry-mark works this means the upstream commit message was about the *exact* same set of changes. Thus, the commit messages can be assumed to be fully interchangeable (and are in fact likely to be completely identical). As such, the clean cherry-pick case represents a case when there is no information to be gained by keeping the extra commit around. All rebase types have always dropped these commits, and no one to my knowledge has ever requested that we do otherwise. For many of the become empty cases (and likely even most), we will also be able to drop the commit without loss of information -- but this isn't quite always the case. Since these commits represent cases that were not clean cherry-picks, there is no upstream commit message explaining the same set of changes. Projects with good commit message hygiene will likely have the explanation from our commit message contained within or spread among the relevant upstream commits, but not all projects run that way. As such, the commit message of the commit being rebased may have reasoning that suggests additional changes that should be made to adapt to the new base, or it may have information that someone wants to add as a note to another commit, or perhaps someone even wants to create an empty commit with the commit message as-is. Junio commented on the "become-empty" types of commits as follows[1]: WRT a change that ends up being empty (as opposed to a change that is empty from the beginning), I'd think that the current behaviour is desireable one. "am" based rebase is solely to transplant an existing history and want to stop much less than "interactive" one whose purpose is to polish a series before making it publishable, and asking for confirmation ("this has become empty--do you want to drop it?") is more appropriate from the workflow point of view. [1] https://lore.kernel.org/git/xmqqfu1fswdh.fsf@gitster-ct.c.googlers.com/ I would simply add that his arguments for "am"-based rebases actually apply to all non-explicitly-interactive rebases. Also, since we are stating that different cases should have different defaults, it may be worth providing a flag to allow users to select which behavior they want for these commits. Introduce a new command line flag for selecting the desired behavior: --empty={drop,keep,ask} with the definitions: drop: drop commits which become empty keep: keep commits which become empty ask: provide the user a chance to interact and pick what to do with commits which become empty on a case-by-case basis In line with Junio's suggestion, if the --empty flag is not specified, pick defaults as follows: explicitly interactive: ask otherwise: drop Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16rebase (interactive-backend): make --keep-empty the defaultLibravatar Elijah Newren9-55/+126
Different rebase backends have different treatment for commits which start empty (i.e. have no changes relative to their parent), and the --keep-empty option was added at some point to allow adjusting behavior. The handling of commits which start empty is actually quite similar to commit b00bf1c9a8dd (git-rebase: make --allow-empty-message the default, 2018-06-27), which pointed out that the behavior for various backends is often more happenstance than design. The specific change made in that commit is actually quite relevant as well and much of the logic there directly applies here. It makes a lot of sense in 'git commit' to error out on the creation of empty commits, unless an override flag is provided. However, once someone determines that there is a rare case that merits using the manual override to create such a commit, it is somewhere between annoying and harmful to have to take extra steps to keep such intentional commits around. Granted, empty commits are quite rare, which is why handling of them doesn't get considered much and folks tend to defer to existing (accidental) behavior and assume there was a reason for it, leading them to just add flags (--keep-empty in this case) that allow them to override the bad defaults. Fix the interactive backend so that --keep-empty is the default, much like we did with --allow-empty-message. The am backend should also be fixed to have --keep-empty semantics for commits that start empty, but that is not included in this patch other than a testcase documenting the failure. Note that there was one test in t3421 which appears to have been written expecting --keep-empty to not be the default as correct behavior. This test was introduced in commit 00b8be5a4d38 ("add tests for rebasing of empty commits", 2013-06-06), which was part of a series focusing on rebase topology and which had an interesting original cover letter at https://lore.kernel.org/git/1347949878-12578-1-git-send-email-martinvonz@gmail.com/ which noted Your input especially appreciated on whether you agree with the intent of the test cases. and then went into a long example about how one of the many tests added had several questions about whether it was correct. As such, I believe most the tests in that series were about testing rebase topology with as many different flags as possible and were not trying to state in general how those flags should behave otherwise. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-17t3404: directly test the behavior of interestLibravatar Elijah Newren1-3/+4
t3404.3 is a simple test added by commit d078c3910689 ("t3404: todo list with commented-out commands only aborts", 2018-08-10) which was designed to test a todo list that only contained commented-out commands. There were two problems with this test: (1) its title did not reflect the purpose of the test, and (2) it tested the desired behavior through a side-effect of other functionality instead of directly testing the desired behavior discussed in the commit message. Modify the test to directly test the desired behavior and update the test title. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-17git-rebase.txt: update description of --allow-empty-messageLibravatar Elijah Newren2-8/+11
Commit b00bf1c9a8dd ("git-rebase: make --allow-empty-message the default", 2018-06-27) made --allow-empty-message the default and thus turned --allow-empty-message into a no-op but did not update the documentation to reflect this. Update the documentation now, and hide the option from the normal -h output since it is not useful. Signed-off-by: Elijah Newren <newren@gmail.com> 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