On 2014-08-12 01:10:28 Andrew Crabtree wrote:
I'm seeing some oddity in one of my repositories where the root commit is
being output in 'rev-list' even
when I pass in a reference that should exclude it from being output.
...
Seeing the issue with versions of git from 1.7 to 2.1.
I have a
On Aug 14, 2014, at 16:18, Junio C Hamano wrote:
Markus Hitter m...@jump-ing.de writes:
The CommonCrypto/CommonHMAC.h is in Mac OS X 10.6 .. 10.9,
but not in 10.4 (I don't know about 10.5).
That header is new with 10.5
Is this about platform dependency, or what the end user happens to
On Fri, Aug 15, 2014 at 3:46 AM, Kyle J. McKay mack...@gmail.com wrote:
On Aug 14, 2014, at 16:18, Junio C Hamano wrote:
Markus Hitter m...@jump-ing.de writes:
The CommonCrypto/CommonHMAC.h is in Mac OS X 10.6 .. 10.9,
but not in 10.4 (I don't know about 10.5).
That header is new with
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
So I think the reasoning (i.e. is a descendant is not quite right)
is correct, but the updated text is not quite right. Changing it
further to only the committer timestamps and identities would
change is
On Fri, Aug 15, 2014 at 2:56 AM, Jeff King p...@peff.net wrote:
I think this is a fine fix for this specific problem, and we should
apply it. But I do wonder if it would be simpler in the long run to
treat verbosity as a global option, and pass it around via a GIT_QUIET
(or GIT_VERBOSITY)
On Fri, Aug 15, 2014 at 12:00 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
diff --git a/t/t1050-large.sh b/t/t1050-large.sh
index 711f22c..b294963 100755
--- a/t/t1050-large.sh
+++ b/t/t1050-large.sh
@@ -116,6 +116,14 @@ test_expect_success
Am 15.08.2014 um 09:46 schrieb Kyle J. McKay:
The below patch does the right thing. Conveniently there's already
a test for 10.4 and earlier so only a single line need be added.
I can confirm this patch works. Thank you very much.
8
Subject: [PATCH] config.mak.uname: set
Am 15.08.2014 um 00:29 schrieb Jonathan Nieder:
Orthogonal to that: a patch to the Darwin section of config.mak.uname
so you can build without the 'make configure' would be even more
welcome. :)
On this one. You need at least NO_GETTEXT and NO_EXPAT. I've attached a
config.mak.autogen to show
Hi Folks,
I'm trying to understand the behavior of git blame -M and find that the actual
results differ from what I understood from the documentation. I've already
asked longer time ago on stackoverflow and on the user mailing list without any
satisfactory results. So here is the example:
Sokolov, Konstantin (ext) konstantin.sokolov@siemens.com writes:
Hi Folks,
I'm trying to understand the behavior of git blame -M and find that
the actual results differ from what I understood from the
documentation. I've already asked longer time ago on stackoverflow and
on the user
Kyle J. McKay mack...@gmail.com writes:
On Aug 14, 2014, at 16:18, Junio C Hamano wrote:
Markus Hitter m...@jump-ing.de writes:
The CommonCrypto/CommonHMAC.h is in Mac OS X 10.6 .. 10.9,
but not in 10.4 (I don't know about 10.5).
That header is new with 10.5
Is this about platform
Kyle J. McKay mack...@gmail.com writes:
The below patch does the right thing. Conveniently there's already
a test for 10.4 and earlier so only a single line need be added.
--Kyle
8
Subject: [PATCH] config.mak.uname: set NO_APPLE_COMMON_CRYPTO on older systems
Older MacOS
Sokolov, Konstantin (ext) konstantin.sokolov@siemens.com
writes:
git blame -s -n -f -w -M20 file.txt
^2cd9f7f 1 1) A
^2cd9f7f 3 2) 2
^2cd9f7f 4 3)
Hi,
the Git for Windows team just released the second maintenance release of
the Windows-specific installers for git 1.9.4.
It can be downloaded from the usual place [1] and I also attached some
(although non-gpg signed) SHA sums [2].
New Features
Comes with Git 1.9.4 plus
Sergey Organov sorga...@gmail.com writes:
...
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 2a93c64..f14100a 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -316,11 +316,8 @@ which makes little sense.
-f::
On Aug 15, 2014, at 10:02, Junio C Hamano wrote:
By the way, can we document this uname_R on MacOS X business
nearby, perhaps like this?
-- 8 --
Subject: config.mak.uname: add hint on uname_R for MacOS X
I always have to scratch my head every time I see this cryptic
pattern [15678]\.; leave a
Kyle J. McKay mack...@gmail.com writes:
+# i.e. begins with [15678] and the a dot means 10.4.* or older.
s/the a dot/a dot/
ifeq ($(shell expr $(uname_R) : '[15678]\.'),2)
OLD_ICONV = UnfortunatelyYes
NO_APPLE_COMMON_CRYPTO = YesPlease
Otherwise looks
On Aug 15, 2014, at 11:04, Junio C Hamano wrote:
The 10.1.0 anomaly actually was bothering me, too. How
about doing it this way?
-- 8 --
Subject: [PATCH v2] config.mak.uname: add hint on uname_R for MacOS X
I always have to scratch my head every time I see this cryptic
pattern [15678]\.;
Am 15.08.2014 19:14, schrieb Thomas Braun:
Hi,
the Git for Windows team just released the second maintenance release of
the Windows-specific installers for git 1.9.4.
Thank you so much!
Regressions
git svn is/might be broken. Fixes welcome.
rebase -b 0x6400
On Thu, Aug 14, 2014 at 1:04 AM, Junio C Hamano gits...@pobox.com wrote:
Being a conservative, I'd rather avoid doing any magic during
read_cache() time. ls-files -s for example should show the four
stages so that the broken state can be inspected.
Well, only read_cache_unmerged() is modified
Junio C Hamano gits...@pobox.com writes:
Sergey Organov sorga...@gmail.com writes:
...
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 2a93c64..f14100a 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -316,11 +316,8 @@ which
Hi David,
thank you very much for the exhaustive answer. The keyword hunk made me try a
little bit more. So I realized that -M works as expected when at least three
lines are moved.
From your answer I discern that you find the current behavior correct. In my
opinion, it diverges at least
No. The distance seems to have no influence. In the meantime I've found out (as
mentioned in my other reply) that the movements are detected if at least three
lines are moved.
-Ursprüngliche Nachricht-
Von: Junio C Hamano [mailto:gits...@pobox.com]
Gesendet: Freitag, 15. August 2014
Jaime Soriano Pastor jsorianopas...@gmail.com writes:
On Thu, Aug 14, 2014 at 1:04 AM, Junio C Hamano gits...@pobox.com wrote:
Being a conservative, I'd rather avoid doing any magic during
read_cache() time. ls-files -s for example should show the four
stages so that the broken state can be
Sergey Organov sorga...@gmail.com writes:
A sentence --force has no effect under --preserve-merges mode does
not tell the readers very much, either and leaves them wondering if
it means --preserve-merges mode always rebases every time it is
asked, never noticing 'ah, the history is already in
The latest feature release Git v2.1.0 is now available at the
usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.1.0'
tag and the 'master' branch that the tag points at:
url =
On Fri, Aug 15, 2014 at 03:46:29PM -0700, Junio C Hamano wrote:
The latest feature release Git v2.1.0 is now available at the
usual places.
I pulled down git v2.1.0, and when I tried to build it via:
make prefix=/usr/local profile-fast
The build died with this:
cannot open
On Fri, Aug 15, 2014 at 9:42 PM, David Kastrup d...@gnu.org wrote:
The function diff_hunks is a wrapper for the diff engine. Putting the
context length explicitly into this wrapper (rather than not passing an
argument and just setting the context length to zero anyway in the
function) clearly
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/fetch.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index e8d0cca..5f06114 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -1110,9 +1110,7 @@ int cmd_fetch(int
Noticed-by: Matthew Flaschen mflasc...@wikimedia.org
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/fetch.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 5f06114..159fb7e 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@
Since v3:
- rename xmallocz_gentle to xmallocz_gently
- drop the unpack-objects patch
- fix allways type
Nguyễn Thái Ngọc Duy (5):
wrapper.c: introduce gentle xmallocz that does not die()
sha1_file.c: do not die failing to malloc in unpack_compressed_entry
diff.c: allow to pass more
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
git-compat-util.h | 1 +
wrapper.c | 68 ++-
2 files changed, 53 insertions(+), 16 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index f587749..8785fd3 100644
Too large files may lead to failure to allocate memory. If it happens
here, it could impact quite a few commands that involve
diff. Moreover, too large files are inefficient to compare anyway (and
most likely non-text), so mark them binary and skip looking at their
content.
Noticed-by: Dale R.
If we are given two SHA-1 and asked to determine if they are different
(but not _what_ differences), we know right away by comparing SHA-1.
A side effect of this patch is, because large files are marked binary,
diff-tree will not need to unpack them. 'diff-index --cached' will not
either. But
Fewer die() gives better control to the caller, provided that the
caller _can_ handle it. And in unpack_compressed_entry() case, it can,
because unpack_compressed_entry() already returns NULL if it fails to
inflate data.
A side effect from this is fsck continues to run when very large blobs
are
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
diff.c| 13 +++--
diffcore-rename.c | 6 --
diffcore.h| 3 ++-
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/diff.c b/diff.c
index
36 matches
Mail list logo
