On Wed, Jun 19, 2019 at 2:19 AM Johannes Sixt wrote:
> Am 19.06.19 um 01:12 schrieb Eric Sunshine:
> > On Tue, Jun 18, 2019 at 8:24 AM Johannes Schindelin via GitGitGadget
> > wrote:
> >> printf ".git\nfatal: Needed a single revision\n" >expect &&
> >> - test_cmp expect output.txt
>
Am 19.06.19 um 05:49 schrieb Jeff King:
> On Tue, Jun 18, 2019 at 10:32:47PM +0200, Johannes Sixt wrote:
>
>> Am 17.06.19 um 18:54 schrieb Boxuan Li:
>>> diff --git a/templates/this--userdiff b/templates/this--userdiff
>>> new file mode 100644
>>> index 00..85114a7229
>>> --- /dev/null
>>>
Am 19.06.19 um 01:12 schrieb Eric Sunshine:
> On Tue, Jun 18, 2019 at 8:24 AM Johannes Schindelin via GitGitGadget
> wrote:
>> diff --git a/t/t0001-init.sh b/t/t0001-init.sh
>> @@ -474,7 +474,8 @@ test_expect_success MINGW 'redirect std handles' '
>> printf ".git\nfatal: Needed a single re
On Tue, Jun 18, 2019 at 8:28 PM Matheus Tavares
wrote:
>
> This patchset contains:
> - tests to the dir-iterator API;
> - dir-iterator refactoring to make its state machine simpler
> and feature adding with tests;
> - a replacement of explicit recursive dir iteration at
> copy_or_link_director
On Tue, Jun 18, 2019 at 8:24 AM Jeff Hostetler via GitGitGadget
wrote:
> This special-cases various signals that are not supported on Windows,
> such as SIGPIPE. These cause the UCRT to throw asserts (at least in
> debug mode).
>
> Signed-off-by: Jeff Hostetler
> Signed-off-by: Johannes Schindeli
On Tue, Jun 18, 2019 at 12:54:50AM +0800, Boxuan Li wrote:
> A few notes and questions:
> 1. In [diff "tex"] section, \x80 and \xff cannot be parsed by git config
> parser.
> I have no idea why this is happening. I changed them to \\x80 and \\xff as a
> workaround, which
> resulted in t4034 fail
On Tue, Jun 18, 2019 at 10:32:47PM +0200, Johannes Sixt wrote:
> Am 17.06.19 um 18:54 schrieb Boxuan Li:
> > The userdiff.c has been rewritten to avoid hard-coded built-in
> > driver patterns. Now we ship
> > $(sharedir)/git-core/templates/userdiff that can be read using
> > git_config_from_file()
On Sat, Jun 15, 2019 at 10:41:44AM +0200, Christian Couder wrote:
> On Fri, Jun 14, 2019 at 5:10 PM Jeff King wrote:
> >
> > On Fri, Jun 14, 2019 at 08:35:04PM +0900, Masahiro Yamada wrote:
> >
> > > Perhaps, 'git interpret-trailers' should be changed
> > > to recognize core.commentChar ?
> >
> >
On Tue, Jun 18, 2019 at 5:26 AM Jeff Hostetler via GitGitGadget
wrote:
> diff --git a/compat/mingw.c b/compat/mingw.c
> index d14d33308d..667285887a 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -2388,6 +2388,12 @@ static void maybe_redirect_std_handles(void)
>
shouldn't this also be a problem with builtin/blame.c?
Carlo
Replace the use of strcmp by fspathcmp at copy_or_link_directory, which
is more permissive/friendly to case-insensitive file systems.
Suggested-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Matheus Tavares
---
builtin/clone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin
Make the copy_or_link_directory function no longer skip hidden
directories. This function, used to copy .git/objects, currently skips
all hidden directories but not hidden files, which is an odd behaviour.
The reason for that could be unintentional: probably the intention was
to skip '.' and '..' o
dir_iterator_advance() is a large function with two nested loops. Let's
improve its readability factoring out three functions and simplifying
its mechanics. The refactored model will no longer depend on
level.initialized and level.dir_state to keep track of the iteration
state and will perform on a
Replace usage of opendir/readdir/closedir API to traverse directories
recursively, at copy_or_link_directory function, by the dir-iterator
API. This simplifies the code and avoids recursive calls to
copy_or_link_directory.
This process also makes copy_or_link_directory call die() in case of an
err
Add the possibility of giving flags to dir_iterator_begin to initialize
a dir-iterator with special options.
Currently possible flags are:
- DIR_ITERATOR_PEDANTIC, which makes dir_iterator_advance abort
immediately in the case of an error, instead of keep looking for the
next valid entry;
- DIR_IT
From: Daniel Ferreira
Create t/helper/test-dir-iterator.c, which prints relevant information
about a directory tree iterated over with dir-iterator.
Create t/t0066-dir-iterator.sh, which tests that dir-iterator does
iterate through a whole directory tree as expected.
Signed-off-by: Daniel Ferre
Change warning(..., strerror(errno)) by warning_errno(...). This helps
to unify warning display besides simplifying a bit the code. Also,
improve warning messages by surrounding paths with quotation marks and
using more meaningful statements.
Signed-off-by: Matheus Tavares
---
dir-iterator.c | 2
Extract dir creation code snippet from copy_or_link_directory to its own
function named mkdir_if_missing. This change will help to remove
copy_or_link_directory's explicit recursion, which will be done in a
following patch. Also makes the code more readable.
Signed-off-by: Matheus Tavares
---
bu
There is currently an odd behaviour when locally cloning a repository
with symlinks at .git/objects: using --no-hardlinks all symlinks are
dereferenced but without it, Git will try to hardlink the files with the
link() function, which has an OS-specific behaviour on symlinks. On OSX
and NetBSD, it
From: Ævar Arnfjörð Bjarmason
Add tests for what happens when we perform a local clone on a repo
containing odd files at .git/object directory, such as symlinks to other
dirs, or unknown files.
I'm bending over backwards here to avoid a SHA-1 dependency. See [1]
for an earlier and simpler versio
This patchset contains:
- tests to the dir-iterator API;
- dir-iterator refactoring to make its state machine simpler
and feature adding with tests;
- a replacement of explicit recursive dir iteration at
copy_or_link_directory for the dir-iterator API;
- some refactoring and behavior changes at
On Tue, Jun 18, 2019 at 8:24 AM Jeff Hostetler via GitGitGadget
wrote:
> In MSVC, the DEBUG constant is set automatically whenever compiling with
> debug information.
>
> This is clearly not what was intended in cache-tree.c, so let's use a less
> ambiguous constant there.
s/constant/macro name/
On Tue, Jun 18, 2019 at 8:24 AM Johannes Schindelin via GitGitGadget
wrote:
> When redirecting stdout/stderr to the same file, we cannot guarantee
> that stdout will come first.
>
> In fact, in this test case, it seems that an MSVC build always prints
> stderr first.
>
> In any case, this test cas
On 2019-06-18 at 06:14:03, Johannes Sixt wrote:
> Am 18.06.19 um 03:29 schrieb brian m. carlson:
> > On 2019-06-17 at 19:05:03, Johannes Schindelin wrote:
> > I'm fine making that change. The original design was because we had
> > other code that used that technique and I didn't see an obviously be
In the interest of simplifying the code and the job of translators, I've
decided to simply remove the ( from the translatable strings as suggested by
Junio in a response to v2 of this patchset.
I thought that a regression test would be a bit overkill for a fix of this
nature. Instead, I've added a
Before this patch, "git branch" would put "(HEAD detached...)" and "(no
branch, rebasing...)" lines before all the other branches *in most
cases* except for when using Chinese-language messages. zh_CN generally
uses a full-width "(" symbol (codepoint FF08) to match the full-width
proportions of Chi
Allow easier parsing by cat-file by giving rev-list an option to print
only the OID of a non-commit object without any additional information.
This is a short-term shim; later on, rev-list should be taught how to
print the types of objects it finds in a format similar to cat-file's.
Before this co
On Mon, Jun 17, 2019 at 03:32:34PM -0700, Junio C Hamano wrote:
> Emily Shaffer writes:
>
> > Allow easier parsing by cat-file by giving rev-list an option to print
> > only the OID of a non-commit object without any additional information.
> > This is a short-term shim; later on, rev-list should
I want to discuss a very profitable business with you.
Reply for info.
Regards,
Ms. Yu
Am 18.06.19 um 22:32 schrieb Johannes Sixt:
> Am 17.06.19 um 18:54 schrieb Boxuan Li:
>> The userdiff.c has been rewritten to avoid hard-coded built-in
>> driver patterns. Now we ship
>> $(sharedir)/git-core/templates/userdiff that can be read using
>> git_config_from_file() interface, using a very
Am 17.06.19 um 18:54 schrieb Boxuan Li:
> The userdiff.c has been rewritten to avoid hard-coded built-in
> driver patterns. Now we ship
> $(sharedir)/git-core/templates/userdiff that can be read using
> git_config_from_file() interface, using a very narrow callback
> function that understands only
From: Derrick Stolee
The --[no-]show-forced-updates option in 'git fetch' can be confusing
for some users, especially if it is enabled via config setting and not
by argument. Add advice to warn the user that the (forced update)
messages were not listed.
Additionally, warn users when the forced u
The git fetch builtin includes a calculation to see if the ref values were
forced updates (i.e. if the old value is not in the history of the new
value). In a repo with many refs and a fast-moving history, this calculation
can be very slow.
This series adds a new --[no-]show-forced-updates option
From: Derrick Stolee
The 'git fetch' command can avoid calculating forced updates, so
allow users of 'git pull' to provide that option. This is particularly
necessary when the advice to use '--no-show-forced-updates' is given
at the end of the command.
Signed-off-by: Derrick Stolee
---
builtin
From: Derrick Stolee
After updating a set of remove refs during a 'git fetch', we walk the
commits in the new ref value and not in the old ref value to discover
if the update was a forced update. This results in two things happening
during the command:
1. The line including the ref update has a
On Tue, Jun 18, 2019 at 10:42:10AM +0200, Johannes Schindelin wrote:
> > + if (!subspecs[0]) {
> > + strbuf_addf(errbuf,
> > + _("expected something after combine:"));
>
> Please squash this in, to pacify Coccinelle:
>
> -- snipsnap --
> diff --git a/list-objects
From: Jeff Hostetler
Teach porcelain V[12] formats to ignore the status.aheadbehind
config setting. They only respect the --[no-]ahead-behind
command line argument. This is for backwards compatibility
with existing scripts.
Signed-off-by: Jeff Hostetler
Signed-off-by: Derrick Stolee
---
buil
From: Jeff Hostetler
The ahead/behind calculation in 'git status' can be slow in some
cases. Users may not realize that there are ways to avoid this
computation, especially if they are not using the information.
Add a warning that appears if this calculation takes more than
two seconds. The warn
From: Jeff Hostetler
The --[no-]ahead-behind option was introduced in fd9b544a
(status: add --[no-]ahead-behind to status and commit for V2
format, 2018-01-09). This is a necessary change of behavior
in repos where the remote tracking branches can move very
quickly ahead of the local branches. Ho
The git status builtin includes a calculation for how far the local ref is
ahead or behind the remote tracking branch. This check can be expensive, so
we already have a --[no-]ahead-behind command-line option.
This series adds two bits of functionality to the feature:
1. Add a new status.aheadBe
From: Derrick Stolee
The helper function commit_compare() actually compares object_id
structs, not commits. A future change to commit-graph.c will need
to sort commit structs, so rename this function in advance.
Signed-off-by: Derrick Stolee
---
commit-graph.c | 4 ++--
1 file changed, 2 inser
From: Derrick Stolee
In an environment like a fork network, it is helpful to have a
commit-graph chain that spans both the base repo and the fork repo. The
fork is usually a small set of data on top of the large repo, but
sometimes the fork is much larger. For example, git-for-windows/git has
alm
From: Derrick Stolee
If we write a commit-graph file without the split option, then
we write to $OBJDIR/info/commit-graph and start to ignore
the chains in $OBJDIR/info/commit-graphs/.
Unlink the commit-graph-chain file and expire the graph-{hash}.graph
files in $OBJDIR/info/commit-graphs/ durin
From: Derrick Stolee
When writing commit-graph files, we append path data to an
object directory, which may be specified by the user via the
'--object-dir' option. If the user supplies a trailing slash,
or some other alternative path format, the resulting path may
be usable for writing to the cor
From: Derrick Stolee
We allow sharing commit-graph files across alternates. When we are
writing a split commit-graph, we allow adding tip graph files that
are not in the alternate, but include commits from our local repo.
However, if our alternate is not using the split commit-graph format,
its
From: Derrick Stolee
To quickly verify a commit-graph chain is valid on load, we will
read from the new "Base Graphs Chunk" of each file in the chain.
This will prevent accidentally loading incorrect data from manually
editing the commit-graph-chain file or renaming graph-{hash}.graph
files.
The
From: Derrick Stolee
The split commit-graph feature is now fully implemented, but needs
some more run-time configurability. Allow direct callers to 'git
commit-graph write --split' to specify the values used in the
merge strategy and the expire time.
Update the documentation to specify these val
From: Derrick Stolee
As we merge commit-graph files in a commit-graph chain, we should clean
up the files that are no longer used.
This change introduces an 'expiry_window' value to the context, which is
always zero (for now). We then check the modified time of each
graph-{hash}.graph file in th
From: Derrick Stolee
Prepare the logic for reading a chain of commit-graphs.
First, look for a file at $OBJDIR/info/commit-graph. If it exists,
then use that file and stop.
Next, look for the chain file at $OBJDIR/info/commit-graphs/commit-graph-chain.
If this file exists, then load the hash va
From: Derrick Stolee
Octopus merges require an extra chunk of data in the commit-graph
file format. Create a test that ensures the new --split option
continues to work with an octopus merge. Specifically, ensure
that the octopus merge has parents across layers to truly check
that our graph positi
From: Derrick Stolee
If we wrote a commit-graph chain, we only modified the tip file in
the chain. It is valuable to verify what we wrote, but not waste
time checking files we did not write.
Add a '--shallow' option to the 'git commit-graph verify' subcommand
and check that it does not read the
From: Derrick Stolee
Add a new "--split" option to the 'git commit-graph write' subcommand. This
option allows the optional behavior of writing a commit-graph chain.
The current behavior will add a tip commit-graph containing any commits that
are not in the existing commit-graph or commit-graph
From: Derrick Stolee
Extend write_commit_graph() to write a commit-graph chain when given the
COMMIT_GRAPH_SPLIT flag.
This implementation is purposefully simplistic in how it creates a new
chain. The commits not already in the chain are added to a new tip
commit-graph file.
Much of the logic a
From: Derrick Stolee
The 'git commit-graph verify' subcommand loads a commit-graph from
a given object directory instead of using the standard method
prepare_commit_graph(). During development of load_commit_graph_chain(),
a version did not include prepare_alt_odb() as it was previously
run by pr
From: Derrick Stolee
The number of chunks in a commit-graph file can change depending on
whether we need the Extra Edges Chunk. We are going to add more optional
chunks, and it will be helpful to rearrange this logic around the chunk
count before doing so.
Specifically, we need to finalize the n
From: Derrick Stolee
When searching for a commit in a commit-graph chain of G graphs with N
commits, the search takes O(G log N) time. If we always add a new tip
graph with every write, the linear G term will start to dominate and
slow the lookup process.
To keep lookups fast, but also keep most
From: Derrick Stolee
To prepare for a chain of commit-graph files, augment the
commit_graph struct to point to a base commit_graph. As we load
commits from the graph, we may actually want to read from a base
file according to the graph position.
The "graph position" of a commit is given by conca
This version is now ready for review.
The commit-graph is a valuable performance feature for repos with large
commit histories, but suffers from the same problem as git repack: it
rewrites the entire file every time. This can be slow when there are
millions of commits, especially after we stopped
From: Derrick Stolee
Add a basic description of commit-graph chains. More details about the
feature will be added as we add functionality. This introduction gives a
high-level overview to the goals of the feature and the basic layout of
commit-graph chains.
Signed-off-by: Derrick Stolee
---
Do
> > @@ -230,7 +246,7 @@ static int find_common(struct fetch_negotiator
> > *negotiator,
> > if (args->stateless_rpc && multi_ack == 1)
> > die(_("--stateless-rpc requires multi_ack_detailed"));
> >
> > - for_each_ref(rev_list_insert_ref_oid, negotiator);
> > + mark_tips(negotia
On Tue, Jun 18, 2019 at 10:01 AM Eric Sunshine wrote:
>
> On Tue, Jun 18, 2019 at 12:39 PM Anthony Sottile wrote:
> > + git fetch origin --tags
> > Unpacking objects: 100% (10/10), done.
> > From https://github.com/asottile-archive/git-windows-branch-test
> > * [new branch] master -> or
On 6/18/2019 10:31 AM, Vanak, Ibrahim wrote:
Hello ALL again,
Has anyone tested the performance of GIT on HP-UX platform? Can someone please
look into the issue we are seeing.
Thanks,
Ibrahim
You might try setting some of the GIT_TRACE* environment variables
listed in [1] on both your HP
git am or rebase have a --skip flag to skip the current commit if the
user wishes to do so. During a cherry-pick or revert a user could
likewise skip a commit, but needs to use 'git reset' (or in the case
of conflicts 'git reset --merge'), followed by 'git (cherry-pick |
revert) --continue' to skip
The previous commit introduced a --skip flag for cherry-pick and
revert. Update the advice messages, to tell users about this less
cumbersome way of skipping commits. Also add tests to ensure
everything is working fine.
Signed-off-by: Rohit Ashiwal
---
builtin/commit.c| 13 ++
Avoid using magic numbers for array size and index under `reset_merge`
function. Use `argv_array` instead. This will make code shorter and
easier to extend.
Signed-off-by: Rohit Ashiwal
---
sequencer.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/sequenc
In the case of merge conflicts, while performing a revert, we are
currently advised to use `git cherry-pick --`
of which --continue is incompatible for continuing the revert.
Introduce a separate advice message for `git revert`. Also change
the signature of `create_seq_dir` to handle which advice t
We are on a path to teach cherry-pick/revert how to skip commits. To
achieve this, we could really make use of existing functions.
reset_for_rollback is one such function, but the name does not
intuitively suggest to use it to reset a merge, which it was born to
perform see 539047c ("revert: introd
Here is another round of my patch, hopefully I have addressed all the changes.
- I have introduced a separate commit which changes `reset_merge` to use
`argv_array` instead of a manual `char *argv`. This will avoid specifying
array size and index and make code easier to read and extend
On Tue, Jun 18, 2019 at 06:15:46PM +0200, Johannes Schindelin wrote:
> > And looking through this patch series, I see a gazillion of *new*
> > process substitutions $(test_something...) and $(basename $whatever).
> > Can't we do something about it?
>
> I wish there was. Unix shell scripting has n
On Tue, Jun 18, 2019 at 12:39 PM Anthony Sottile wrote:
> + git fetch origin --tags
> Unpacking objects: 100% (10/10), done.
> From https://github.com/asottile-archive/git-windows-branch-test
> * [new branch] master -> origin/master
> error: cannot lock ref 'refs/remotes/origin/pr/aux':
On Tue, Jun 18, 2019 at 06:15:46PM +0200, Johannes Schindelin wrote:
> > Regardless of how it is implemented, I have another gripe with this
> > helper: the way it must be used requires a process: $(test_out_to_path
> > $foo)
>
> Indeed.
>
> > And looking through this patch series, I see a gazill
hit send too quickly, here's my version information:
$ git --version
git version 2.22.0.windows.1
On Tue, Jun 18, 2019 at 9:38 AM Anthony Sottile wrote:
>
> I've set up a demo problematic repository on github:
> https://github.com/asottile-archive/git-windows-branch-test
>
> The minimal reproduc
I've set up a demo problematic repository on github:
https://github.com/asottile-archive/git-windows-branch-test
The minimal reproduction is:
rm -rf x
git init x
cd x
git remote add origin https://github.com/asottile-archive/git-windows-branch-te>
git fetch origin --tags
Here's the output:
+ gi
Hi Hannes,
On Tue, 18 Jun 2019, Johannes Sixt wrote:
> Am 18.06.19 um 03:29 schrieb brian m. carlson:
> > On 2019-06-17 at 19:05:03, Johannes Schindelin wrote:
> >> I guess it does not *really* matter all that much, but this does spawn a
> >> new process (and I think it actually spawns 4 on Windo
We started including stdio.h to pick up the declaration of "FILE" in
f26a001226 (Enable wt-status output to a given FILE pointer.,
2007-09-17). But there's no need, since headers can assume that
git-compat-util.h has been included, which covers stdio.
This should just be redundant, and not hurting
There's no reason verify-tag.c needs to include signal.h. It's already
in git-compat-util.h, which we properly include as the first header.
And there doesn't seem to be a particular reason for this include; it's
just an artifact from the file creation in 2ae68fcb78 (Make verify-tag a
builtin., 2007
On Mon, Jun 17, 2019 at 11:45:37PM -0700, Carlo Marcelo Arenas Belón wrote:
> after b46054b374 ("xdiff: use git-compat-util", 2019-04-11), two system
> headers added in 2012 to xutils where no longer needed and could conflict
> as shown below:
>
> In file included from xdiff/xinclude.h:26:0,
>
"Morian Sonnet via GitGitGadget" wrote:
I fixed the problem with the test case. Please take another look.
> From: Morian Sonnet
>
> Calling
>
> git submodule foreach --recursive git reset --hard
>
> leads to an error stating that the option --hard is unknown to
> submodule--helper.
>
> Reas
Hi Carlo,
in the Git ecosystem, the abbreviation "LFS" does not mean what you think
it means... Let's not use the abbreviation for anything else.
On Mon, 17 Jun 2019, Carlo Marcelo Arenas Belón wrote:
> after b46054b374 ("xdiff: use git-compat-util", 2019-04-11), two system
> headers added in 20
Hello ALL again,
Has anyone tested the performance of GIT on HP-UX platform? Can someone please
look into the issue we are seeing.
Thanks,
Ibrahim
-Original Message-
From: Vanak, Ibrahim
Sent: Tuesday, June 11, 2019 10:09 PM
To: Jeff King
Cc: git@vger.kernel.org
Subject: RE: GIT issue
On Tue, Jul 03 2018, Jonathan Tan wrote:
> During negotiation, fetch-pack eventually reports as "have" lines all
> commits reachable from all refs. Allow the user to restrict the commits
> sent in this way by providing a whitelist of tips; only the tips
> themselves and their ancestors will be s
On 6/14/2019 4:50 PM, Junio C Hamano wrote:
> * ds/commit-graph-incremental (2019-06-12) 16 commits
> - commit-graph: test --split across alternate without --split
> - commit-graph: test octopus merges with --split
> - commit-graph: clean up chains after flattened write
> - commit-graph: verify
Philip Oakley and Jeff Hostetler worked quite a bit on getting Git to
compile with MS Visual C again, and this patch series is the culmination of
those efforts. With these patches, it is as easy as
make MSVC=1
Note: the patches went through quite the number of iterations. For example,
for a long
From: Philip Oakley
On MSVC (VS2008) sigset_t is not defined.
Signed-off-by: Philip Oakley
Signed-off-by: Johannes Schindelin
---
compat/msvc.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/compat/msvc.h b/compat/msvc.h
index 29a8ce8204..04b4750b87 100644
--- a/compat/msvc.h
+++ b/com
From: Jeff Hostetler
It is just called differently in MSVC's headers.
Signed-off-by: Jeff Hostetler
Signed-off-by: Johannes Schindelin
---
compat/msvc.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/compat/msvc.h b/compat/msvc.h
index d336d80670..d7525cf61d 100644
--- a/compat/msvc.h
From: Johannes Schindelin
When redirecting stdout/stderr to the same file, we cannot guarantee
that stdout will come first.
In fact, in this test case, it seems that an MSVC build always prints
stderr first.
In any case, this test case does not want to verify the *order* but
the *presence* of b
From: Jeff Hostetler
In MSVC, the DEBUG constant is set automatically whenever compiling with
debug information.
This is clearly not what was intended in cache-tree.c, so let's use a less
ambiguous constant there.
Signed-off-by: Jeff Hostetler
Signed-off-by: Johannes Schindelin
---
cache-tre
From: Johannes Schindelin
The file compat/msvc.c includes compat/mingw.c, which means that we have
to recompile compat/msvc.o if compat/mingw.c changes.
Signed-off-by: Johannes Schindelin
---
config.mak.uname | 2 ++
1 file changed, 2 insertions(+)
diff --git a/config.mak.uname b/config.mak.u
From: Philip Oakley
MSVC can be overzealous about some warnings. Disable them.
Signed-off-by: Philip Oakley
Signed-off-by: Johannes Schindelin
---
compat/msvc.h | 4
1 file changed, 4 insertions(+)
diff --git a/compat/msvc.h b/compat/msvc.h
index d7525cf61d..1d7a8c6145 100644
--- a/comp
From: Jeff Hostetler
VS2015 complains when using a const pointer in memcpy()/free().
Signed-off-by: Jeff Hostetler
Signed-off-by: Johannes Schindelin
---
compat/mingw.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 0d8713e515..d1
From: Jeff Hostetler
VS2015's headers already declare that struct.
Signed-off-by: Jeff Hostetler
Signed-off-by: Johannes Schindelin
---
compat/mingw.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/compat/mingw.h b/compat/mingw.h
index 210f1b01a8..a03e40e6e2 100644
--- a/compat/mingw.h
From: Jeff Hostetler
This special-cases various signals that are not supported on Windows,
such as SIGPIPE. These cause the UCRT to throw asserts (at least in
debug mode).
Signed-off-by: Jeff Hostetler
Signed-off-by: Johannes Schindelin
---
compat/mingw.c | 26 ++
1 fi
From: Johannes Schindelin
Git for Windows has special code to retrieve the command-line parameters
(and even the environment) in UTF-16 encoding, so that they can be
converted to UTF-8. This is necessary because Git for Windows wants to
use UTF-8 encoded strings throughout its code, and the main(
From: Philip Oakley
This constant is not defined in MSVC's headers.
In UCRT's fcntl.h, _O_RDONLY, _O_WRONLY and _O_RDWR are defined as 0, 1
and 2, respectively. Yes, that means that UCRT breaks with the tradition
that O_RDWR == O_RDONLY | O_WRONLY.
It is a perfectly legal way to define those co
From: Jeff Hostetler
With this patch, Git can be built using the Microsoft toolchain, via:
make MSVC=1 [DEBUG=1]
Third party libraries are built from source using the open source
"vcpkg" tool set. See https://github.com/Microsoft/vcpkg
On a first build, the vcpkg tools and the third pa
From: Jeff Hostetler
Ignore .dll files copied into the top-level directory.
Ignore MSVC incremental compiler output files.
Signed-off-by: Jeff Hostetler
Signed-off-by: Johannes Schindelin
---
.gitignore | 5 +
1 file changed, 5 insertions(+)
diff --git a/.gitignore b/.gitignore
index 237
From: Jeff Hostetler
The ntstatus.h header is only available in MINGW.
Signed-off-by: Jeff Hostetler
Signed-off-by: Johannes Schindelin
---
compat/winansi.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/compat/winansi.c b/compat/winansi.c
index f4f08237f9..11cd9b82cc 1006
From: Johannes Schindelin
For regular debugging, it is pretty helpful when a debug assertion in a
running application triggers a window that offers to start the debugger.
However, when running the test suite, it is not so helpful, in
particular when the debug assertions are then suppressed anywa
From: Johannes Schindelin
MS Visual C suggests that the construct
condition ? (int) i : (ptrdiff_t) d
is incorrect. Let's fix this by casting to ptrdiff_t also for the
positive arm of the conditional.
Signed-off-by: Johannes Schindelin
---
compat/obstack.h | 2 +-
1 file changed, 1 i
From: Johannes Schindelin
Just like the natural line ending for Unix shell scripts consist of a
single Line Feed, the natural line ending for (DOS) Batch scripts
consists of a Carriage Return followed by a Line Feed.
It seems that both Unix shell script interpreters and the interpreter
for Batch
1 - 100 of 103 matches
Mail list logo
