When crosscompiling, one cannot rely on `uname` from host system.
Thus, add an option to use `make MINGW=1` for building MinGW build
from non-MinGW host (Linux, for example).
Signed-off-by: Marat Radchenko
---
config.mak.uname | 5 +
1 file changed, 5 insertions(+)
diff --git a
On Mon, Apr 28, 2014 at 03:20:46PM +0200, Johannes Schindelin wrote:
> That way, upstream Git does not have anything to change (and we avoid
> discussing five versions of essentially the same patch :-P).
This bug isn't specific to msysGit but also affects all environments
where curl-config is not
Silvola Tuomas wrote
> Hello,
>
> I installed git for windows 1.9.0 but any push operation I tried with it
> produced an error message saying "git: 'http-push' is not a git command".
> Other commands like pull, add, and commit worked just fine.
> At the end of this day I noticed that C:\Program Fi
Setup:
20 people (programmers, artists, designers) with prior SVN knowledge and a
desire to use Git for a new project (mostly on programmers side).
Non-programmers used TortoiseSVN before so choosing TortoiseGit as a GUI was an
obvios step.
We made an in-house presentation introducing basic Git
config.mak.uname: provide a way to explicitely request MinGW build.
This is required to perform Linux->MinGW crosscompilation.
---
> Personally I don't see why ideally I shouldn't be able to build upstream Git
> for Windows with mingw without leaving my Linux system.
One day you might be able, bu
On Sat, Apr 19, 2014 at 05:24:33PM +0200, Johannes Schindelin wrote:
> Marat, please do not add to the confusion. "msysGit" is the name of the
> *development environment* for developing Git for Windows.
This confusion comes from the fact that major part of msysGit is packaged
with Git for Windows
> So the reason for this new package is that you need 64bit binaries?
That's the most important bit. Plus, weird ssh transfer speeds [1] caused by
ansient openssh bundled in msysgit.
> I can see the need for a pure Windows solution (no msys tools at least for
> runtime).
Several Git scripts ar
On Thursday 03 April 2014 at 17:48:08 Konstantin Khomoutov wrote:
>
> What is the state of Unicode support in WinGit?
I haven't seen any Unicode-related issues when using through TortoiseGit.
Command-line usage is currently broken: no UTF-8 <->cmd.exe encoding
conversion is performed. Fixing thi
Drop NO_PERL_MAKEMAKER from config.mak.uname for the MSVC platform.
MakeMaker is available on Windows Perl implementations and
installs modules to correct location, unlike NO_PERL_MAKEMAKER Makefile.
Signed-off-by: Marat Radchenko
---
config.mak.uname | 1 -
1 file changed, 1 deletion(-)
diff
Stefan Zager chromium.org> writes:
>
> This adds a Windows implementation of pread.
> diff --git a/compat/mingw.h b/compat/mingw.h
> index 08b83fe..377ba50 100644
> --- a/compat/mingw.h
> +++ b/compat/mingw.h
> +ssize_t mingw_pread(int fd, void *buf, size_t count, off64_t offset);
> +#define pre
OPT_SET_PTR was never used since its creation in 2007 (commit
db7244bd5be12e389badb9cec621dbbcfa11f59a).
---
Documentation/technical/api-parse-options.txt | 4
parse-options.c | 5 -
parse-options.h | 5 +
t/t0040-parse-optio
correct one.
Signed-off-by: Marat Radchenko
---
test-parse-options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test-parse-options.c b/test-parse-options.c
index 434e8b8..6f6c656 100644
--- a/test-parse-options.c
+++ b/test-parse-options.c
@@ -60,7 +60,7 @@ int main(int
Do not force users of OPT_SET_PTR to cast pointer to correct
underlying pointer type by integrating cast into OPT_SET_PTR macro.
Cast is required to prevent 'initialization makes integer from pointer
without a cast' compiler warning.
---
parse-options.h | 2 +-
test-parse-options.c | 2 +-
2
by reverting №3, it will be returned
in a sane state.
Decision of (not) merging №3 is left as an exercise to the reader due to
my insufficient knowledge of accepted practices in Git project.
Marat Radchenko (3):
MSVC: fix t0040-parse-options crash
parse-options: add cast to correct pointer
correct one.
Signed-off-by: Marat Radchenko
---
Aargh! Didn't notice that V2 introduced compilation warning. Take three.
test-parse-options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test-parse-options.c b/test-parse-options.c
index 434e8b8..6f6c656 100644
--- a
.
Signed-off-by: Marat Radchenko
---
I will write verbose commit messages. I will write verbose commit messages.
I will write verbose commit messages. I will write verbose commit messages.
I will write verbose commit messages. I will write verbose commit messages.
I will write verbose commit
it is treated as invalid argument,
causing abort() and crash report window.
Linking in invalidcontinue.obj (provided along with MS compiler) allows
raise(SIGPIPE) to return with errno=EINVAL.
Signed-off-by: Marat Radchenko
---
config.mak.uname | 2 +-
1 file changed, 1 insertion(+), 1 del
Junio C Hamano pobox.com> writes:
> > This patch fixes crashes caused by quitting from PAGER.
>
> Can you elaborate a bit more on the underlying cause, summarizing
> what you learned from this discussion, so that those who read "git
> log" output two weeks from now do not have to come back to th
Signed-off-by: Marat Radchenko
---
test-parse-options.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/test-parse-options.c b/test-parse-options.c
index 434e8b8..7840493 100644
--- a/test-parse-options.c
+++ b/test-parse-options.c
@@ -11,6 +11,7 @@ static char *string
This patch fixes crashes caused by quitting from PAGER.
Signed-off-by: Marat Radchenko
---
> Please do not cull the Cc list.
That was gmane web interface.
> The correct solution is to link against invalidcontinue.obj in the MSVC
> build. This is a compiler-provided object file tha
Jeff King peff.net> writes:
>
> I'm not sure what an actual SIGPIPE death looks like on Windows.
There is no SIGPIPE death on Windows due to total absence of SIGPIPE.
raise(unsupported int) just causes ugly "git.exe has stopped working"
window and possibly ends up as SIGABT (I don't know how to
Marat Radchenko slonopotamus.org> writes:
>
> Jeff King peff.net> writes:
>
> >
> > The write_or_die function will always die on an error,
> > including EPIPE. However, it currently treats EPIPE
> > specially by suppressing any error message, and by
Jeff King peff.net> writes:
>
> The write_or_die function will always die on an error,
> including EPIPE. However, it currently treats EPIPE
> specially by suppressing any error message, and by exiting
> with exit code 0.
This causes error box on Windows in MSVC=1 build:
git.exe!_invoke_watson
Without this, xdiff/xutils.c fails to compile.
Signed-off-by: Marat Radchenko
---
I thought about removing #define inline __inline from compat/msvc.h but:
* compat/msvc.h is included based on #if defined(_MSC_VER)
and can be enabled even if MSVC != 1
* compat/msvc.h also has #define
Junio C Hamano pobox.com> writes:
> My gut feeling is that adding a mechanism to add -DINLINE=__inline
> only on MSVC to the top-level Makefile, without touching this file,
> may be a much more palatable.
Okay, I'll think more about this one. Maybe *moving* inline=__inline from
compat-headers in
Signed-off-by: Marat Radchenko
---
xdiff/xutils.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index 62cb23d..a21a835 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -23,6 +23,7 @@
#include
#include
#include "xinclude.h"
+#include &
Signed-off-by: Marat Radchenko
---
compat/vcbuild/scripts/clink.pl | 2 ++
config.mak.uname| 1 -
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/compat/vcbuild/scripts/clink.pl b/compat/vcbuild/scripts/clink.pl
index 4374771..a87d0da 100755
--- a/compat/vcbuild
101 - 127 of 127 matches
Mail list logo
