thicket of implied branches is usually very wide; It is
actually quite common that *most* of the commits in a topic branch have
not even one implied parent, so that a final merge commit has about as
many implied parents as there are commits in said branch.
Signed-off-by: Johannes Schindelin
Hi Jonathan,
On Fri, 27 Dec 2013, Jonathan Nieder wrote:
Johannes Schindelin wrote:
it returns EOF only if ch == EOF *and* sb-len == 0, i.e. if no characters
have been read before hitting EOF.
Yep. api-strbuf.txt even says so.
I never bothered to look ;-)
Sorry for the nonsense
Hi Jonathan,
On Fri, 27 Dec 2013, Jonathan Nieder wrote:
Johannes Schindelin wrote:
On Fri, 27 Dec 2013, Jonathan Nieder wrote:
Is this easy to reproduce so some interested but lazy person could
write a test?
Yep. Make 25 orphan commits, add a graft line to make the first a merge
Dear fans of Git,
this mail brings to you the good news that Git for Windows is available in
a new version: 1.8.5.2-preview20131230
Many, many thanks go to the tireless developers working on this
particularly hard port of Git.
Changes since Git-1.8.4-preview20130916
New Features
- Comes with
Hi Junio,
On Thu, 2 Jan 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
On Thu, 2 Jan 2014, Sebastian Schuberth wrote:
See https://github.com/msysgit/git/pull/80.
Thanks Sebastian!
However, since the git.git project is not comfortable
a platform specific directory separator into
safe_create_leading_directories().
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
It would be nice to have links to the original discussion, but I guess
that that would not be accepted
Hi Junio,
On Thu, 2 Jan 2014, Junio C Hamano wrote:
If we are going to change the meaning of the function so that it can
now take any random path in platform-specific convention
Note that nothing in the function name or documentation suggests
otherwise.
that may be incompatible with the
Hi,
On Tue, 7 Jan 2014, Erik Faye-Lund wrote:
On Thu, Jan 2, 2014 at 9:46 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
Well, you and I both know how easy GitHub's pull request made things
for us as well as for contributors. I really cannot thank Erik enough
for bullying me
Hi Torsten,
On Mon, 20 Jan 2014, Torsten Bögershausen wrote:
(No top-posting, please see my comments below)
already very good! For extra brownie points, just edit the quoted part to
reflect the abridged version needed to understand the context.
On 2014-01-20 15.02, Jochen wrote:
On
Hi kusma,
On Tue, 21 Jan 2014, Erik Faye-Lund wrote:
On Tue, Jan 21, 2014 at 12:25 AM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
On Mon, 20 Jan 2014, Torsten Bögershausen wrote:
b) add +++ at the places where you added the stat() and chmod(),
c) and to send the question
Hi Michael,
On Wed, 22 Jan 2014, Michael Haggerty wrote:
Would the mentioned authors (CCed) consent to the removal of these
sections?
Fine by me!
Dscho
P.S.: Congrats on your new job!
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Hi Brian,
On Fri, 24 Jan 2014, brian m. carlson wrote:
On Fri, Jan 24, 2014 at 10:05:14PM +0100, Torsten Bögershausen wrote:
diff --git a/builtin/repack.c b/builtin/repack.c
index ba66c6e..033b4c2 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -324,6 +324,10 @@ int
Hi Tay,
On Mon, 17 Feb 2014, Tay Ray Chuan wrote:
Posting to msysgit since this was on Windows.
Thanks.
On Mon, Feb 17, 2014 at 3:45 PM, youngseonkim 1.youngsun@gmail.com
wrote:
git svn clone https://my.svn.repo/url --stdlayout
When I test a small svn repository and 'real working
Hopefully the Postfix Greylisting Policy Server will not try again to
greylist me, as it might however do without violating the RFC.
-- Forwarded message --
Date: Tue, 18 Feb 2014 00:38:54 +0100 (CET)
From: Johannes Schindelin johannes.schinde...@gmx.de
To: msys
Hi Sebastian,
On Wed, 19 Mar 2014, Sebastian Schuberth wrote:
On MINGW, pwd is defined as pwd -W in test-lib.sh. This usually is the
right thing, but the absolute Windows path with a colon confuses rsync. We
could use $PWD in this case to work around the issue, but in fact there is
no need
Hi,
the Git for Windows team just released version 1.9.2 of the
Windows-specific installers.
New Features
* Comes with Git 1.9.2 plus Windows-specific patches.
* Custom installer settings can be saved and loaded, for unsupervised
installation on batches of machines (msysGit PR #168).
* Comes
Dear friends of Git for Windows,
it was very delightful to be on the show, hosted by Thomas Ferris
Nicolaisen:
http://episodes.gitminutes.com/2014/04/gitminutes-28-johannes-schindelin-on.html
Enjoy,
Johannes
--
To unsubscribe from this list: send the line unsubscribe git in
the body
Hi Peff,
On Wed, 16 Apr 2014, Jeff King wrote:
On Wed, Apr 16, 2014 at 04:15:19PM +0200, Stepan Kasal wrote:
From: Jean-Jacques Lafay at Sat, 10 Nov 2012 18:36:10 +0100
In large repos, the recursion implementation of contains(commit,
commit_list) may result in a stack overflow.
Hi Peff,
On Thu, 17 Apr 2014, Jeff King wrote:
On Thu, Apr 17, 2014 at 07:31:54PM +0200, Johannes Schindelin wrote:
bash -c ulimit -s 64 git tag --contains HEAD actual
[...]
Please see https://github.com/msysgit/git/c63d196 for the fixup, and
https://github.com/msysgit/git
Hi,
On Sat, 19 Apr 2014, Heiko Voigt wrote:
On Thu, Apr 03, 2014 at 05:18:50PM +0400, ma...@slonopotamus.org wrote:
I'm proud to announce WinGit:
an attempt to bring Git powers to 64-bit Windows.
So the reason for this new package is that you need 64bit binaries?
Relationship with
Hi Marat,
On Sat, 19 Apr 2014, Marat Radchenko wrote:
But in practice, msysgit is:
1) outdated msys that was patched in multiple ways without
sending patches upstream
2) heavily patched git, again not upstreamed
Again, this time explicitly: I wish you had done a little more research on
Hi Heiko,
On Sat, 19 Apr 2014, Heiko Voigt wrote:
Regarding mingwGitDevEnv[2]: That is a project started by Sebastian who
also contributes to msysgit (and Git for Windows).
In fact, Sebastian is not only a contributor. He is co-maintainer of Git
for Windows.
It eventually can (and probably
On Mon, 21 Apr 2014, Johannes Schindelin wrote:
(I also would like to look into getting the performance improvement
Hannes Sixt achieved by his patch [*1*] into mingwGitDevEnv's Git
installation, too.)
Whoops. Footnote *1*: https://github.com/msysgit/msysgit/commit/a0f5d4f
--
To unsubscribe
Hi Sebastian,
On Mon, 21 Apr 2014, Sebastian Schuberth wrote:
On 21.04.2014 00:10, Johannes Schindelin wrote:
tests do not pass yet. (I also would like to look into getting the
performance improvement Hannes Sixt achieved by his patch [*1*] into
mingwGitDevEnv's Git installation, too
Hi,
On Mon, 21 Apr 2014, Felipe Contreras wrote:
Johannes Schindelin wrote:
Now, clearly you have all the motivation that is needed to get 64-bit
builds of Git for Windows going, and all the motivation required to make
sure that the MSVC support of the msysGit project works.
s/msysGit
Hi Marat,
On Tue, 22 Apr 2014, Marat Radchenko wrote:
Johannes says building mingw64 Git is dirt-easy.
Marat, please let's stop misquoting me, okay?
What I said was more along the lines that there had been some start of a
work on getting things to compile for 64-bit Windows, but that the test
Hi Felipe,
On Tue, 22 Apr 2014, Felipe Contreras wrote:
Johannes Schindelin wrote:
On Mon, 21 Apr 2014, Felipe Contreras wrote:
Johannes Schindelin wrote:
Now, clearly you have all the motivation that is needed to get 64-bit
builds of Git for Windows going, and all the motivation
Hi,
On Wed, 23 Apr 2014, Stepan Kasal wrote:
I have found out that ulimit -s does not work on Windows.
Adding this as a prerequisite, we will skip the test there.
The interdiff can be seen here:
https://github.com/msysgit/git/commit/c68e27d5
Ciao,
Johannes
--
To unsubscribe from
Hi Peff,
On Wed, 23 Apr 2014, Jeff King wrote:
On Wed, Apr 23, 2014 at 09:53:25AM +0200, Stepan Kasal wrote:
I have found out that ulimit -s does not work on Windows. Adding
this as a prerequisite, we will skip the test there.
I found this bit weird, as the test originated on Windows.
Hi kusma,
On Mon, 28 Apr 2014, Erik Faye-Lund wrote:
On Mon, Apr 28, 2014 at 10:48 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
So it seems that 08900987 (Decide whether to build http-push in the
Makefile) makes a bad assumption about the availability of
curl-config on new libcurl
Hi kusma,
On Wed, 30 Apr 2014, Erik Faye-Lund wrote:
While it's certainly a good point, I think this is *our* fault for not
upstreaming our changes, and the responsibility of cleaning up merges
should lie on our shoulders. We've diverged a lot. Sure, Dscho does a
great job making the
Hi kusma,
On Wed, 30 Apr 2014, Erik Faye-Lund wrote:
We can keep this patch in the msysGit repo for the 2.0 release.
FWIW the plan is to switch to mingwGitDevEnv for the 2.0 release. It is
not quite clear as of yet how patches will be managed with said
environment.
Ciao,
Johannes
--
To
Hi Peff,
On Wed, 14 May 2014, Jeff King wrote:
On Wed, May 14, 2014 at 05:44:19PM +0200, Stepan Kasal wrote:
From: Johannes Schindelin johannes.schinde...@gmx.de
Date: Mon, 8 Nov 2010 16:10:43 +0100
Incidentally, this makes grep -I respect the binary attribute (actually,
the -text
Hi Junio,
On Wed, 14 May 2014, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
+ if (opt.ignore_case !strcmp(less, pager))
+ string_list_append(path_list, -i);
I have a feeling that this goes against the recent trend of not
mucking with the
Hi Peff,
On Wed, 14 May 2014, Jeff King wrote:
On Wed, May 14, 2014 at 11:26:54AM -0700, Jonathan Nieder wrote:
git grep has other options that affect interpretation of the pattern
which this patch does not help with:
* -v / --ignore-match: probably should disable this feature of
Hi,
On Thu, 15 May 2014, Stepan Kasal wrote:
From: Sverre Rabbelier srabbel...@gmail.com
Date: Sat, 28 Aug 2010 20:49:01 -0500
[PT: ensure we add an additional element to the argv array]
IIRC we had problems with refs vs file names.
Ciao,
Johannes
--
To unsubscribe from this list: send
Hi,
On Thu, 15 May 2014, Jonathan Nieder wrote:
Johannes Schindelin wrote:
On Wed, 14 May 2014, Junio C Hamano wrote:
Spot on. The change, especially with -I, makes sense.
Except that it was not tested with -I. If you change it that way and it
stops working on Windows, it's useless
.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
t/t5302-pack-index.sh | 19 +++
1 file changed, 19 insertions(+)
diff --git a/t/t5302-pack-index.sh b/t/t5302-pack-index.sh
index 4bbb718..80bd3ee 100755
--- a/t/t5302-pack-index.sh
+++ b/t/t5302-pack-index.sh
The intent of the two new test cases is to catch general breakages in
the fsck_tag() function, not so much to test it extensively, trying to
strike the proper balance between thoroughness and speed.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
t/t1450-fsck.sh | 39
In the next commits, we will enhance the fsck_tag() function to check
tag objects more thoroughly. To this end, we need a function to verify
that a given string is a valid object type, but that does not die() in
the negative case.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
handling of tag
objects.
The assumption that such buffers are inherently NUL terminated is now
wrong, of course, hence we pass the size of the buffer so that we can
add a sanity check later, to prevent running past the end of the buffer.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
prematurely, and consequently we can get away with the current string
comparisons even with non-NUL-terminated buffers are passed to
fsck_object().
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
fsck.c | 23 +++
1 file changed, 23 insertions(+)
diff --git
We inspect commit objects pretty much in detail in git-fsck, but we just
glanced over the tag objects. Let's be stricter.
This work was sponsored by GitHub Inc.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
fsck.c | 88
in a NUL.
This work was sponsored by GitHub.
Johannes Schindelin (5):
Refactor type_from_string() to avoid die()ing in case of errors
fsck: inspect tag objects more closely
Add regression tests for stricter tag fsck'ing
Refactor out fsck_object_buffer() accepting the object data
Make
handling of tag
objects.
The assumption that such buffers are inherently NUL terminated is now
wrong, of course, hence we pass the size of the buffer so that we can
add a sanity check later, to prevent running past the end of the buffer.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
. strings
with an explicitly specified length rather than a NUL termination.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
object.c | 11 +--
object.h | 3 ++-
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/object.c b/object.c
index a16b9f9..aedac24
with the code, and IIRC the problematic unit test
that revealed that these buffers are not always NUL-terminated exercised the
unpack-objects code path, not index-pack, again nothing I wanted to let
delay this patch series any further).
Johannes Schindelin (6):
Refactor type_from_string
We inspect commit objects pretty much in detail in git-fsck, but we just
glanced over the tag objects. Let's be stricter.
Since we do not want to limit 'tag' lines unduly, values that would fail
the refname check only result in warnings, not errors.
Signed-off-by: Johannes Schindelin
prematurely, and consequently we can get away with the current string
comparisons even with non-NUL-terminated buffers are passed to
fsck_object().
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
fsck.c | 23 +++
1 file changed, 23 insertions(+)
diff --git
.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
t/t5302-pack-index.sh | 19 +++
1 file changed, 19 insertions(+)
diff --git a/t/t5302-pack-index.sh b/t/t5302-pack-index.sh
index 4bbb718..80bd3ee 100755
--- a/t/t5302-pack-index.sh
+++ b/t/t5302-pack-index.sh
The intent of the two new test cases is to catch general breakages in
the fsck_tag() function, not so much to test it extensively, trying to
strike the proper balance between thoroughness and speed.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
t/t1450-fsck.sh | 39
Hi Junio,
On Wed, 10 Sep 2014, Johannes Schindelin wrote:
Still unaddressed:
- getting rid of struct object altogether in fsck (I felt this was quite a big
task, getting much more familiar with the non-tag code paths, and I did not
want to delay this patch series up any further
Hi Junio,
On Wed, 10 Sep 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
diff --git a/fsck.c b/fsck.c
index dd77628..9dd7d12 100644
--- a/fsck.c
+++ b/fsck.c
@@ -237,6 +237,26 @@ static int fsck_tree(struct tree *item, int strict,
fsck_error
Hi Junio,
On Wed, 10 Sep 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
+ test_when_finished git update-ref -d refs/tags/wrong
+ git fsck --tags 2out
I wonder what the command does with or without --tags option
(applies to both tests added
Hi,
On Wed, 10 Sep 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
+tag=$(git hash-object -t tag -w --stdin wrong-tag)
+pack1=$(echo $tag | git pack-objects tag-test)
+echo remove tag object
+thirtyeight=${tag#??}
+rm -f
handling of tag
objects.
The assumption that such buffers are inherently NUL terminated is now
wrong, of course, hence we pass the size of the buffer so that we can
add a sanity check later, to prevent running past the end of the buffer.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
. strings
with an explicitly specified length rather than a NUL termination.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
object.c | 11 +--
object.h | 3 ++-
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/object.c b/object.c
index a16b9f9..aedac24
-pack, again nothing I wanted to let
delay this patch series any further).
Johannes Schindelin (6):
Refactor type_from_string() to avoid die()ing in case of errors
Accept object data in the fsck_object() function
Make sure fsck_commit_buffer() does not run out of the buffer
fsck: check tag
prematurely, and consequently we can get away with the current string
comparisons even with non-NUL-terminated buffers are passed to
fsck_object().
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
fsck.c | 23 +++
1 file changed, 23 insertions(+)
diff --git
would
have to actively *break* pack-index in order to test this. Or rewrite
both hash-object and pack-index in shell script. Ain't gonna happen.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
t/t5302-pack-index.sh | 19 +++
1 file changed, 19 insertions(+)
diff
Hi Junio,
On Wed, 10 Sep 2014, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Johannes Schindelin johannes.schinde...@gmx.de writes:
This patch series introduces detailed checking of tag objects when calling
git fsck, and also when transfer.fsckobjects is set to true
We inspect commit objects pretty much in detail in git-fsck, but we just
glanced over the tag objects. Let's be stricter.
Since we do not want to limit 'tag' lines unduly, values that would fail
the refname check only result in warnings, not errors.
Signed-off-by: Johannes Schindelin
#??}
mkdir -p .git/objects/${sha1%$suffix}
echo $contents |
perl -MCompress::Zlib -e 'undef $/; print compress()' \
.git/objects/${sha1%$suffix}/$suffix
echo $sha1
}
Signed-off-by: Johannes Schindelin johannes.schinde
Hi Junio,
On Thu, 11 Sep 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
On Wed, 10 Sep 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
+tag=$(git hash-object -t tag -w --stdin wrong-tag)
+pack1
Hi Junio,
On Thu, 11 Sep 2014, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
When our toolset has become too tight without leaving enough escape
hatch to hinder further development, it is very sensible to at least
think about adding a new --for-debug option to
handling of tag
objects.
The assumption that such buffers are inherently NUL terminated is now
wrong, of course, hence we pass the size of the buffer so that we can
add a sanity check later, to prevent running past the end of the buffer.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
prematurely, and consequently we can get away with the current string
comparisons even with non-NUL-terminated buffers are passed to
fsck_object().
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
fsck.c | 23 +++
1 file changed, 23 insertions(+)
diff --git
contain an end of header (i.e. an empty line) to
guarantee that our checks do not run beyond the buffer.
This work was sponsored by GitHub.
Changes since v3:
- removed undesired negativity from commit message
- removed space in '2 err'
Johannes Schindelin (6):
Refactor type_from_string() to avoid
. strings
with an explicitly specified length rather than a NUL termination.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
object.c | 11 +--
object.h | 3 ++-
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/object.c b/object.c
index a16b9f9..aedac24
We inspect commit objects pretty much in detail in git-fsck, but we just
glanced over the tag objects. Let's be stricter.
Since we do not want to limit 'tag' lines unduly, values that would fail
the refname check only result in warnings, not errors.
Signed-off-by: Johannes Schindelin
#??}
mkdir -p .git/objects/${sha1%$suffix}
echo $contents |
perl -MCompress::Zlib -e 'undef $/; print compress()' \
.git/objects/${sha1%$suffix}/$suffix
echo $sha1
}
Signed-off-by: Johannes Schindelin johannes.schinde
a 'tagger' line.
Technically, this test is not enough: it only exercises a code path that
*warns*, not one that *fails*. The reason is that hash-object and
pack-objects both insist on parsing the tag objects and would fail on
invalid tag objects at this time.
Signed-off-by: Johannes Schindelin
Hi Junio,
On Fri, 12 Sep 2014, Junio C Hamano wrote:
Thanks. I think this is ready for 'next' and then down to 'master'
for the next release.
Thank you!
Dscho
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo
Hi Marat,
On Sun, 28 Sep 2014, Marat Radchenko wrote:
This patch series fixes building on modern MinGW and MinGW-W64
(including x86_64!).
Awesome work! I'll have a look at it as soon as I can!
Ciao,
Johannes
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a
Hi Marat,
On Wed, 8 Oct 2014, Marat Radchenko wrote:
On Wed, Oct 08, 2014 at 01:09:20AM +0200, Thomas Braun wrote:
I wanted to verify that on msysgit but some patches fail to apply
cleanly. Did you also had to tweak the patches?
If yes, are these tweaked patches still available
Hi Thomas,
On Wed, 8 Oct 2014, Thomas Braun wrote:
I wanted to verify that on msysgit but some patches fail to apply
cleanly. Did you also had to tweak the patches?
I applied the patches to git-for-windows/git's master, manually fixing
three of them, and pushed the result to the 'w64' branch
Hi all,
On Tue, 30 Sep 2014, Marat Radchenko wrote:
This patch series fixes building on modern MinGW and MinGW-W64
(including x86_64!).
To make it easier to review and substantially easier to work on this patch
series with Git, I opened a pull request on GitHub:
Hi Marat,
On Wed, 8 Oct 2014, Marat Radchenko wrote:
On Wed, Oct 08, 2014 at 10:59:57AM +0200, Johannes Schindelin wrote:
So the idea would be to rebase from git/git/master onto
msysgit/git/master. Did you do that yet?
No, what for?
To work together?
If you are not interested
Hi Marat,
On Wed, 8 Oct 2014, Marat Radchenko wrote:
On Wed, Oct 08, 2014 at 11:40:17AM +0200, Johannes Schindelin wrote:
To make it easier to review and substantially easier to work on this patch
series with Git, I opened a pull request on GitHub:
https://github.com/msysgit/git
Hi Junio,
On Wed, 8 Oct 2014, Junio C Hamano wrote:
Marat Radchenko ma...@slonopotamus.org writes:
#define DEFAULT_PACKED_GIT_LIMIT \
- ((1024L * 1024L) * (sizeof(void*) = 8 ? 8192 : 256))
+ ((size_t)(1024L * 1024L) * (sizeof(void*) = 8 ? 8192 : 256))
1024 * 1024 * 8192
Hi Junio,
On Thu, 9 Oct 2014, Junio C Hamano wrote:
Marat Radchenko ma...@slonopotamus.org writes:
On Wed, Oct 08, 2014 at 12:26:52PM -0700, Junio C Hamano wrote:
...
What I am wondering is if it is a better solution to make it easier
to allow somebody who is cross compiling to
forcing them to use an unstable version of MinGW-w64.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
compat/poll/poll.c | 12
1 file changed, 12 insertions(+)
diff --git a/compat/poll/poll.c b/compat/poll/poll.c
index 8941249..dcbcbaf 100644
--- a/compat/poll/poll.c
Hi Junio,
On Thu, 9 Oct 2014, Junio C Hamano wrote:
Isn't the primary reason we use colon-assign to avoid running the same
$(shell) over and over again every time $(uname_?) gets referenced? How
would it work with ?= ???
I was under the impression that ?= would only define the variable once,
Hi Junio,
On Thu, 9 Oct 2014, Junio C Hamano wrote:
I didn't mean multiple uses of ?= for the same variable. I meant
multiple uses of (references to) the variable. I.e. wouldn't FOO and
BAR behave differently below?
FOO := $(shell random)
BAR = $(shell random)
all::
echo $(FOO) and
Hi,
On Wed, 8 Oct 2014, Marat Radchenko wrote:
+CC_MACH := $(shell sh -c '$(CC) -dumpmachine 2/dev/null || echo not')
There is a rather huge problem with that. The latest mingw-w64 release,
4.9.1, does not do what you expect here: while '.../mingw32/bin/gcc -m32
-o 32.exe test.c' and
Hi Ray,
On Thu, 9 Oct 2014, Ray Donnelly wrote:
On Thu, Oct 9, 2014 at 8:22 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
On Wed, 8 Oct 2014, Marat Radchenko wrote:
+CC_MACH := $(shell sh -c '$(CC) -dumpmachine 2/dev/null || echo not')
There is a rather huge problem
Hi Ray,
On Fri, 10 Oct 2014, Ray Donnelly wrote:
On Thu, Oct 9, 2014 at 8:47 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
On Thu, 9 Oct 2014, Ray Donnelly wrote:
On Thu, Oct 9, 2014 at 8:22 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
On Wed, 8 Oct
Hi,
On Fri, 10 Oct 2014, Johannes Schindelin wrote:
With this [mingw-w64] compiler, and the 'w64' branch from
https://github.com/dscho/git – intended to be merged into
https://github.com/git-for-windows/git – the following command-line
produces 64-bit Git:
PATH=/path/to/unpacked
Hi Ray,
On Fri, 10 Oct 2014, Ray Donnelly wrote:
what's the difference between https://github.com/msysgit/git and
https://github.com/git-for-windows/git ? I noticed that your fork is
forked from msysgit, not git-for-windows?
I am glad you asked!
Git for Windows was developed using the
Hi,
On Fri, 10 Oct 2014, Johannes Schindelin wrote:
On Fri, 10 Oct 2014, Johannes Schindelin wrote:
With this [mingw-w64] compiler, and the 'w64' branch from
https://github.com/dscho/git – intended to be merged into
https://github.com/git-for-windows/git – the following command-line
Hi Michael,
On Mon, 13 Oct 2014, Michael Stefaniuc wrote:
On 10/10/2014 02:04 PM, Duy Nguyen wrote:
On Fri, Oct 10, 2014 at 7:02 PM, Thomas Braun
Are you compiling git.git or msysgit.git?
git.git
And how about the test suite?
running right now, fingers crossed.. kinda slow,
Hi,
On Thu, 16 Oct 2014, Thomas Braun wrote:
Am 16.10.2014 um 21:29 schrieb Torsten Bögershausen:
core.filemode is set automatically when a repo is created.
But when a repo is exported via CIFS or cygwin is mixed with Git for Windows
core.filemode may better be set manually to false.
in which in particular the 'updateInstead' setting became a
boon in this developer's daily work is a multi-laptop one, where working
directories need to be updated between computers without a hassle.
Johannes Schindelin (2):
Add a few more values for receive.denyCurrentBranch
Let deny.currentBranch
-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
Documentation/config.txt | 5 +
builtin/receive-pack.c | 58 ++--
t/t5516-fetch-push.sh| 36 ++
3 files changed, 97 insertions(+), 2 deletions(-)
diff --git
They are not affected by the update anyway.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
builtin/receive-pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index be4172f..4ba51df 100644
--- a/builtin
Hi Junio,
On Fri, 7 Nov 2014, Junio C Hamano wrote:
[...]
I will address your concerns after the weekend.
Ciao,
Johannes
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hi Junio,
On Fri, 7 Nov 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
Under certain circumstances, it makes a *lot* of sense to allow pushing
into the current branch. For example, when two machines with different
Operating Systems are required
Hi Junio,
On Fri, 7 Nov 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
builtin/receive-pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/receive
Hi Peff,
On Sat, 8 Nov 2014, Jeff King wrote:
On Fri, Nov 07, 2014 at 02:58:17PM +0100, Johannes Schindelin wrote:
Under certain circumstances, it makes a *lot* of sense to allow pushing
into the current branch. For example, when two machines with different
Operating Systems
Hi Jens,
On Sun, 9 Nov 2014, Jens Lehmann wrote:
Am 07.11.2014 um 20:20 schrieb Junio C Hamano:
Johannes Schindelin johannes.schinde...@gmx.de writes:
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
builtin/receive-pack.c | 2 +-
1 file changed, 1 insertion
1 - 100 of 5954 matches
Mail list logo
