Derrick Stolee writes:
> Updates in V5:
>
> * Fixed the error in PATCH 7 due to a missing line that existed in PATCH 8.
> Thanks, Josh Steadmon!
>
> * The 'repack' subcommand now computes the "expected size" of a pack instead
> of
> relying on the total size of the pack. This is actually real
"Derrick Stolee via GitGitGadget" writes:
> + int version = 0;
> ...
> + if (flags & COMMIT_GRAPH_VERSION_1)
> + version = 1;
> + if (!version)
> + version = 1;
> + if (version != 1) {
> + error(_("unsupported commit-graph version %d"),
> +
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> The write_commit_graph() and write_commit_graph_reachable() methods
> currently take two boolean parameters: 'append' and 'report_progress'.
> We will soon expand the possible options to send to these methods, so
> instead of c
Hi Junio,
On Thu, Apr 25, 2019 at 12:02:23PM +0900, Junio C Hamano wrote:
> Denton Liu writes:
>
> > In git-difftool, if the tool is called with --gui but `diff.guitool` is
> > not set, it falls back to `diff.tool`. Make git-mergetool also fallback
> > from `merge.guitool` to `merge.tool` if the
Vishal Verma writes:
> Add a note to the --squash option for git-merge to clarify its behavior
> with respect to --commit. When --squash is supplied, 'option_commit' is
> silently dropped. This can be surprising to a user who tries to override
> the no-commit behavior of squash using --commit exp
Sitaram Chamarty writes:
> I'm not in a position to use either of those on at least some of my
> systems, but meanwhile, I thought I'd ask this: what is the difference
> between this and "git show REF:PATH > PATH", in terms of side-effects.
>
> (I.e., any differences other than looking cleaner, n
On 24/04/2019 19.16, Junio C Hamano wrote:
> Piotr Krukowiecki writes:
>
>> I was familiar with "git checkout revision -- file".
>>
>> But it updates both working tree and index. I had some changes in
>> index (staged) and "git checkout HEAD -- file" silently overwritten
>> it. Well, probably
Denton Liu writes:
> @@ -734,8 +728,8 @@ int cmd_difftool(int argc, const char **argv, const char
> *prefix)
> if (use_gui_tool + !!difftool_cmd + !!extcmd > 1)
> die(_("--gui, --tool and --extcmd are mutually exclusive"));
>
> - if (use_gui_tool && diff_gui_tool && *di
Denton Liu writes:
> In git-difftool, if the tool is called with --gui but `diff.guitool` is
> not set, it falls back to `diff.tool`. Make git-mergetool also fallback
> from `merge.guitool` to `merge.tool` if the former is undefined.
>
> If git-difftool were to use `get_configured_mergetool`, it
Denton Liu writes:
> This change is not completely backwards compatible as there may be
> external users of git-mergetool--lib. However, only one user,
> git-diffall[1], was found from searching GitHub and Google. It seems
> very unlikely that there exists an external caller that would take into
Denton Liu writes:
> The output for commands used to be suppressed by redirecting both stdout
> and stderr to /dev/null. However, this should not happen since the
> output is useful for debugging and, without the "-v" flag, test scripts
> don't output anyway.
>
> Unsuppress the output by removing
Eric Sunshine writes:
> As a person who rarely, if ever, uses git-ls-files, I'm having trouble
> understanding why de-duping isn't the default behavior when the
> listing is otherwise not annotated (that is, when -t/-v/-f/--debug are
> not used).
It was because the implementor of the original wa
On Thu, Apr 25, 2019 at 01:24:56AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Thu, Apr 25 2019, Eugeniu Rosca wrote:
>
> > Hi Ævar,
> >
> > Thanks for the amazingly fast reply and for the useful feature (yay!).
> >
> > On Wed, Apr 24, 2019 at 05:37:10PM +0200, Ævar Arnfjörð Bjarmason wrote:
> >
Johannes Sixt writes:
> Furthermore, basing a decision on whether a file is executable won't
> work on Windows as intended. So, it is better to aim for an existence check.
That is a good point.
So it may be OK for "do we have a single hook script for this hook
name?" to say "no" when the path e
Ævar Arnfjörð Bjarmason writes:
>> I agree. I am a bit bothered by the fact that
>> `git log --oneline -Ux -G --pickaxe-raw-diff` outputs the
>> contents/patch of a commit. My expectation is that we have the
>> `log -p` knob for that?
>
> This is unrelated to --pickaxe-raw-diff, -U just implies -
On Thu, Apr 25, 2019 at 6:41 AM brian m. carlson
wrote:
>
> On Wed, Apr 24, 2019 at 04:49:54PM +0700, Duy Nguyen wrote:
> > Heh you beat me to it. My config-hooks branch [1] has not been updated
> > for half a year. I only skimmed through quickly so no useful comments,
> > but I went with a slight
On Wed, Apr 24, 2019 at 04:49:54PM +0700, Duy Nguyen wrote:
> Heh you beat me to it. My config-hooks branch [1] has not been updated
> for half a year. I only skimmed through quickly so no useful comments,
> but I went with a slightly different design, introducing
> for_each_hook() instead (see run
Hi,
brian m. carlson wrote:
> On Tue, Apr 23, 2019 at 07:34:38PM -0700, Jonathan Nieder wrote:
>> brian m. carlson wrote:
>>> I've talked with some people about this approach, and they've indicated
>>> they would prefer a configuration-based approach.
>>
>> I would, too, mostly because that reduc
On Thu, Apr 25 2019, Eugeniu Rosca wrote:
> Hi Ævar,
>
> Thanks for the amazingly fast reply and for the useful feature (yay!).
>
> On Wed, Apr 24, 2019 at 05:37:10PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Wed, Apr 24 2019, Ævar Arnfjörð Bjarmason wrote:
>>
>> > Add the ability for the -
On Tue, Apr 23, 2019 at 07:34:38PM -0700, Jonathan Nieder wrote:
> Hi,
>
> brian m. carlson wrote:
>
> > I've talked with some people about this approach, and they've indicated
> > they would prefer a configuration-based approach.
>
> I would, too, mostly because that reduces the problem of secu
On Wed, Apr 24, 2019 at 04:49:54PM +0700, Duy Nguyen wrote:
> Heh you beat me to it. My config-hooks branch [1] has not been updated
> for half a year. I only skimmed through quickly so no useful comments,
> but I went with a slightly different design, introducing
> for_each_hook() instead (see run
In git-difftool, if the tool is called with --gui but `diff.guitool` is
not set, it falls back to `diff.tool`. Make git-mergetool also fallback
from `merge.guitool` to `merge.tool` if the former is undefined.
If git-difftool were to use `get_configured_mergetool`, it would also
get the fallback be
In 063f2bdbf7 (mergetool: accept -g/--[no-]gui as arguments,
2018-10-24), mergetool was taught the --gui option but no tests were
added to ensure that it was working properly. Add a test to ensure that
it works.
Signed-off-by: Denton Liu
---
t/t7610-mergetool.sh | 22 ++
1 fi
The output for commands used to be suppressed by redirecting both stdout
and stderr to /dev/null. However, this should not happen since the
output is useful for debugging and, without the "-v" flag, test scripts
don't output anyway.
Unsuppress the output by removing the redirections to /dev/null.
In git-difftool.txt, it says
'git difftool' falls back to 'git mergetool' config variables when the
difftool equivalents have not been defined.
However, when `diff.guitool` is missing, it doesn't fallback to
anything. Make git-difftool fallback to `merge.guitool` when `diff.guitoo
In git-difftool, these options specify which tool to ultimately run. As
a result, they are logically conflicting. Explicitly disallow these
options from being used together.
Signed-off-by: Denton Liu
---
builtin/difftool.c | 3 +++
t/t7800-difftool.sh | 8
2 files changed, 11 insertion
Hi Ævar,
Thanks for the amazingly fast reply and for the useful feature (yay!).
On Wed, Apr 24, 2019 at 05:37:10PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Apr 24 2019, Ævar Arnfjörð Bjarmason wrote:
>
> > Add the ability for the -G pickaxe to search only through added
> > or removed l
In git-mergetool, the logic for getting which merge tool to use is
duplicated in git-mergetool--lib, except for the fact that it needs to
know whether the tool was guessed or not.
Rewrite `get_merge_tool` to return whether or not the tool was guessed
through the return code and make git-mergetool
Thanks for the review, Junio.
I hadn't thought about using the return code for `get_merge_tool` so
thanks for that suggestion. It should be a lot cleaner now.
---
Changes since v2:
* Unsuppress output in t7610
* Make `get_merge_tool` return 1 on guessed so we don't have to deal
with parsing '
On Wed, Apr 24, 2019 at 10:51:56AM +0100, Phillip Wood wrote:
> On 24/04/2019 01:49, brian m. carlson wrote:
> > Add support for multiple post-rewrite hooks, both for "git commit
> > --amend" and "git rebase".
> >
> > Additionally add support for multiple prepare-commit-msg hooks.
> >
> > Signed-
On Wed, Apr 24, 2019 at 11:27:59AM +0900, Junio C Hamano wrote:
> "brian m. carlson" writes:
> > diff --git a/run-command.c b/run-command.c
> > index 3449db319b..669af5ebc7 100644
> > --- a/run-command.c
> > +++ b/run-command.c
> > @@ -1308,58 +1308,137 @@ int async_with_fork(void)
> > #endif
> >
Add a note to the --squash option for git-merge to clarify its behavior
with respect to --commit. When --squash is supplied, 'option_commit' is
silently dropped. This can be surprising to a user who tries to override
the no-commit behavior of squash using --commit explicitly.
Signed-off-by: Vishal
Hi Michael -
I dug into the code a bit more and have some more comments below. Take
anything I say with a grain of salt; I'm still trying to understand how
it all works. =)
If you do have updates to your patch, see if you can make it apply onto
my branch at https://github.com/brho/git/co
Hi Piotr
On 24/04/2019 19:15, Piotr Krukowiecki wrote:
I think the new command is now on the 'pu' branch, but in a few
weeks hopefully it will appear on the 'next' branch.
Is it possible to get a Windows build?
Dscho maintains a relatively recent merge with pu at his
https://github.com/git-for
From: Derrick Stolee
Allow the commit-graph builtin to specify the file format version
using the '--version=' option. Specify the version exactly in
the verification tests as using a different version would change
the offsets used in those tests.
Signed-off-by: Derrick Stolee
---
Documentation
From: Derrick Stolee
The write_commit_graph() and write_commit_graph_reachable() methods
currently take two boolean parameters: 'append' and 'report_progress'.
We will soon expand the possible options to send to these methods, so
instead of complicating the parameter list, first simplify it.
Col
From: Derrick Stolee
The write_commit_graph() method uses die() to report failure and
exit when confronted with an unexpected condition. This use of
die() in a library function is incorrect and is now replaced by
error() statements and an int return type.
Now that we use 'goto cleanup' to jump t
From: Derrick Stolee
The commit-graph file format had some shortcomings which we now
correct:
1. The hash algorithm was determined by a single byte, instead
of the 4-byte format identifier.
2. There was no way to update the reachability index we used.
We currently only support gen
From: Derrick Stolee
In anticipation of a new commit-graph file format version, create
a flag for the write_commit_graph() and write_commit_graph_reachable()
methods to take a version number.
When there is no specified version, the implementation selects a
default value. Currently, the only vali
The commit-graph file format has some shortcomings that were discussed
on-list:
1. It doesn't use the 4-byte format ID from the_hash_algo.
2. There is no way to change the reachability index from generation numbers
to corrected commit date [1].
3. The unused byte in the
On Fri, Apr 19, 2019 at 09:28:32PM +0200, Ax Da wrote:
>
> We're working on Windows machines and have been experiencing issues with the
> current implementation of Git with config setting "core.ignorecase = true"
> (which is the default on Windows machines and repositories created on Windows
> m
Am 24.04.19 um 04:27 schrieb Junio C Hamano:
> "brian m. carlson" writes:
>> +static int has_hook(struct strbuf *path, int strip)
>> +{
>> +if (access(path->buf, X_OK) < 0) {
>
> Does ".git/post-commit" that is not an executable exist?
>
> It was perfectly fine for find_hook() to say "there
On 04/23, Matheus Tavares Bernardino wrote:
> On Thu, Apr 11, 2019 at 6:09 PM Thomas Gummerer wrote:
> >
> > On 04/10, Matheus Tavares Bernardino wrote:
> > > > > diff --git a/dir-iterator.h b/dir-iterator.h
> > > > > index 970793d07a..93646c3bea 100644
> > > > > --- a/dir-iterator.h
> > > > > +++
On Wed, Apr 24, 2019 at 1:10 AM Ævar Arnfjörð Bjarmason
wrote:
>
> On Wed, Apr 24 2019, brian m. carlson wrote:
>
> > Oftentimes, people want to use multiple of the same kind of hook. This
> > may be because software or a project they use requires a given hook, but
> > they would also like to have
On Wed, Apr 24, 2019 at 3:46 PM Junio C Hamano wrote:
>
> Piotr Krukowiecki writes:
>
> > I was familiar with "git checkout revision -- file".
> >
> > But it updates both working tree and index. I had some changes in
> > index (staged) and "git checkout HEAD -- file" silently overwritten
> > it.
On 04/17, Johannes Schindelin wrote:
> Hi Thomas,
>
> On Mon, 15 Apr 2019, Thomas Gummerer wrote:
> > I like declaring this a bug. We are after all parsing
> > machine-generated output, that does come from git (which is why I
> > neglected the NULL checking in the first place). If that second "@
On Wed, Apr 24, 2019 at 7:26 AM SZEDER Gábor wrote:
> On second thought, however, I'm not sure that such a '--dedup' option
> would be all that useful in the above cases. If the users have to
> adjust their 'git ls-files' invocation by specifying '--dedup' to
> avoid the same paths listed multipl
On Wed, Apr 24 2019, Ævar Arnfjörð Bjarmason wrote:
> Add the ability for the -G pickaxe to search only through added
> or removed lines in the diff, or even through an arbitrary amount of
> context lines when combined with -U.
>
> This has been requested[1][2] a few times in the past, and isn't
Refactor the code around processing an added (!one) or deleted (!two)
file in diff_grep, which is used by the -G option.
This makes a subsequent change where we'd like to munge the "one" or
"two" "ptr" smaller. While we're at it let's add an assert that "one"
and "two" can't both be false at the s
Add the ability for the -G pickaxe to search only through added
or removed lines in the diff, or even through an arbitrary amount of
context lines when combined with -U.
This has been requested[1][2] a few times in the past, and isn't
currently possible. Instead users need to do -G and then write
This implements --pickaxe-raw-diff as explained in 2/2. I based this
on "next" because Duy's in-flight diff option refactoring would have
conflicted with it.
Ævar Arnfjörð Bjarmason (2):
diffcore-pickaxe: refactor !one or !two case in diff_grep
diffcore-pickaxe: add --pickaxe-raw-diff for use
To repack with a non-zero batch-size, first sort all pack-files by
their modified time. Second, walk those pack-files from oldest
to newest, compute their expected size, and add the packs to a list
if they are smaller than the given batch-size. Stop when the total
expected size is at least the batc
The repack builtin deletes redundant pack-files and their
associated .idx, .promisor, .bitmap, and .keep files. We will want
to re-use this logic in the future for other types of repack, so
pull the logic into 'unlink_pack_path()' in packfile.c.
The 'ignore_keep' parameter is enabled for the use i
We will add new subcommands to the multi-pack-index, and that will
make the documentation a bit messier. Clean up the 'verb'
descriptions by renaming the concept to 'subcommand' and removing
the reference to the object directory.
Helped-by: Stefan Beller
Helped-by: Szeder Gábor
Signed-off-by: De
The 'git multi-pack-index expire' subcommand looks at the existing
mult-pack-index, counts the number of objects referenced in each
pack-file, deletes the pack-fils with no referenced objects, and
rewrites the multi-pack-index to no longer reference those packs.
Refactor the write_midx_file() meth
In an environment where the multi-pack-index is useful, it is due
to many pack-files and an inability to repack the object store
into a single pack-file. However, it is likely that many of these
pack-files are rather small, and could be repacked into a slightly
larger pack-file without too much eff
During development of the multi-pack-index expire subcommand, a
version went out that improperly computed the pack order if a new
pack was introduced while other packs were being removed. Part of
the subtlety of the bug involved the new pack being placed before
other packs that already existed in t
The 'git multi-pack-index expire' subcommand may delete packs that
are not needed from the perspective of the multi-pack-index. If
a pack has a .keep file, then we should not delete that pack. Add
a test that ensures we preserve a pack that would otherwise be
expired. First, create a new pack that
The multi-pack-index provides a fast way to find an object among a large list
of pack-files. It stores a single pack-reference for each object id, so
duplicate objects are ignored. Among a list of pack-files storing the same
object, the most-recently modified one is used.
Create new subcommands fo
The 'git multi-pack-index repack' command can take a batch size of
zero, which creates a new pack-file containing all objects in the
multi-pack-index. The first 'repack' command will create one new
pack-file, and an 'expire' command after that will delete the old
pack-files, as they no longer conta
In anticipation of the expire subcommand, refactor the way we sort
the packfiles by name. This will greatly simplify our approach to
dropping expired packs from the list.
First, create 'struct pack_info' to replace 'struct pack_pair'.
This struct contains the necessary information about a pack,
in
Before writing the multi-pack-index, we compute the length of the
pack-index names concatenated together. This forms the data in the
pack name chunk, and we precompute it to compute chunk offsets.
The value is also modified to fit alignment needs.
Previously, this computation was coupled with addi
The multi-pack-index tracks objects in a collection of pack-files.
Only one copy of each object is indexed, using the modified time
of the pack-files to determine tie-breakers. It is possible to
have a pack-file with no referenced objects because all objects
have a duplicate in a newer pack-file.
> From: Junio C Hamano
> "CHIGOT, CLEMENT" writes:
>
> > On AIX, access(X_OK) may success when run under root even if the
>
> s/success/succeed/;
>
> Also perhaps s/under/as/.
>
> > execution isn't possible. This comes from the POSIX specifications
>
> s/comes from/behaviour is allowed by/;
Piotr Krukowiecki writes:
> I was familiar with "git checkout revision -- file".
>
> But it updates both working tree and index. I had some changes in
> index (staged) and "git checkout HEAD -- file" silently overwritten
> it. Well, probably my mistake, it's documented.
We'd invite you to live o
"CHIGOT, CLEMENT" writes:
> On AIX, access(X_OK) may success when run under root even if the
s/success/succeed/;
Also perhaps s/under/as/.
> execution isn't possible. This comes from the POSIX specifications
s/comes from/behaviour is allowed by/; I agree with you that AIX
behaviour is subop
Hi,
what is the standard/recommended way for updating a file to given version?
I was familiar with "git checkout revision -- file".
But it updates both working tree and index. I had some changes in
index (staged) and "git checkout HEAD -- file" silently overwritten
it. Well, probably my mistake,
On AIX, access(X_OK) may success when run under root even if the
execution isn't possible. This comes from the POSIX specifications
which say:
"... for a process with appropriate privileges, an implementation
may indicate success for X_OK even if execute permission is not
granted to any user."
T
On Wed, Apr 24, 2019 at 10:03:37AM +0900, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > I remember being rather puzzled by 'git ls-files' listing the same
> > file more than once depending on its --options when I was working on
> > the git-aware path completion parts of our completion script
On Wed, Apr 24, 2019 at 07:36:34PM +0900, Junio C Hamano wrote:
> if git merge-base --is-ancestor master "$DEV_BRANCH"
> then
> echo "master is an ancestor of $DEV_BRANCH"
> else
> echo "master has commits not in $DEV_BRANCH"
> git --no-pa
Dear Junio,
Junio C Hamano (gits...@pobox.com) 2019-04-24:
> if cs/topic branch does not exist, of if the branch
> does not contain 'master', the command will show "here are the
> branches that match the criteria you gave me" by giving no lines in
> its standard output, and exits with 0 to signal
Dear Junio,
Junio C Hamano (gits...@pobox.com) 2019-04-24:
> This invocation is not in line with how "git branch" subcommand is
> designed to work.
This is fair. I completely accept a "you're wielding it wrong" answer!
However, your explanation sounds to me like that invocation is exactly
in line
Junio C Hamano writes:
> The list mode ...
> ... can
> also limit the branches whose tip commits can reach a named commit
> with the "--contains".
>
> $ DEV_BRANCH=cs/topic
> $ git branch --contains master "$DEV_BRANCH"
>
> asks the subcommand to show only the branches that can reach
a...@xkqr.org (Christoffer Stjernlöf) writes:
> A common use case of git branch – for me – is to use it to test whether
> a particular branch satisfies some conditions. A recent example is this:
>
> if ! git branch "$DEV_BRANCH" --contains master; then
This invocation is not in line with how
Hello git community,
In the context of [1], I would like to find all Linux commits which
replaced:
'devm_request_threaded_irq(* IRQF_SHARED *)'
by:
'devm_request_threaded_irq(* IRQF_ONESHOT *)'
Actually, I would be happy with a much lower degree of precision, e.g.
finding commits
Dear Sirs/Madams,
A common use case of git branch – for me – is to use it to test whether
a particular branch satisfies some conditions. A recent example is this:
if ! git branch "$DEV_BRANCH" --contains master; then
echo "The development branch ($DEV_BRANCH) is not up to date"
On 24/04/2019 09:10, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Apr 24 2019, brian m. carlson wrote:
>
>> Oftentimes, people want to use multiple of the same kind of hook. This
>> may be because software or a project they use requires a given hook, but
>> they would also like to have a custom hoo
On 24/04/2019 01:49, brian m. carlson wrote:
> Add support for multiple post-rewrite hooks, both for "git commit
> --amend" and "git rebase".
>
> Additionally add support for multiple prepare-commit-msg hooks.
>
> Signed-off-by: brian m. carlson
> ---
> builtin/am.c | 28 +
On Wed, Apr 24, 2019 at 7:54 AM brian m. carlson
wrote:
>
> Oftentimes, people want to use multiple of the same kind of hook. This
> may be because software or a project they use requires a given hook, but
> they would also like to have a custom hook, or because they're using
> multiple pieces of
On Fri, Mar 08 2019, Jonathan Tan wrote:
> One relatively significant change: someone pointed out that the issue fixed by
> 50d3413740 ("http: make redirects more obvious", 2016-12-06) could also
> occur here, so I have changed it so that the server is required to send
> the packfile's hash alon
On Wed, Apr 24 2019, Jonathan Nieder wrote:
> Hi,
>
> brian m. carlson wrote:
>
>> I've talked with some people about this approach, and they've indicated
>> they would prefer a configuration-based approach.
>
> I would, too, mostly because that reduces the problem of securing
> hooks to securin
On Wed, Apr 24 2019, brian m. carlson wrote:
> On Wed, Apr 24, 2019 at 11:09:10AM +0900, Junio C Hamano wrote:
>> "brian m. carlson" writes:
>>
>> > To preserve backwards compatibility, we don't run the hooks in the ".d"
>> > directory if the single file is a valid hook (i.e. it exists and is
>
On Wed, Apr 24 2019, brian m. carlson wrote:
> Oftentimes, people want to use multiple of the same kind of hook. This
> may be because software or a project they use requires a given hook, but
> they would also like to have a custom hook, or because they're using
> multiple pieces of software th
From: Junio C Hamano on behalf of Junio C Hamano
> "CHIGOT, CLEMENT" writes:
> > From: Junio C Hamano on behalf of Junio C Hamano
> >
> >> > On some OSes like AIX, access with X_OK is always true if launched under
> >> > root.
> >>
> >> That may be the case, but you'd need to describe why it
On Wed, Apr 24 2019, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> On Wed, Apr 24 2019, Jonathan Nieder wrote:
>>> Jeff King wrote:
On Fri, Mar 08, 2019 at 01:55:17PM -0800, Jonathan Tan wrote:
>
> +If the 'packfile-uris' feature is advertised, the following argument
>
On Wed, Apr 24 2019, Jonathan Nieder wrote:
> brian m. carlson wrote:
brian: I'm very interested in this. I barked up this tree before almost
exactly 3 years ago:
https://public-inbox.org/git/cacbzzx6j6q2dun_z-pnent1u714dvnpfbrl_pieqylmczlu...@mail.gmail.com/
https://public-inbox.org
Denton Liu writes:
> +get_merge_tool_guessed () {
> + is_guessed=false
> # Check if a merge tool has been configured
> - merge_tool=$(get_configured_merge_tool)
> + merge_tool=$(get_configured_merge_tool $GIT_MERGETOOL_GUI)
> # Try to guess an appropriate merge tool if no
Denton Liu writes:
> In 063f2bdbf7 (mergetool: accept -g/--[no-]gui as arguments,
> 2018-10-24), mergetool was taught the --gui option but no tests were
> added to ensure that it was working properly. Add a test to ensure that
> it works.
>
> Signed-off-by: Denton Liu
> ---
> t/t7610-mergetool.
88 matches
Mail list logo
