From: Johannes Schindelin
We already called that function at this point, and stored the result in
the `path` variable. We might just as well use it ;-)
Signed-off-by: Johannes Schindelin
---
builtin/rebase.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/rebase.c
From: Johannes Schindelin
When `git stash apply ` sees an argument that consists only of
digits, it tries to be smart and interpret it as `stash@{}`.
Unfortunately, an all-digit hash (which is unlikely but still possible)
is therefore misinterpreted as `stash@{}` reflog.
To prevent that from
Gábor reported in
https://public-inbox.org/git/20181019124625.gb30...@szeder.dev/ that
t5520-pull.sh fails from time to time, and Alban root-caused this to a bug
in the built-in rebase.
This patch series fixes that, and while at it also fixes an oversight of
yours truly when helping Pratik with
From: Johannes Schindelin
`git repack` can drop unreachable commits without further warning,
making the corresponding entries in `.git/shallow` invalid, which causes
serious problems when deepening the branches.
One scenario where unreachable commits are dropped by `git repack` is
when a `git
From: Johannes Schindelin
A `git fetch --prune` can turn previously-reachable objects unreachable,
even commits that are in the `shallow` list. A subsequent `git repack
-ad` will then unceremoniously drop those unreachable commits, and the
`shallow` list will become stale. This means that when
From: Johannes Schindelin
The `prune_shallow()` function wants a full reachability check to be
completed before it goes to work, to ensure that all unreachable entries
are removed from the shallow file.
However, in the upcoming patch we do not even want to go that far. We
really only need to
Under certain circumstances, commits that were reachable can be made
unreachable, e.g. via git fetch --prune. These commits might have been
packed already, in which case git repack -adlf will just drop them without
giving them the usual grace period before an eventual git prune (via git gc)
prunes
From: Johannes Schindelin
In 9ac3f0e5b3e4 (pack-objects: fix performance issues on packing large
deltas, 2018-07-22), a mutex was introduced that is used to guard the
call to set the delta size. This commit even added code to initialize
it, but at an incorrect spot: in `init_threaded_search()`,
From: Johannes Schindelin
There is a problem in the way 9ac3f0e5b3e4 (pack-objects: fix
performance issues on packing large deltas, 2018-07-22) initializes that
mutex in the `packing_data` struct. The problem manifests in a
segmentation fault on Windows, when a mutex (AKA critical section) is
From: Johannes Schindelin
Signed-off-by: Johannes Schindelin
---
pack-objects.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pack-objects.h b/pack-objects.h
index 2ca39cfcfe..86ee93feb4 100644
--- a/pack-objects.h
+++ b/pack-objects.h
@@ -377,7 +377,7 @@ static inline
From: Johannes Schindelin
As of cURL v7.60.0, the Secure Channel backend can use the certificate
bundle provided via `http.sslCAInfo`, but that would override the
Windows Certificate Store. Since this is not desirable by default, let's
tell Git to not ask cURL to use that bundle by default when
From: Johannes Schindelin
As of version 7.56.0, curl supports being compiled with multiple SSL
backends.
This patch adds the Git side of that feature: by setting http.sslBackend
to "openssl" or "schannel", Git for Windows can now choose the SSL
backend at runtime.
This comes in handy on
This topic branch brings support for choosing cURL's SSL backend (a feature
developed in Git for Windows' context) at runtime via http.sslBackend, and
two more patches that are related (and only of interest for Windows users).
Brendan Forster (1):
http: add support for disabling SSL revocation
From: Johannes Schindelin
Sometimes, failures in a test case are actually caused by issues in
earlier test cases.
To make it easier to see those issues, let's attach the output from
before the failing test case (i.e. stdout/stderr since the previous
failing test case, or the start of the test
From: Johannes Schindelin
Just like so many other OSS projects, we now also have a build badge.
Signed-off-by: Johannes Schindelin
---
README.md | 2 ++
1 file changed, 2 insertions(+)
diff --git a/README.md b/README.md
index f920a42fad..bf4780c22d 100644
--- a/README.md
+++ b/README.md
@@
From: Johannes Schindelin
In the next commit, we want to teach Git's test suite to optionally
output test results in JUnit-style .xml files. These files contain
information about the time spent. So we need a way to measure time.
While we could use `date +%s` for that, this will give us only
From: Johannes Schindelin
The JUnit XML format lends itself to be presented in a powerful UI,
where you can drill down to the information you are interested in very
quickly.
For test failures, this usually means that you want to see the detailed
trace of the failing tests.
With Travis CI, we
From: Johannes Schindelin
When building a PR, TRAVIS_BRANCH refers to the *target branch*.
Therefore, if a PR targets `master`, and `master` happened to be tagged,
we skipped the build by mistake.
Fix this by using TRAVIS_PULL_REQUEST_BRANCH (i.e. the *source branch*)
when available, falling
For a long time already, we have Git's source code continuously tested via
Travis CI, see e.g. https://travis-ci.org/git/git/builds/421738884. It has
served us well, and more and more developers actually pay attention and
benefit from the testing this gives us.
It is also an invaluable tool for
From: Johannes Schindelin
When running the p4 daemon or `git daemon`, we want to kill it at the
end of the test script.
So far, we do this "manually".
However, in the next few commits we want to teach the test suite to
optionally re-run scripts with different options, therefore we will have
to
From: Johannes Schindelin
This commit adds an azure-pipelines.yml file which is Azure DevOps'
equivalent to Travis CI's .travis.yml.
To make things a bit easier to understand, we refrain from using the
`matrix` feature here because (while it is powerful) it can be a bit
confusing to users who
From: Johannes Schindelin
This patch introduces a conditional arm that defines some environment
variables and a function that displays the URL given the job id (to
identify previous runs for known-good trees).
Signed-off-by: Johannes Schindelin
---
ci/lib.sh | 23 +++
1
From: Johannes Schindelin
This should be more reliable than the current method, and prepares the
test suite for a consistent way to clean up before re-running the tests
with different options.
Signed-off-by: Johannes Schindelin
---
t/lib-git-p4.sh| 10 +-
From: Johannes Schindelin
This will come in handy when publishing the results of Git's test suite
during an automated Azure DevOps run.
Signed-off-by: Johannes Schindelin
---
t/.gitignore | 1 +
t/test-lib.sh | 98 +++
2 files changed, 99
From: Johannes Schindelin
The name is hard-coded to reflect that we use Travis CI for continuous
testing.
In the next commits, we will extend this to be able use Azure DevOps,
too.
So let's adjust the name to make it more generic.
Signed-off-by: Johannes Schindelin
---
From: Johannes Schindelin
This makes use of the just-introduced consistent way to specify that a
long-running process needs to be terminated at the end of a test script
run.
Signed-off-by: Johannes Schindelin
---
t/interop/i5500-git-daemon.sh | 1 -
t/lib-git-daemon.sh | 3 +--
From: Johannes Schindelin
The upcoming patches will allow building git.git via Azure Pipelines
(i.e. Azure DevOps' Continuous Integration), where variable names and
URLs look a bit different than in Travis CI.
Signed-off-by: Johannes Schindelin
---
ci/install-dependencies.sh | 3 ++-
From: Johannes Schindelin
When a user is registered in a Windows domain, it is really easy to
obtain the email address. So let's do that.
Suggested by Lutz Roeder.
Signed-off-by: Johannes Schindelin
---
compat/mingw.c| 5 +
compat/mingw.h| 2 ++
git-compat-util.h | 4
From: Johannes Schindelin
We do have the excellent GetUserInfoEx() function to obtain more
detailed information of the current user (if the user is part of a
Windows domain); Let's use it.
Suggested by Lutz Roeder.
To avoid the cost of loading Secur32.dll (even lazily, loading DLLs
takes a
On Linux, we use the gecos information to come up with a sensible user
name/email. On Windows, there is no gecos. But there is something
comparable, and with these patches, we use it.
This has been carried in Git for Windows for three years, and is considered
mature.
Johannes Schindelin (3):
From: Johannes Schindelin
Signed-off-by: Johannes Schindelin
---
compat/mingw.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 18caf21969..597781b370 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@
From: Johannes Schindelin
We had not documented previously what happens when an `exec` command in
an interactive rebase fails. Now we do.
Signed-off-by: Johannes Schindelin
---
Documentation/git-rebase.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Stefan asked a while back
[https://public-inbox.org/git/20180118183618.39853-3-sbel...@google.com/]
for a todo command in interactive rebases that would essentially perform the
"stop" part of the edit command, but without the "pick" part: interrupt the
interactive rebase, with exit code 0,
From: Johannes Schindelin
The 'edit' command can be used to cherry-pick a commit and then
immediately drop out of the interactive rebase, with exit code 0, to let
the user amend the commit, or test it, or look around.
Sometimes this functionality would come in handy *without*
cherry-picking a
From: Johannes Schindelin
The 'edit' command can be used to cherry-pick a commit and then
immediately drop out of the interactive rebase, with exit code 0, to let
the user amend the commit, or test it, or look around.
Sometimes this functionality would come in handy *without*
cherry-picking a
From: Johannes Schindelin
We had not documented previously what happens when an `exec` command in
an interactive rebase fails. Now we do.
Signed-off-by: Johannes Schindelin
---
Documentation/git-rebase.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Stefan asked a while back
[https://public-inbox.org/git/20180118183618.39853-3-sbel...@google.com/]
for a todo command in interactive rebases that would essentially perform the
"stop" part of the edit command, but without the "pick" part: interrupt the
interactive rebase, with exit code 0,
The builtin rebase and the builtin interactive rebase have been developed
independently, on purpose: Google Summer of Code rules specifically state
that students have to work on independent projects, they cannot collaborate
on the same project.
The reason is probably the very fine tradition in
From: Johannes Schindelin
The builtin rebase and the builtin interactive rebase have been
developed independently, on purpose: Google Summer of Code rules
specifically state that students have to work on independent projects,
they cannot collaborate on the same project.
One fallout is that the
From: Johannes Schindelin
Previously, we only ever declared a target Windows version if compiling
with Visual C.
Which meant that we were relying on the MinGW headers to guess which
Windows version we want to target...
Let's be explicit about it, in particular because we actually want to
bump
From: Johannes Schindelin
Windows Vista (and later) actually have a working poll(), but we still
cannot use it because it only works on sockets.
So let's detect when we are targeting Windows Vista and undefine those
constants, and define `pollfd` so that we can declare our own pollfd
struct.
I noticed that a recent GitGitGadget build failed in the Windows phase, with
compat/poll/poll.h problems all over the place.
Turns out that this is caused by the recent upgrade of the mingw-w64 headers
and crt files (7.0.0.5233.e0c09544 -> 7.0.0.5245.edf66197, which I assume
now enforces Vista as
From: Johannes Schindelin
Quite some time ago, a last plea to the XP users out there who want to
see Windows XP support in Git for Windows, asking them to get engaged
and help, vanished into the depths of the universe.
We tried for a long time to play nice with the last remaining XP users
who
From: Johannes Schindelin
The 'edit' command can be used to cherry-pick a commit and then
immediately drop out of the interactive rebase, with exit code 0, to let
the user amend the commit, or test it, or look around.
Sometimes this functionality would come in handy *without*
cherry-picking a
Stefan asked a while back
[https://public-inbox.org/git/20180118183618.39853-3-sbel...@google.com/]
for a todo command in interactive rebases that would essentially perform the
"stop" part of the edit command, but without the "pick" part: interrupt the
interactive rebase, with exit code 0,
This patch series completes the support for all rebase options in the
builtin rebase, e.g. --signoff, rerere-autoupdate, etc.
It is based on pk/rebase -in-c-3-acts.
Changes since v1:
* Added the forgotten -k short option for --keep-empty (and verified that
no other short options were
This patch series provides the bare minimum to run more than just the
trivial rebase (i.e. git rebase ): it implements the most common
options such as --onto.
It is based the latest iteration of pk/rebase-in-c.
This is the second patch series that brings us more closer to a builtin "git
rebase".
From: Johannes Schindelin
Sometimes, failures in a test case are actually caused by issues in
earlier test cases.
To make it easier to see those issues, let's attach the output from
before the failing test case (i.e. stdout/stderr since the previous
failing test case, or the start of the test
From: Johannes Schindelin
In the next commit, we want to teach Git's test suite to optionally
output test results in JUnit-style .xml files. These files contain
information about the time spent. So we need a way to measure time.
While we could use `date +%s` for that, this will give us only
From: Johannes Schindelin
Just like so many other OSS projects, we now also have a build badge.
Signed-off-by: Johannes Schindelin
---
README.md | 2 ++
1 file changed, 2 insertions(+)
diff --git a/README.md b/README.md
index f920a42fad..f260e78042 100644
--- a/README.md
+++ b/README.md
@@
From: Johannes Schindelin
The upcoming patches will allow building git.git via VSTS CI, where
variable names and URLs look a bit different than in Travis CI.
Signed-off-by: Johannes Schindelin
---
ci/install-dependencies.sh | 3 ++-
ci/lib.sh | 44
From: Johannes Schindelin
The JUnit XML format lends itself to be presented in a powerful UI,
where you can drill down to the information you are interested in very
quickly.
For test failures, this usually means that you want to see the detailed
trace of the failing tests.
With Travis CI, we
From: Johannes Schindelin
This commit adds a .vsts-ci.yml which is Visual Studio Team Services'
equivalent to Travis CI's .travis.yml.
To make things a bit easier to understand, we refrain from using the
`matrix` feature here because (while it is powerful) it can be a bit
confusing to users who
From: Johannes Schindelin
This will come in handy when publishing the results of Git's test suite
during an automated VSTS CI run.
Signed-off-by: Johannes Schindelin
---
t/.gitignore | 1 +
t/test-lib.sh | 98 +++
2 files changed, 99
From: Johannes Schindelin
The name is hard-coded to reflect that we use Travis CI for continuous
testing.
In the next commits, we will extend this to be able use Visual Studio
Team Services, too.
So let's adjust the name to make it more generic.
Signed-off-by: Johannes Schindelin
---
From: Johannes Schindelin
This patch introduces a conditional arm that defines some environment
variables and a function that displays the URL given the job id (to
identify previous runs for known-good trees).
Signed-off-by: Johannes Schindelin
---
ci/lib.sh | 23 +++
1
For a long time already, we have Git's source code continuously tested via
Travis CI, see e.g. https://travis-ci.org/git/git/builds/421738884. It has
served us well, and more and more developers actually pay attention and
benefit from the testing this gives us.
It is also an invaluable tool for
'tis bug fix season! I admit, though, that this bug might be a bit too off
the trodden path to merit fast-tracking into v2.19.0.
While pairing with Jameson Miller to rebase Git for Windows to v2.19.0-rc1,
we had to fix a couple of commits which had somehow lost their proper
authorship (probably
From: Johannes Schindelin
When an interactive rebase was stopped at the end of a fixup/squash
chain, the user might have edited the commit manually before continuing
(with either `git rebase --skip` or `git rebase --continue`, it does not
really matter which).
We need to be very careful to wrap
From: Johannes Schindelin
The `git commit --squash` command can be used not only to amend commit
messages and changes, but also to record notes for an upcoming rebase.
For example, when the author information of a given commit is incorrect,
a user might call `git commit --allow-empty -m "Fix
From: Johannes Schindelin
The builtin rebase and the builtin interactive rebase have been
developed independently, on purpose: Google Summer of Code rules
specifically state that students have to work on independent projects,
they cannot collaborate on the same project.
One fallout is that the
The builtin rebase and the builtin interactive rebase have been developed
independently, on purpose: Google Summer of Code rules specifically state
that students have to work on independent projects, they cannot collaborate
on the same project.
The reason is probably the very fine tradition in
While trying to run the build & test with NO_PERL, I noticed that t2024 had
a failing test case. This patch works around that failing test case by
skipping it when we know that the error message looks different than that
test case would expect.
Changes since v1 (which did not make it to the list
From: Johannes Schindelin
A recently-added test case tries to verify that the output of `checkout
-p` contains a certain piece of advice.
But if Git was built without Perl and therefore lacks support for `git
add -i`, the error output contains the hint that `-p` is not even
available instead.
From: Johannes Schindelin
It is no longer a shell script, so we need to call it in a different way
than the other backends.
Signed-off-by: Johannes Schindelin
---
builtin/rebase.c | 81
1 file changed, 81 insertions(+)
diff --git
The builtin rebase and the builtin interactive rebase have been developed
independently, on purpose: Google Summer of Code rules specifically state
that students have to work on independent projects, they cannot collaborate
on the same project.
The reason is probably the very fine tradition in
From: Johannes Schindelin
The `chainlint` target compares actual output to expected output, where
the actual output is generated from files that are specifically checked
out with LF-only line endings. So the expected output needs to be
checked out with LF-only line endings, too.
Signed-off-by:
Historically, nobody paid attention to our own source code having correct
Git attributes
[https://www.edwardthomson.com/blog/git_for_windows_line_endings.html] when
it comes to line endings. Because historically, we had no good way to
specify that ;-)
But now we do, and so we need to use it.
From: Johannes Schindelin
The way the guard was put, the code was declaring an unused variable on
Windows. No need to do that, so let's fix it.
Signed-off-by: Johannes Schindelin
---
entry.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/entry.c b/entry.c
index
With the relatively frequent breakages of pu recently, I had trouble staying
on top of the compile errors/test failures, sorry.
This one exists since Sunday, and it is a compile error only with
DEVELOPER=1, which is, however, the recommended way to build in Git for
Windows' SDK.
Note: it is
From: Johannes Schindelin
When displaying a diff of diffs, it is possible that there is an outer
`+` before a context line. That happens when the context changed between
old and new commit. When that context line starts with a tab (after the
space that marks it as context line), our diff
From: Johannes Schindelin
Tab completion of `git range-diff` is very convenient, especially
given that the revision arguments to specify the commit ranges to
compare are typically more complex than, say, what is normally passed
to `git log`.
Signed-off-by: Johannes Schindelin
---
From: Johannes Schindelin
The bulk of this patch consists of a heavily butchered version of
tbdiff's README written by Thomas Rast and Thomas Gummerer, lifted from
https://github.com/trast/tbdiff.
Signed-off-by: Johannes Schindelin
---
Documentation/git-range-diff.txt | 229
From: Johannes Schindelin
After using this command extensively for the last two months, this
developer came to the conclusion that even if the dual color mode still
leaves a lot of room for confusion about what was actually changed, the
non-dual color mode is substantially worse in that regard.
From: Johannes Schindelin
As pointed out by Elijah Newren, tbdiff has this neat little alignment
trick where it outputs the commit pairs with patch numbers that are
padded to the maximal patch number's width:
1: cafedead = 1: acefade first patch
[...]
314: beefeada <
From: Johannes Schindelin
When diffing diffs, it can be quite daunting to figure out what the heck
is going on, as there are nested +/- signs.
Let's make this easier by adding a flag in diff_options that allows
color-coding the outer diff sign with inverted colors, so that the
preimage and
From: Johannes Schindelin
When showing what changed between old and new commits, we show a diff of
the patches. This diff is a diff between diffs, therefore there are
nested +/- signs, and it can be relatively hard to understand what is
going on.
With the --dual-color option, the preimage and
From: Johannes Schindelin
It *is* a confusing thing to look at a diff of diffs. All too easy is it
to mix up whether the -/+ markers refer to the "inner" or the "outer"
diff, i.e. whether a `+` indicates that a line was added by either the
old or the new diff (or both), or whether the new diff
From: Johannes Schindelin
Arguably the most important part of `git range-diff`'s output is the
list of commits in the two branches, together with their relationships.
For that reason, tbdiff introduced color-coding that is pretty
intuitive, especially for unchanged patches (all dim yellow, like
From: Johannes Schindelin
This not only uses "dashed stand-ins" for "pairs" where one side is
missing (i.e. unmatched commits that are present only in one of the two
commit ranges), but also adds onelines for the reader's pleasure.
This change brings `git range-diff` yet another step closer to
From: Johannes Schindelin
When showing the diff between corresponding patches of the two branch
versions, we have to make up a fake filename to run the diff machinery.
That filename does not carry any meaningful information, hence tbdiff
suppresses it. So we should, too.
Signed-off-by:
From: Johannes Schindelin
Just like tbdiff, we now show the diff between matching patches. This is
a "diff of two diffs", so it can be a bit daunting to read for the
beginner.
An alternative would be to display an interdiff, i.e. the hypothetical
diff which is the result of first reverting the
From: Johannes Schindelin
At this stage, `git range-diff` can determine corresponding commits
of two related commit ranges. This makes use of the recently introduced
implementation of the linear assignment algorithm.
The core of this patch is a straight port of the ideas of tbdiff, the
From: Johannes Schindelin
We are comparing complete, formatted commit messages with patches. There
are no function names here, so stop looking for them.
Signed-off-by: Johannes Schindelin
---
range-diff.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/range-diff.c b/range-diff.c
From: Johannes Schindelin
When comparing commit messages, we need to keep in mind that they are
indented by four spaces. That is, empty lines are no longer empty, but
have "trailing whitespace". When displaying them in color, that results
in those nagging red lines.
Let's just right-trim the
From: Johannes Schindelin
This "color" simply reverts background and foreground. It will be used
in the upcoming "dual color" mode of `git range-diff`, where we will
reverse colors for the -/+ markers and the fragment headers of the
"outer" diff.
Signed-off-by: Johannes Schindelin
---
color.h
From: Johannes Schindelin
The problem solved by the code introduced in this commit goes like this:
given two sets of items, and a cost matrix which says how much it
"costs" to assign any given item of the first set to any given item of
the second, assign all items (except when the sets have
From: Johannes Schindelin
This command does not do a whole lot so far, apart from showing a usage
that is oddly similar to that of `git tbdiff`. And for a good reason:
the next commits will turn `range-branch` into a full-blown replacement
for `tbdiff`.
At this point, we ignore tbdiff's color
The incredibly useful git-tbdiff [https://github.com/trast/tbdiff] tool to
compare patch series (say, to see what changed between two iterations sent
to the Git mailing list) is slightly less useful for this developer due to
the fact that it requires the hungarian and numpy Python packages which
From: Johannes Schindelin
This patch lets `git range-diff` use the same order as tbdiff.
The idea is simple: for left-to-right readers, it is natural to assume
that the `git range-diff` is performed between an older vs a newer
version of the branch. As such, the user is probably more interested
From: Johannes Schindelin
The main information in the `range-diff` view comes from the list of
matching and non-matching commits, the diffs are additional information.
Indenting them helps with the reading flow.
Signed-off-by: Johannes Schindelin
---
builtin/range-diff.c | 10 ++
1
From: Johannes Schindelin
It *is* a confusing thing to look at a diff of diffs. All too easy is it
to mix up whether the -/+ markers refer to the "inner" or the "outer"
diff, i.e. whether a `+` indicates that a line was added by either the
old or the new diff (or both), or whether the new diff
From: Johannes Schindelin
When showing what changed between old and new commits, we show a diff of
the patches. This diff is a diff between diffs, therefore there are
nested +/- signs, and it can be relatively hard to understand what is
going on.
With the --dual-color option, the preimage and
From: Johannes Schindelin
This patch lets `git range-diff` use the same order as tbdiff.
The idea is simple: for left-to-right readers, it is natural to assume
that the `git range-diff` is performed between an older vs a newer
version of the branch. As such, the user is probably more interested
From: Johannes Schindelin
At this stage, `git range-diff` can determine corresponding commits
of two related commit ranges. This makes use of the recently introduced
implementation of the linear assignment algorithm.
The core of this patch is a straight port of the ideas of tbdiff, the
From: Johannes Schindelin
When comparing commit messages, we need to keep in mind that they are
indented by four spaces. That is, empty lines are no longer empty, but
have "trailing whitespace". When displaying them in color, that results
in those nagging red lines.
Let's just right-trim the
From: Johannes Schindelin
When diffing diffs, it can be quite daunting to figure out what the heck
is going on, as there are nested +/- signs.
Let's make this easier by adding a flag in diff_options that allows
color-coding the outer diff sign with inverted colors, so that the
preimage and
From: Johannes Schindelin
Arguably the most important part of `git range-diff`'s output is the
list of commits in the two branches, together with their relationships.
For that reason, tbdiff introduced color-coding that is pretty
intuitive, especially for unchanged patches (all dim yellow, like
From: Johannes Schindelin
This "color" simply reverts background and foreground. It will be used
in the upcoming "dual color" mode of `git range-diff`, where we will
reverse colors for the -/+ markers and the fragment headers of the
"outer" diff.
Signed-off-by: Johannes Schindelin
---
color.h
From: Johannes Schindelin
After using this command extensively for the last two months, this
developer came to the conclusion that even if the dual color mode still
leaves a lot of room for confusion about what was actually changed, the
non-dual color mode is substantially worse in that regard.
101 - 200 of 323 matches
Mail list logo
