Re: Problem with Git rev-list output
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 small test repo on GitHub that demonstrates the problem. I expect it is caused by the commit dates being out of sequence: 1. Clone the revlist repo: # git clone https://github.com/pcharlan/revlist.git Cloning into 'revlist'... 2. master has six commits (with out-of-order dates): # git log --pretty='%h %cd' master 0f9e594 Sun May 20 01:01:01 2007 -0700 1ad887b Sun May 20 01:01:01 2007 -0700 cde7188 Sun May 20 01:01:01 2007 -0700 51af1c0 Sun May 20 01:01:01 2007 -0700 -- date seven years ago 0e080e8 Tue Aug 12 11:51:19 2014 -0700 -- present day 77ce973 Fri May 20 01:01:01 2011 -0700 -- three years ago 3. Pruning master with origin/other (a branch with the same root and also out-of-order dates) has no effect, counter to expectation: # git log --pretty='%h %cd' master ^origin/other 0f9e594 Sun May 20 01:01:01 2007 -0700 1ad887b Sun May 20 01:01:01 2007 -0700 cde7188 Sun May 20 01:01:01 2007 -0700 51af1c0 Sun May 20 01:01:01 2007 -0700 0e080e8 Tue Aug 12 11:51:19 2014 -0700 77ce973 Fri May 20 01:01:01 2011 -0700 --- Reachable from origin/other 4. Pruning master with the parent of origin/other removes the root commit: # git log --pretty='%h %cd' master ^origin/other~ 0f9e594 Sun May 20 01:01:01 2007 -0700 1ad887b Sun May 20 01:01:01 2007 -0700 cde7188 Sun May 20 01:01:01 2007 -0700 51af1c0 Sun May 20 01:01:01 2007 -0700 0e080e8 Tue Aug 12 11:51:19 2014 -0700 Q: Is this expected behavior? If so, and assuming that it's the dates that are throwing Git off, is there a way to tell Git to not care about the dates, or to care less than it does? Thanks, --Pete Peter Harlan HP Networking -- 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 http://vger.kernel.org/majordomo-info.html
Re: Git on Mac OS X 10.4.10
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 choose to install (in other words, is there an add-on users of 10.4 can choose to add, which allows them to use that header)? Nope, it's a platform dependency. Not available prior to 10.5. 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 systems prior to 10.5 do not have the CommonCrypto support Git uses so set NO_APPLE_COMMON_CRYPTO on those systems. Signed-off-by: Kyle J. McKay mack...@gmail.com --- config.mak.uname | 1 + 1 file changed, 1 insertion(+) diff --git a/config.mak.uname b/config.mak.uname index 7846bd76..f8e12c96 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -88,6 +88,7 @@ ifeq ($(uname_S),Darwin) NEEDS_LIBICONV = YesPlease ifeq ($(shell expr $(uname_R) : '[15678]\.'),2) OLD_ICONV = UnfortunatelyYes + NO_APPLE_COMMON_CRYPTO = YesPlease endif ifeq ($(shell expr $(uname_R) : '[15]\.'),2) NO_STRLCPY = YesPlease -- 1.8.5 -- 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 http://vger.kernel.org/majordomo-info.html
Re: Git on Mac OS X 10.4.10
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 10.5 Is this about platform dependency, or what the end user happens to choose to install (in other words, is there an add-on users of 10.4 can choose to add, which allows them to use that header)? Nope, it's a platform dependency. Not available prior to 10.5. 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 tested with Mac OS X 10.5 (and 10.9) to verify that there is no regression. Works fine. --Kyle 8 Subject: [PATCH] config.mak.uname: set NO_APPLE_COMMON_CRYPTO on older systems Older MacOS systems prior to 10.5 do not have the CommonCrypto support Git uses so set NO_APPLE_COMMON_CRYPTO on those systems. Signed-off-by: Kyle J. McKay mack...@gmail.com --- config.mak.uname | 1 + 1 file changed, 1 insertion(+) diff --git a/config.mak.uname b/config.mak.uname index 7846bd76..f8e12c96 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -88,6 +88,7 @@ ifeq ($(uname_S),Darwin) NEEDS_LIBICONV = YesPlease ifeq ($(shell expr $(uname_R) : '[15678]\.'),2) OLD_ICONV = UnfortunatelyYes + NO_APPLE_COMMON_CRYPTO = YesPlease endif ifeq ($(shell expr $(uname_R) : '[15]\.'),2) NO_STRLCPY = YesPlease -- 1.8.5 -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.
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 probably not an improvement, either. Force the rebase that would otherwise be a no-op may be a better phrasing that does not risk going stale even if we update what are preserved and what are modified in the future. Also I notice the sentence Normally non-interactive...in such a situation is not helping the reader in this description very much. I wonder if we should keep it if we are rewriting this paragraph. How about doing it this way, perhaps? -- 8 -- From: Sergey Organov sorga...@gmail.com Date: Tue, 12 Aug 2014 00:22:48 +0400 Subject: [PATCH] Documentation/git-rebase.txt: -f forces a rebase that would otherwise be a no-op Current branch is a descendant of the commit you are rebasing onto does not necessarily mean rebase requires --force. For a plain vanilla history flattening rebase, the rebase can be done without forcing if there is a merge between the tip of the branch being rebased and the commit you are rebasing onto, even if the tip is descendant of the other. [jc: reworded both the text and the log description] Signed-off-by: Sergey Organov sorga...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/git-rebase.txt | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) 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:: --force-rebase:: - Force the rebase even if the current branch is a descendant - of the commit you are rebasing onto. Normally non-interactive rebase will - exit with the message Current branch is up to date in such a - situation. - Incompatible with the --interactive option. + Force a rebase even if the current branch is up-to-date and + the command without `--force` would return without doing anything. + You may find this (or --no-ff with an interactive rebase) helpful after reverting a topic branch merge, as this option recreates the topic branch 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 probably not an improvement, either. Force the rebase that would otherwise be a no-op may be a better phrasing that does not risk going stale even if we update what are preserved and what are modified in the future. Also I notice the sentence Normally non-interactive...in such a situation is not helping the reader in this description very much. I wonder if we should keep it if we are rewriting this paragraph. How about doing it this way, perhaps? -- 8 -- From: Sergey Organov sorga...@gmail.com Date: Tue, 12 Aug 2014 00:22:48 +0400 Subject: [PATCH] Documentation/git-rebase.txt: -f forces a rebase that would otherwise be a no-op Current branch is a descendant of the commit you are rebasing onto does not necessarily mean rebase requires --force. For a plain vanilla history flattening rebase, the rebase can be done without forcing if there is a merge between the tip of the branch being rebased and the commit you are rebasing onto, even if the tip is descendant of the other. [jc: reworded both the text and the log description] Signed-off-by: Sergey Organov sorga...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/git-rebase.txt | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) 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:: --force-rebase:: - Force the rebase even if the current branch is a descendant - of the commit you are rebasing onto. Normally non-interactive rebase will - exit with the message Current branch is up to date in such a - situation. - Incompatible with the --interactive option. + Force a rebase even if the current branch is up-to-date and + the command without `--force` would return without doing anything. + You may find this (or --no-ff with an interactive rebase) helpful after reverting a topic branch merge, as this option recreates the topic branch with I dig more into it, and that's what I came up with, using some of your suggestions as well. Please notice new text on essential interaction with --preserve-merges. I also thought about
Re: [PATCH 2/2] fetch: silence git-gc if --quiet is given
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) environment variable. I would not be surprised at all to find that there are other cases where sub-programs do not respect the parent verbosity (I know we have had problems with progress reporting flags carried over the transport interface in the past, but I think we fixed all of those). I don't see any easy way to make everybody aware of $GIT_QUIET. But the idea is nice. -- Duy -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/6] diff: shortcut for diff'ing two binary SHA-1 objects
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 'diff --stat' ' git diff --stat HEAD^ HEAD ' +test_expect_success 'diff' ' + git diff HEAD^ HEAD +' + +test_expect_success 'diff --cached' ' + git diff --cached HEAD^ +' What are these checking? No check for their outcome? The first test in this file set $GIT_ALLOC_LIMIT and these commands would not succeed without the patch. But yes I can check the binary files differ too. -- Duy -- 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 http://vger.kernel.org/majordomo-info.html
Re: Git on Mac OS X 10.4.10
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 NO_APPLE_COMMON_CRYPTO on older systems Older MacOS systems prior to 10.5 do not have the CommonCrypto support Git uses so set NO_APPLE_COMMON_CRYPTO on those systems. Signed-off-by: Kyle J. McKay mack...@gmail.com --- config.mak.uname | 1 + 1 file changed, 1 insertion(+) diff --git a/config.mak.uname b/config.mak.uname index 7846bd76..f8e12c96 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -88,6 +88,7 @@ ifeq ($(uname_S),Darwin) NEEDS_LIBICONV = YesPlease ifeq ($(shell expr $(uname_R) : '[15678]\.'),2) OLD_ICONV = UnfortunatelyYes + NO_APPLE_COMMON_CRYPTO = YesPlease endif ifeq ($(shell expr $(uname_R) : '[15]\.'),2) NO_STRLCPY = YesPlease -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ -- 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 http://vger.kernel.org/majordomo-info.html
Re: Git on Mac OS X 10.4.10
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 what's needed.
However, if somebody chooses to install gettext or expat after OS installation,
how is the build process expected to detect this? IMHO, checking for OS version
number instead of actually available features is the wrong thing to do.
Markus
--
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/
# git Makefile configuration, included in main Makefile
# config.mak.autogen. Generated from config.mak.in by configure.
CC = cc
CFLAGS = -g -O2
CPPFLAGS =
LDFLAGS =
AR = ar
TAR = tar
DIFF = diff
PACKAGE_TARNAME = git
#INSTALL = @INSTALL@# needs install-sh or install.sh in sources
prefix = /usr/local
exec_prefix = ${prefix}
bindir = ${exec_prefix}/bin
gitexecdir = ${exec_prefix}/libexec/git-core
datarootdir = @datarootdir@
template_dir = ${prefix}/share/git-core/templates
sysconfdir = ${prefix}/etc
docdir = @docdir@
mandir = ${prefix}/man
htmldir = @htmldir@
AUTOCONFIGURED=YesPlease
INLINE=
CC_LD_DYNPATH=
TCLTK_PATH=wish
NEEDS_SSL_WITH_CRYPTO=
NO_OPENSSL=
NO_CURL=
NO_EXPAT=YesPlease
NEEDS_LIBICONV=YesPlease
NO_ICONV=
NO_DEFLATE_BOUND=
NEEDS_SOCKET=
NO_INET_NTOP=
NO_INET_PTON=
NO_HSTRERROR=
NEEDS_RESOLV=
NEEDS_LIBGEN=
LIBC_CONTAINS_LIBINTL=
NO_GETTEXT=YesPlease
NO_SYS_SELECT_H=
NO_SYS_POLL_H=
NO_INTTYPES_H=
OLD_ICONV=UnfortunatelyYes
SOCKLEN_T=
NO_D_INO_IN_DIRENT=
NO_D_TYPE_IN_DIRENT=
NO_GECOS_IN_PWENT=
NO_SOCKADDR_STORAGE=
NO_IPV6=
NO_REGEX=
FREAD_READS_DIRECTORIES=
SNPRINTF_RETURNS_BOGUS=
NO_LIBGEN_H=
HAVE_PATHS_H=YesPlease
HAVE_LIBCHARSET_H=YesPlease
HAVE_STRINGS_H=YesPlease
CHARSET_LIB=-liconv
NO_STRCASESTR=
NO_MEMMEM=YesPlease
NO_STRLCPY=
NO_UINTMAX_T=
NO_STRTOUMAX=
NO_SETENV=
NO_UNSETENV=
NO_MKDTEMP=
NO_MKSTEMPS=
NO_INITGROUPS=
PTHREAD_CFLAGS=
PTHREAD_LIBS=
NO_PTHREADS=
Understanding behavior of git blame -M
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: Initial content of file.txt (2cd9f7f) A B 2 D E G F Move line B to the middle (d4bbd97e): A 2 D B E G F git blame -s -n -f -w -M20 file.txt ^2cd9f7f 1 1) A ^2cd9f7f 3 2) 2 ^2cd9f7f 4 3) D d4bbd97e 4 4) B ^2cd9f7f 5 5) E ^2cd9f7f 6 6) G ^2cd9f7f 7 7) F I wonder, why line B is not recognized as moved. According to the documentation, I would expect git blame to report that it originates from line 2 in revision 2cd9f7f. Can anybody explain the behavior? Thanks in advance Konstantin -- 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 http://vger.kernel.org/majordomo-info.html
Re: Understanding behavior of git blame -M
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 mailing list without any satisfactory results. So here is the example: Initial content of file.txt (2cd9f7f) A B 2 D E G F Move line B to the middle (d4bbd97e): A 2 D B E G F git blame -s -n -f -w -M20 file.txt ^2cd9f7f 1 1) A ^2cd9f7f 3 2) 2 ^2cd9f7f 4 3) D d4bbd97e 4 4) B ^2cd9f7f 5 5) E ^2cd9f7f 6 6) G ^2cd9f7f 7 7) F I wonder, why line B is not recognized as moved. According to the documentation, I would expect git blame to report that it originates from line 2 in revision 2cd9f7f. Can anybody explain the behavior? Someone had reasons. diff_hunks in builtin/blame.c is once called with 0 as third argument, once with 1. Change the latter call to using 0 as well and you get your expected result: dak@lola:/tmp/test$ /usr/local/tmp/git/git blame -s -n -f -w -M20 file.txt ^2cab496 file.txt 1 1) A ^2cab496 file.txt 3 2) 2 ^2cab496 file.txt 4 3) D ^2cab496 file.txt 2 4) B ^2cab496 file.txt 5 5) E ^2cab496 file.txt 6 6) G ^2cab496 file.txt 7 7) F 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 indicates that somebody _wanted_ it called with different values. There is no documentation or rationale in the file _why_ as far as I remember. Maybe it can crash or end up in an infinite loop. Maybe it could do so at one point of time but no longer does. Maybe Git is just a puzzle from genius to genius. Good luck figuring it out. I have not touched this when rewriting git-blame recently, and I am not interested in touching it. I stand absolutely nothing to gain from working on Git. -- David Kastrup -- 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 http://vger.kernel.org/majordomo-info.html
Re: Git on Mac OS X 10.4.10
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 dependency, or what the end user happens to choose to install (in other words, is there an add-on users of 10.4 can choose to add, which allows them to use that header)? Nope, it's a platform dependency. Not available prior to 10.5. 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 Nice. Use of APPLE_COMMON_CRYPTO thing is not new to the upcoming release, so let me queue it for the next development cycle, not applying directly before curring 2.1 release today. Thanks. 8 Subject: [PATCH] config.mak.uname: set NO_APPLE_COMMON_CRYPTO on older systems Older MacOS systems prior to 10.5 do not have the CommonCrypto support Git uses so set NO_APPLE_COMMON_CRYPTO on those systems. Signed-off-by: Kyle J. McKay mack...@gmail.com --- config.mak.uname | 1 + 1 file changed, 1 insertion(+) diff --git a/config.mak.uname b/config.mak.uname index 7846bd76..f8e12c96 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -88,6 +88,7 @@ ifeq ($(uname_S),Darwin) NEEDS_LIBICONV = YesPlease ifeq ($(shell expr $(uname_R) : '[15678]\.'),2) OLD_ICONV = UnfortunatelyYes + NO_APPLE_COMMON_CRYPTO = YesPlease endif ifeq ($(shell expr $(uname_R) : '[15]\.'),2) NO_STRLCPY = YesPlease -- 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 http://vger.kernel.org/majordomo-info.html
Re: Git on Mac OS X 10.4.10
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 systems prior to 10.5 do not have the CommonCrypto support Git uses so set NO_APPLE_COMMON_CRYPTO on those systems. Signed-off-by: Kyle J. McKay mack...@gmail.com --- config.mak.uname | 1 + 1 file changed, 1 insertion(+) diff --git a/config.mak.uname b/config.mak.uname index 7846bd76..f8e12c96 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -88,6 +88,7 @@ ifeq ($(uname_S),Darwin) NEEDS_LIBICONV = YesPlease ifeq ($(shell expr $(uname_R) : '[15678]\.'),2) OLD_ICONV = UnfortunatelyYes + NO_APPLE_COMMON_CRYPTO = YesPlease endif ifeq ($(shell expr $(uname_R) : '[15]\.'),2) NO_STRLCPY = YesPlease 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 short note to remind the maintainer and the reviewers. Signed-off-by: Junio C Hamano gits...@pobox.com --- config.mak.uname | 4 1 file changed, 4 insertions(+) diff --git a/config.mak.uname b/config.mak.uname index f8e12c9..7e49aca 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -86,6 +86,10 @@ ifeq ($(uname_S),Darwin) NEEDS_CRYPTO_WITH_SSL = YesPlease NEEDS_SSL_WITH_CRYPTO = YesPlease NEEDS_LIBICONV = YesPlease + # Note: $(uname_R) gives us the underlying Darwin version. + # - MacOS 10.0 = Darwin 1.* + # - MacOS 10.x.? = Darwin (x+4).* for (1 = x) + # i.e. begins with [15678] and the a dot means 10.4.* or older. ifeq ($(shell expr $(uname_R) : '[15678]\.'),2) OLD_ICONV = UnfortunatelyYes NO_APPLE_COMMON_CRYPTO = YesPlease -- 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 http://vger.kernel.org/majordomo-info.html
Re: Understanding behavior of git blame -M
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) D d4bbd97e 4 4) B ^2cd9f7f 5 5) E ^2cd9f7f 6 6) G ^2cd9f7f 7 7) F I wonder, why line B is not recognized as moved. According to the documentation, I would expect git blame to report that it originates from line 2 in revision 2cd9f7f. Can anybody explain the behavior? Interesting. Would it make a difference if you move B further away from lines A and C? -- 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 http://vger.kernel.org/majordomo-info.html
Git for Windows 1.9.4.msysgit.1
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 Windows-specific patches Add vimtutor (msysgit PR #220) Update OpenSSH to 6.6.1p1 and its OpenSSL to 1.0.1i (msysgit PR #221, #223, #224, #226, #229, #234, #236) Update mingw OpenSSL to 0.9.8zb (msysgit PR #241, #242) Bugfixes Checkout problem with directories exceeding MAX_PATH (PR msysgit/git#212, msysgit #227) Backport a webdav fix from junio/maint (d9037e http-push.c: make CURLOPT_IOCTLDATA a usable pointer, PR msysgit/git#230) Regressions git svn is/might be broken. Fixes welcome. Have phun, Thomas [1]: https://github.com/msysgit/msysgit/releases/download/Git-1.9.4-preview20140815/Git-1.9.4-preview20140815.exe [2]: SHA1(Git-1.9.4-preview20140815.exe)= 88dd56d612431055a5c5d65c3b2f23736ad725b0 SHA1(msysGit-netinstall-1.9.4-preview20140815.exe)= c2cb700839fdcea79b5401f046878de711628ccc SHA1(PortableGit-1.9.4-preview20140815.7z)= 4deafc5fede624437c68d101a660a78bdb56f899 -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.
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:: --force-rebase:: -Force the rebase even if the current branch is a descendant -of the commit you are rebasing onto. Normally non-interactive rebase will -exit with the message Current branch is up to date in such a -situation. -Incompatible with the --interactive option. +Force a rebase even if the current branch is up-to-date and +the command without `--force` would return without doing anything. + You may find this (or --no-ff with an interactive rebase) helpful after reverting a topic branch merge, as this option recreates the topic branch with I dig more into it, and that's what I came up with, using some of your suggestions as well. Please notice new text on essential interaction with --preserve-merges. I also thought about Force the rebase that would otherwise be a no-op, and while it is future-changes-agnostic indeed, it doesn't actually explain anything, so I put some explanation back. 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 a good shape and there is no need to do anything further' or --preserve-merges mode ignores --force and refuses to recreate the history if the history is in the shape the mode deems is already desirable. I think the root cause of the issue we share in this thread, when trying to come up with an improvement of this part, is that we are trying to put more explanation to the description of --force, but if we step back a bit, it may be that the explanation does not belong there. As far as the readers are concerned, --force is about forcing a rebase that would not otherwise be a no-op, but the real issue is that the condition under which a requested rebase becomes a no-op, iow, the history is already in the desired shape, nothing to do, is different from mode to mode, because the desired shape is what distinguishes the modes. Preserve-merge rebase may think that a history that is descendant of the onto commit is already in the desired shape while plain-vanilla rebase does not if it has a merge in between, for example. The sentence that follows Otherwise in this version encourages the readers to be in a wrong mind-set that rebase is only about making the branch a descendant of the 'onto' commit, which isn't the case. The desired outcome depends on the mode (and that is why there are modes), and not saying that explicitly will only help spread the confusion, I am afraid. Isn't it a better solution to explain what that no-op condition is for the mode at the place in the document where we describe each mode? E.g. under --preserve-merges heading, we may say make sure the history is a descendant of the 'onto' commit; if it already is, nothing is done because there is no need to do anything or something along that line. The description for the plain-vanilla rebase may say flatten the history on top of the 'onto' commit by replaying the changes in each non-merge commit; if the history is already a descendant of the 'onto' commit without any merge in between, nothing is done because there is no need to. That would make description of the modes more understandable, too. The users can read what kind of resulting history they can get out of by using each mode in one place. Hmm? -- 8 -- From: Sergey Organov sorga...@gmail.com Date: Tue, 12 Aug 2014 00:10:19 +0400 Subject: [PATCH] Documentation/git-rebase.txt: fix -f description to match Current branch is a descendant of the commit you are rebasing onto does not necessarily mean rebase requires --force. Presence of merge commit(s) makes rebase perform its default flattening actions anyway. Signed-off-by: Sergey Organov sorga...@gmail.com --- Documentation/git-rebase.txt | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 2a93c64..9153369 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -316,11 +316,10 @@ which makes little sense. -f:: --force-rebase:: - Force the rebase even if the current branch is a descendant - of the commit you are rebasing onto. Normally non-interactive rebase will - exit with the message Current branch is up to date in such a - situation. - Incompatible with the --interactive option. + If --preserve-merges is given, has no effect. Otherwise forces + rebase even if the current branch is a descendant of the commit + you are rebasing onto and there are no merge commits among +
Re: Git on Mac OS X 10.4.10
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 short note to remind the maintainer and the reviewers. Signed-off-by: Junio C Hamano gits...@pobox.com --- config.mak.uname | 4 1 file changed, 4 insertions(+) diff --git a/config.mak.uname b/config.mak.uname index f8e12c9..7e49aca 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -86,6 +86,10 @@ ifeq ($(uname_S),Darwin) NEEDS_CRYPTO_WITH_SSL = YesPlease NEEDS_SSL_WITH_CRYPTO = YesPlease NEEDS_LIBICONV = YesPlease + # Note: $(uname_R) gives us the underlying Darwin version. + # - MacOS 10.0 = Darwin 1.* + # - MacOS 10.x.? = Darwin (x+4).* for (1 = x) + # 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 good. Mac OS X 10.1.0 doesn't actually fit the pattern (it's still Darwin 1.*), but it's so old and it doesn't affect the 10.4.* or older test (or the later 10.1.* or older test), so let's just ignore that anomaly. :) -- 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 http://vger.kernel.org/majordomo-info.html
Re: Git on Mac OS X 10.4.10
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 good. Mac OS X 10.1.0 doesn't actually fit the pattern (it's still Darwin 1.*), but it's so old and it doesn't affect the 10.4.* or older test (or the later 10.1.* or older test), so let's just ignore that anomaly. :) Thanks. 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]\.; leave a short note to remind the maintainer and the reviewers. Signed-off-by: Junio C Hamano gits...@pobox.com --- config.mak.uname | 4 1 file changed, 4 insertions(+) diff --git a/config.mak.uname b/config.mak.uname index f8e12c9..414760f 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -86,6 +86,10 @@ ifeq ($(uname_S),Darwin) NEEDS_CRYPTO_WITH_SSL = YesPlease NEEDS_SSL_WITH_CRYPTO = YesPlease NEEDS_LIBICONV = YesPlease + # Note: $(uname_R) gives us the underlying Darwin version. + # - MacOS 10.0.* and MacOS 10.1.0 = Darwin 1.* + # - MacOS 10.x.* = Darwin (x+4).* for (1 = x) + # i.e. begins with [15678] and a dot means 10.4.* or older. ifeq ($(shell expr $(uname_R) : '[15678]\.'),2) OLD_ICONV = UnfortunatelyYes NO_APPLE_COMMON_CRYPTO = YesPlease -- 2.1.0-rc2-283-g1433d67 -- 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 http://vger.kernel.org/majordomo-info.html
Re: Git on Mac OS X 10.4.10
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]\.; leave a short note to remind the maintainer and the reviewers. Signed-off-by: Junio C Hamano gits...@pobox.com --- config.mak.uname | 4 1 file changed, 4 insertions(+) diff --git a/config.mak.uname b/config.mak.uname index f8e12c9..414760f 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -86,6 +86,10 @@ ifeq ($(uname_S),Darwin) NEEDS_CRYPTO_WITH_SSL = YesPlease NEEDS_SSL_WITH_CRYPTO = YesPlease NEEDS_LIBICONV = YesPlease + # Note: $(uname_R) gives us the underlying Darwin version. + # - MacOS 10.0.* and MacOS 10.1.0 = Darwin 1.* + # - MacOS 10.x.* = Darwin (x+4).* for (1 = x) + # i.e. begins with [15678] and a dot means 10.4.* or older. ifeq ($(shell expr $(uname_R) : '[15678]\.'),2) OLD_ICONV = UnfortunatelyYes NO_APPLE_COMMON_CRYPTO = YesPlease -- 2.1.0-rc2-283-g1433d67 Very nice. -- 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 http://vger.kernel.org/majordomo-info.html
Re: Git for Windows 1.9.4.msysgit.1
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 bin/libsvn_repos-1-0.dll rebase -b 0x6420 bin/libneon-25.dll See https://github.com/msysgit/msysgit/pull/245 -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH] read-cache.c: Ensure unmerged entries are removed
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 in the sent patch, so no magic is done in read_cache(), I'd also avoid changes there. Indeed with the patch, ls-files -s can be used to inspect the problem without further problems. Instead, I suspect that the code paths with problematic iterations over the index entries that assume that having stage #0 entry for a path guarantees that there will not be any higher stage entry first need to be identified (you already said add and reset may be problematic, there may be others, or they may be the only ones, I dunno), and then the most sensible one, which would be different from case to case, among various possibilities need to be chosen as a fix to each of them: (1) the loop may be fixed to ignore/skip unmerged entries; (2) the loop may be fixed to ignore/skip the merged entry; (3) the loop may be fixed not to spin indefinitely on a path with mixed entries; or (4) the command should error out. git reset will clean the index anyway if the loop finishes, would it be ok? I think that it'd be acceptable for git reset --hard to clean the index as git checkout -f already does it even in this case. git merge is also affected by the loop in read_cache_unmerged(), but any of the solutions would be enough for it as only by finishing the loop with unmerged entries it will die without commiting the cache to the index file. For git add probably the best option is to error out and ask the user to check git ls-files -s to investigate the problem and decide what to do. The error message given by git commit -a is a bit confusing in this case, I can take a look to this too. I'll try to prepare a patch with these cases, and rethinking the loop to avoid future problems there, I think that is a bit dangerous to look for the position of a path entry (with index_name_pos) for the next iteration. Yes, it would be more work, but I'd feel safer if the following worked: $ git ls-files -s 100644 3cc58df83752123644fef39faab2393af643b1d2 0 conflict 100644 f70f10e4db19068f79bc43844b49f3eece45c4e8 1 conflict 100644 3cc58df83752123644fef39faab2393af643b1d2 2 conflict 100644 223b7836fb19fdf64ba2d3cd6173c6a283141f78 3 conflict $ empty $ git add empty 100644 3cc58df83752123644fef39faab2393af643b1d2 0 conflict 100644 f70f10e4db19068f79bc43844b49f3eece45c4e8 1 conflict 100644 3cc58df83752123644fef39faab2393af643b1d2 2 conflict 100644 223b7836fb19fdf64ba2d3cd6173c6a283141f78 3 conflict 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 empty $ git cat-file blob :empty output $ cmp empty output echo OK OK which would be impossible to do if we nuked the problematic stages whenever we read the index, I am afraid. This works with the first patch as read_cache() is not modified, and git add would only clean the entries for the paths passed as arguments. BTW, I didn't know git cat-file blob 0:$path, but I only manage to get Not a valid object name fatals. How is it supposed to be used? That was a typo of :$n:$path (where 0 = $n = 3). Great, thanks! -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.
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 makes little sense. -f:: --force-rebase:: - Force the rebase even if the current branch is a descendant - of the commit you are rebasing onto. Normally non-interactive rebase will - exit with the message Current branch is up to date in such a - situation. - Incompatible with the --interactive option. + Force a rebase even if the current branch is up-to-date and + the command without `--force` would return without doing anything. + You may find this (or --no-ff with an interactive rebase) helpful after reverting a topic branch merge, as this option recreates the topic branch with I dig more into it, and that's what I came up with, using some of your suggestions as well. Please notice new text on essential interaction with --preserve-merges. I also thought about Force the rebase that would otherwise be a no-op, and while it is future-changes-agnostic indeed, it doesn't actually explain anything, so I put some explanation back. 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 a good shape and there is no need to do anything further' or --preserve-merges mode ignores --force and refuses to recreate the history if the history is in the shape the mode deems is already desirable. In fact there is no way to force rebase when --preserve-merges is given. Neither --force nor --no-ff has any effect. Maybe some clarification could be given in --preserve-merges description, provided it's not clear that has no effect for --force means that one can't force the rebase in this case. I think the root cause of the issue we share in this thread, when trying to come up with an improvement of this part, is that we are trying to put more explanation to the description of --force, but if we step back a bit, it may be that the explanation does not belong there. As far as the readers are concerned, --force is about forcing a rebase that would not otherwise be a no-op, but the real issue is that the condition under which a requested rebase becomes a no-op, iow, the history is already in the desired shape, nothing to do, is different from mode to mode, because the desired shape is what distinguishes the modes. Preserve-merge rebase may think that a history that is descendant of the onto commit is already in the desired shape while plain-vanilla rebase does not if it has a merge in between, for example. I think the root cause is even deeper, in the current design of the rebase interface, but those my opinion you already know and I'll leave discussion for another post that I currently try to formulate. The sentence that follows Otherwise in this version encourages the readers to be in a wrong mind-set that rebase is only about making the branch a descendant of the 'onto' commit, which isn't the case. I'm not happy with the wording myself either. The desired outcome depends on the mode (and that is why there are modes), and not saying that explicitly will only help spread the confusion, I am afraid. Isn't it a better solution to explain what that no-op condition is for the mode at the place in the document where we describe each mode? E.g. under --preserve-merges heading, we may say make sure the history is a descendant of the 'onto' commit; if it already is, nothing is done because there is no need to do anything or something along that line. The description for the plain-vanilla rebase may say flatten the history on top of the 'onto' commit by replaying the changes in each non-merge commit; if the history is already a descendant of the 'onto' commit without any merge in between, nothing is done because there is no need to. That would make description of the modes more understandable, too. The users can read what kind of resulting history they can get out of by using each mode in one place. I think you've lost me here, though I think that all the suggested variants are still better than what is there right now. -- Sergey. -- 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 http://vger.kernel.org/majordomo-info.html
AW: Understanding behavior of git blame -M
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 from the documented behavior, as the documentation doesn't mention this number of lines aspect but rather speaks about number of alphanumeric characters. Regards Konstantin -Ursprüngliche Nachricht- Von: David Kastrup [mailto:d...@gnu.org] Gesendet: Freitag, 15. August 2014 16:42 An: Sokolov, Konstantin (ext) Cc: git@vger.kernel.org Betreff: Re: Understanding behavior of git blame -M 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 mailing list without any satisfactory results. So here is the example: Initial content of file.txt (2cd9f7f) A B 2 D E G F Move line B to the middle (d4bbd97e): A 2 D B E G F git blame -s -n -f -w -M20 file.txt ^2cd9f7f 1 1) A ^2cd9f7f 3 2) 2 ^2cd9f7f 4 3) D d4bbd97e 4 4) B ^2cd9f7f 5 5) E ^2cd9f7f 6 6) G ^2cd9f7f 7 7) F I wonder, why line B is not recognized as moved. According to the documentation, I would expect git blame to report that it originates from line 2 in revision 2cd9f7f. Can anybody explain the behavior? Someone had reasons. diff_hunks in builtin/blame.c is once called with 0 as third argument, once with 1. Change the latter call to using 0 as well and you get your expected result: dak@lola:/tmp/test$ /usr/local/tmp/git/git blame -s -n -f -w -M20 file.txt ^2cab496 file.txt 1 1) A ^2cab496 file.txt 3 2) 2 ^2cab496 file.txt 4 3) D ^2cab496 file.txt 2 4) B ^2cab496 file.txt 5 5) E ^2cab496 file.txt 6 6) G ^2cab496 file.txt 7 7) F 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 indicates that somebody _wanted_ it called with different values. There is no documentation or rationale in the file _why_ as far as I remember. Maybe it can crash or end up in an infinite loop. Maybe it could do so at one point of time but no longer does. Maybe Git is just a puzzle from genius to genius. Good luck figuring it out. I have not touched this when rewriting git-blame recently, and I am not interested in touching it. I stand absolutely nothing to gain from working on Git. -- David Kastrup -- 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 http://vger.kernel.org/majordomo-info.html
AW: Understanding behavior of git blame -M
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 19:08 An: Sokolov, Konstantin (ext) Cc: git@vger.kernel.org Betreff: Re: Understanding behavior of git blame -M 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) D d4bbd97e 4 4) B ^2cd9f7f 5 5) E ^2cd9f7f 6 6) G ^2cd9f7f 7 7) F I wonder, why line B is not recognized as moved. According to the documentation, I would expect git blame to report that it originates from line 2 in revision 2cd9f7f. Can anybody explain the behavior? Interesting. Would it make a difference if you move B further away from lines A and C? -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH] read-cache.c: Ensure unmerged entries are removed
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 inspected. Well, only read_cache_unmerged() is modified in the sent patch, so no magic is done in read_cache(), I'd also avoid changes there. Ahh, I must have overlooked that; changes being only in _unmerged() variant makes me feel much better, and it probably would make much of ... Yes, it would be more work,... ... moot, hopefully ;-) git reset will clean the index anyway if the loop finishes, would it be ok? Surely. git merge is also affected by the loop in read_cache_unmerged(), but any of the solutions would be enough for it as only by finishing the loop with unmerged entries it will die without commiting the cache to the index file. Again, true. The mergy operations want to start from a clean slate and they call _unmerged() variant primarily to learn that there were unmerged entries in the index, only to abort the operation in that case, so a change to _unmerged() variant should be safe for them. I'll take another look at your patch later, but not before the 2.1 final, and by that time you may already have sent a reroll ;-) Thanks. -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.
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 a good shape and there is no need to do anything further' or --preserve-merges mode ignores --force and refuses to recreate the history if the history is in the shape the mode deems is already desirable. In fact there is no way to force rebase when --preserve-merges is given. Neither --force nor --no-ff has any effect. Maybe some clarification could be given in --preserve-merges description, provided it's not clear that has no effect for --force means that one can't force the rebase in this case. I am not sure if that is an intended behaviour or simply a bug (I rarely use preserve-merges myself, so I offhand do not know for certain). -- 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 http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Git v2.1.0
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 = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v2.1 Release Notes == Backward compatibility notes * The default value we give to the environment variable LESS has been changed from FRSX to FRX, losing S (chop long lines instead of wrapping). Existing users who prefer not to see line-wrapped output may want to set $ git config core.pager less -S to restore the traditional behaviour. It is expected that people find output from most subcommands easier to read with the new default, except for blame which tends to produce really long lines. To override the new default only for git blame, you can do this: $ git config pager.blame less -S * A few disused directories in contrib/ have been retired. Updates since v2.0 -- UI, Workflows Features * Since the very beginning of Git, we gave the LESS environment a default value FRSX when we spawn less as the pager. S (chop long lines instead of wrapping) has been removed from this default set of options, because it is more or less a personal taste thing, as opposed to the others that have good justifications (i.e. R is very much justified because many kinds of output we produce are colored and FX is justified because output we produce is often shorter than a page). * The logic and data used to compute the display width needed for UTF-8 strings have been updated to match Unicode 7.0 better. * HTTP-based transports learned to better propagate the error messages from the webserver to the client coming over the HTTP transport. * The completion script for bash (in contrib/) has been updated to better handle aliases that define a complex sequence of commands. * The core.preloadindex configuration variable is enabled by default, allowing modern platforms to take advantage of their multiple cores. * git clone applies the if cloning from a local disk, physically copy the repository using hardlinks, unless otherwise told not to with --no-local optimization when the url.*.insteadOf mechanism rewrites a remote-repository git clone $URL into a clone from a local disk. * git commit --date=date option learned more timestamp formats, including --date=now. * The `core.commentChar` configuration variable is used to specify a custom comment character (other than the default #) for the commit message editor. This can be set to `auto` to attempt to choose a different character that does not conflict with any that already starts a line in the message being edited, for cases like git commit --amend. * git format-patch learned --signature-file=file to add the contents of a file as a signature to the mail message it produces. * git grep learned the grep.fullname configuration variable to force --full-name to be the default. This may cause regressions for scripted users who do not expect this new behaviour. * git imap-send learned to ask the credential helper for auth material. * git log and friends now understand the value auto for the log.decorate configuration variable to enable the --decorate option automatically when the output is sent to tty. * git merge without an argument, even when there is an upstream defined for the current branch, refused to run until merge.defaultToUpstream is set to true. Flip the default of that configuration variable to true. * git mergetool learned to drive the vimdiff3 backend. * mergetool.prompt used to default to 'true', always asking do you really want to run the tool on this path?. The default has been changed to 'false'. However, the prompt will still appear if mergetool used its autodetection system to guess which tool to use. Users who explicitly specify or configure a tool will no longer see the prompt by default. Strictly speaking, this is a backward incompatible change and users need to explicitly set the variable to 'true' if they want to be prompted to confirm running the tool on each path. * git replace learned the --edit subcommand to create a replacement by editing an existing object. * git replace learned a --graft option to rewrite the parents of a commit. * git send-email learned --to-cover and --cc-cover options, to tell it to copy To: and Cc: headers found in the first input file when emitting later input files. * git svn learned to
Re: [ANNOUNCE] Git v2.1.0
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 test-results/p5302-pack-index.subtests: No such file or directory at ./aggregate.perl line 77. Makefile:7: recipe for target 'perf' failed make[2]: *** [perf] Error 2 make[2]: Leaving directory '/usr/projects/git/git/t/perf' Not a big deal, but I thought I would mention it. Cheers, - Ted -- 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 http://vger.kernel.org/majordomo-info.html
Re: Understanding behavior of git blame -M
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 indicates that somebody _wanted_ it called with different values. There is no documentation or rationale in the file _why_ as far as I remember. Maybe it can crash or end up in an infinite loop. Maybe it could do so at one point of time but no longer does. Not sure if it helps, but ctxlen = 1 seems to be added back in d24bba8 (git-pickaxe -M: blame line movements within a file. - 2006-10-19), if I track the changes correctly. -- Duy -- 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 http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] fetch: convert argv_gc_auto to struct argv_array
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 argc, const char **argv, const char
*prefix)
struct string_list list = STRING_LIST_INIT_NODUP;
struct remote *remote;
int result = 0;
- static const char *argv_gc_auto[] = {
- gc, --auto, NULL,
- };
+ struct argv_array argv_gc_auto = ARGV_ARRAY_INIT;
packet_trace_identity(fetch);
@@ -1198,7 +1196,9 @@ int cmd_fetch(int argc, const char **argv, const char
*prefix)
list.strdup_strings = 1;
string_list_clear(list, 0);
- run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
+ argv_array_pushl(argv_gc_auto, gc, --auto, NULL);
+ run_command_v_opt(argv_gc_auto.argv, RUN_GIT_CMD);
+ argv_array_clear(argv_gc_auto);
return result;
}
--
2.1.0.rc0.78.gc0d8480
--
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 http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] fetch: silence git-gc if --quiet is given
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 @@ -1197,6 +1197,8 @@ int cmd_fetch(int argc, const char **argv, const char *prefix) string_list_clear(list, 0); argv_array_pushl(argv_gc_auto, gc, --auto, NULL); + if (verbosity 0) + argv_array_push(argv_gc_auto, --quiet); run_command_v_opt(argv_gc_auto.argv, RUN_GIT_CMD); argv_array_clear(argv_gc_auto); -- 2.1.0.rc0.78.gc0d8480 -- 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 http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/5] Large file improvements
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 flags to diff_populate_filespec diff --stat: mark any file larger than core.bigfilethreshold binary diff: shortcut for diff'ing two binary SHA-1 objects Documentation/config.txt| 3 +- Documentation/gitattributes.txt | 4 +-- diff.c | 52 ++- diffcore-rename.c | 6 ++-- diffcore.h | 4 ++- git-compat-util.h | 1 + sha1_file.c | 4 ++- t/t1050-large.sh| 20 wrapper.c | 68 +++-- 9 files changed, 125 insertions(+), 37 deletions(-) -- 2.1.0.rc0.78.gc0d8480 -- 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 http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/5] wrapper.c: introduce gentle xmallocz that does not die()
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
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -593,6 +593,7 @@ extern try_to_free_t set_try_to_free_routine(try_to_free_t);
extern char *xstrdup(const char *str);
extern void *xmalloc(size_t size);
extern void *xmallocz(size_t size);
+extern void *xmallocz_gently(size_t size);
extern void *xmemdupz(const void *data, size_t len);
extern char *xstrndup(const char *str, size_t len);
extern void *xrealloc(void *ptr, size_t size);
diff --git a/wrapper.c b/wrapper.c
index bc1bfb8..dc9c8f4 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -9,16 +9,23 @@ static void do_nothing(size_t size)
static void (*try_to_free_routine)(size_t size) = do_nothing;
-static void memory_limit_check(size_t size)
+static int memory_limit_check(size_t size, int gentle)
{
static int limit = -1;
if (limit == -1) {
const char *env = getenv(GIT_ALLOC_LIMIT);
limit = env ? atoi(env) * 1024 : 0;
}
- if (limit size limit)
- die(attempting to allocate %PRIuMAX over limit %d,
- (intmax_t)size, limit);
+ if (limit size limit) {
+ if (gentle) {
+ error(attempting to allocate %PRIuMAX over limit %d,
+ (intmax_t)size, limit);
+ return -1;
+ } else
+ die(attempting to allocate %PRIuMAX over limit %d,
+ (intmax_t)size, limit);
+ }
+ return 0;
}
try_to_free_t set_try_to_free_routine(try_to_free_t routine)
@@ -42,11 +49,12 @@ char *xstrdup(const char *str)
return ret;
}
-void *xmalloc(size_t size)
+static void *do_xmalloc(size_t size, int gentle)
{
void *ret;
- memory_limit_check(size);
+ if (memory_limit_check(size, gentle))
+ return NULL;
ret = malloc(size);
if (!ret !size)
ret = malloc(1);
@@ -55,9 +63,16 @@ void *xmalloc(size_t size)
ret = malloc(size);
if (!ret !size)
ret = malloc(1);
- if (!ret)
- die(Out of memory, malloc failed (tried to allocate
%lu bytes),
- (unsigned long)size);
+ if (!ret) {
+ if (!gentle)
+ die(Out of memory, malloc failed (tried to
allocate %lu bytes),
+ (unsigned long)size);
+ else {
+ error(Out of memory, malloc failed (tried to
allocate %lu bytes),
+ (unsigned long)size);
+ return NULL;
+ }
+ }
}
#ifdef XMALLOC_POISON
memset(ret, 0xA5, size);
@@ -65,16 +80,37 @@ void *xmalloc(size_t size)
return ret;
}
-void *xmallocz(size_t size)
+void *xmalloc(size_t size)
+{
+ return do_xmalloc(size, 0);
+}
+
+static void *do_xmallocz(size_t size, int gentle)
{
void *ret;
- if (unsigned_add_overflows(size, 1))
- die(Data too large to fit into virtual memory space.);
- ret = xmalloc(size + 1);
- ((char*)ret)[size] = 0;
+ if (unsigned_add_overflows(size, 1)) {
+ if (gentle) {
+ error(Data too large to fit into virtual memory
space.);
+ return NULL;
+ } else
+ die(Data too large to fit into virtual memory space.);
+ }
+ ret = do_xmalloc(size + 1, gentle);
+ if (ret)
+ ((char*)ret)[size] = 0;
return ret;
}
+void *xmallocz(size_t size)
+{
+ return do_xmallocz(size, 0);
+}
+
+void *xmallocz_gently(size_t size)
+{
+ return do_xmallocz(size, 1);
+}
+
/*
* xmemdupz() allocates (len + 1) bytes of memory, duplicates len bytes of
* data to the allocated memory, zero terminates the allocated memory,
@@ -96,7 +132,7 @@ void *xrealloc(void *ptr, size_t size)
{
void *ret;
- memory_limit_check(size);
+ memory_limit_check(size, 0);
ret = realloc(ptr, size);
if (!ret !size)
ret = realloc(ptr, 1);
@@ -115,7 +151,7 @@ void *xcalloc(size_t nmemb, size_t size)
{
void *ret;
- memory_limit_check(size * nmemb);
+ memory_limit_check(size * nmemb, 0);
ret = calloc(nmemb, size);
if (!ret (!nmemb || !size))
ret = calloc(1, 1);
--
2.1.0.rc0.78.gc0d8480
--
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
[PATCH v4 4/5] diff --stat: mark any file larger than core.bigfilethreshold binary
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. Worley wor...@alum.mit.edu
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/config.txt| 3 ++-
Documentation/gitattributes.txt | 4 ++--
diff.c | 26 ++
diffcore.h | 1 +
t/t1050-large.sh| 4
5 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c55c22a..3b5b24a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -499,7 +499,8 @@ core.bigFileThreshold::
Files larger than this size are stored deflated, without
attempting delta compression. Storing large files without
delta compression avoids excessive memory usage, at the
- slight expense of increased disk usage.
+ slight expense of increased disk usage. Additionally files
+ larger than this size are always treated as binary.
+
Default is 512 MiB on all platforms. This should be reasonable
for most projects as source code and other text files can still
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 643c1ba..9b45bda 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -440,8 +440,8 @@ Unspecified::
A path to which the `diff` attribute is unspecified
first gets its contents inspected, and if it looks like
- text, it is treated as text. Otherwise it would
- generate `Binary files differ`.
+ text and is smaller than core.bigFileThreshold, it is treated
+ as text. Otherwise it would generate `Binary files differ`.
String::
diff --git a/diff.c b/diff.c
index f4b7421..d381a6f 100644
--- a/diff.c
+++ b/diff.c
@@ -2188,8 +2188,8 @@ int diff_filespec_is_binary(struct diff_filespec *one)
one-is_binary = one-driver-binary;
else {
if (!one-data DIFF_FILE_VALID(one))
- diff_populate_filespec(one, 0);
- if (one-data)
+ diff_populate_filespec(one, CHECK_BINARY);
+ if (one-is_binary == -1 one-data)
one-is_binary = buffer_is_binary(one-data,
one-size);
if (one-is_binary == -1)
@@ -2725,6 +2725,11 @@ int diff_populate_filespec(struct diff_filespec *s,
unsigned int flags)
}
if (size_only)
return 0;
+ if ((flags CHECK_BINARY)
+ s-size big_file_threshold s-is_binary == -1) {
+ s-is_binary = 1;
+ return 0;
+ }
fd = open(s-path, O_RDONLY);
if (fd 0)
goto err_empty;
@@ -2746,16 +2751,21 @@ int diff_populate_filespec(struct diff_filespec *s,
unsigned int flags)
}
else {
enum object_type type;
- if (size_only) {
+ if (size_only || (flags CHECK_BINARY)) {
type = sha1_object_info(s-sha1, s-size);
if (type 0)
die(unable to read %s, sha1_to_hex(s-sha1));
- } else {
- s-data = read_sha1_file(s-sha1, type, s-size);
- if (!s-data)
- die(unable to read %s, sha1_to_hex(s-sha1));
- s-should_free = 1;
+ if (size_only)
+ return 0;
+ if (s-size big_file_threshold s-is_binary == -1)
{
+ s-is_binary = 1;
+ return 0;
+ }
}
+ s-data = read_sha1_file(s-sha1, type, s-size);
+ if (!s-data)
+ die(unable to read %s, sha1_to_hex(s-sha1));
+ s-should_free = 1;
}
return 0;
}
diff --git a/diffcore.h b/diffcore.h
index c80df18..33ea2de 100644
--- a/diffcore.h
+++ b/diffcore.h
@@ -56,6 +56,7 @@ extern void fill_filespec(struct diff_filespec *, const
unsigned char *,
int, unsigned short);
#define CHECK_SIZE_ONLY 1
+#define CHECK_BINARY2
extern int diff_populate_filespec(struct diff_filespec *, unsigned int);
extern void diff_free_filespec_data(struct diff_filespec *);
extern void diff_free_filespec_blob(struct diff_filespec *);
diff --git a/t/t1050-large.sh b/t/t1050-large.sh
index 5642f84..00d2f33 100755
--- a/t/t1050-large.sh
+++
[PATCH v4 5/5] diff: shortcut for diff'ing two binary SHA-1 objects
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 'diff-files' still does.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
diff.c | 13 +
t/t1050-large.sh | 10 ++
2 files changed, 23 insertions(+)
diff --git a/diff.c b/diff.c
index d381a6f..b85bcfb 100644
--- a/diff.c
+++ b/diff.c
@@ -2324,6 +2324,19 @@ static void builtin_diff(const char *name_a,
} else if (!DIFF_OPT_TST(o, TEXT)
( (!textconv_one diff_filespec_is_binary(one)) ||
(!textconv_two diff_filespec_is_binary(two)) )) {
+ if (!one-data !two-data
+ S_ISREG(one-mode) S_ISREG(two-mode)
+ !DIFF_OPT_TST(o, BINARY)) {
+ if (!hashcmp(one-sha1, two-sha1)) {
+ if (must_show_header)
+ fprintf(o-file, %s, header.buf);
+ goto free_ab_and_return;
+ }
+ fprintf(o-file, %s, header.buf);
+ fprintf(o-file, %sBinary files %s and %s differ\n,
+ line_prefix, lbl[0], lbl[1]);
+ goto free_ab_and_return;
+ }
if (fill_mmfile(mf1, one) 0 || fill_mmfile(mf2, two) 0)
die(unable to read files to diff);
/* Quite common confusing case */
diff --git a/t/t1050-large.sh b/t/t1050-large.sh
index 00d2f33..05a1e1d 100755
--- a/t/t1050-large.sh
+++ b/t/t1050-large.sh
@@ -116,6 +116,16 @@ test_expect_success 'diff --stat' '
git diff --stat HEAD^ HEAD
'
+test_expect_success 'diff' '
+ git diff HEAD^ HEAD actual
+ grep Binary files.*differ actual
+'
+
+test_expect_success 'diff --cached' '
+ git diff --cached HEAD^ actual
+ grep Binary files.*differ actual
+'
+
test_expect_success 'hash-object' '
git hash-object large1
'
--
2.1.0.rc0.78.gc0d8480
--
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 http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/5] sha1_file.c: do not die failing to malloc in unpack_compressed_entry
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 present (and do not fit in memory). Noticed-by: Dale R. Worley wor...@alum.mit.edu Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- sha1_file.c | 4 +++- t/t1050-large.sh | 6 ++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/sha1_file.c b/sha1_file.c index 3f70b1d..8db73f0 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -1923,7 +1923,9 @@ static void *unpack_compressed_entry(struct packed_git *p, git_zstream stream; unsigned char *buffer, *in; - buffer = xmallocz(size); + buffer = xmallocz_gently(size); + if (!buffer) + return NULL; memset(stream, 0, sizeof(stream)); stream.next_out = buffer; stream.avail_out = size + 1; diff --git a/t/t1050-large.sh b/t/t1050-large.sh index aea4936..5642f84 100755 --- a/t/t1050-large.sh +++ b/t/t1050-large.sh @@ -163,4 +163,10 @@ test_expect_success 'zip achiving, deflate' ' git archive --format=zip HEAD /dev/null ' +test_expect_success 'fsck' ' + test_must_fail git fsck 2err + n=$(grep error: attempting to allocate .* over limit err | wc -l) + test $n -gt 1 +' + test_done -- 2.1.0.rc0.78.gc0d8480 -- 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 http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/5] diff.c: allow to pass more flags to diff_populate_filespec
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 867f034..f4b7421 100644
--- a/diff.c
+++ b/diff.c
@@ -376,7 +376,7 @@ static unsigned long diff_filespec_size(struct
diff_filespec *one)
{
if (!DIFF_FILE_VALID(one))
return 0;
- diff_populate_filespec(one, 1);
+ diff_populate_filespec(one, CHECK_SIZE_ONLY);
return one-size;
}
@@ -1910,11 +1910,11 @@ static void show_dirstat(struct diff_options *options)
diff_free_filespec_data(p-one);
diff_free_filespec_data(p-two);
} else if (DIFF_FILE_VALID(p-one)) {
- diff_populate_filespec(p-one, 1);
+ diff_populate_filespec(p-one, CHECK_SIZE_ONLY);
copied = added = 0;
diff_free_filespec_data(p-one);
} else if (DIFF_FILE_VALID(p-two)) {
- diff_populate_filespec(p-two, 1);
+ diff_populate_filespec(p-two, CHECK_SIZE_ONLY);
copied = 0;
added = p-two-size;
diff_free_filespec_data(p-two);
@@ -2668,8 +2668,9 @@ static int diff_populate_gitlink(struct diff_filespec *s,
int size_only)
* grab the data for the blob (or file) for our own in-core comparison.
* diff_filespec has data and size fields for this purpose.
*/
-int diff_populate_filespec(struct diff_filespec *s, int size_only)
+int diff_populate_filespec(struct diff_filespec *s, unsigned int flags)
{
+ int size_only = flags CHECK_SIZE_ONLY;
int err = 0;
/*
* demote FAIL to WARN to allow inspecting the situation
@@ -4688,8 +4689,8 @@ static int diff_filespec_check_stat_unmatch(struct
diff_filepair *p)
!DIFF_FILE_VALID(p-two) ||
(p-one-sha1_valid p-two-sha1_valid) ||
(p-one-mode != p-two-mode) ||
- diff_populate_filespec(p-one, 1) ||
- diff_populate_filespec(p-two, 1) ||
+ diff_populate_filespec(p-one, CHECK_SIZE_ONLY) ||
+ diff_populate_filespec(p-two, CHECK_SIZE_ONLY) ||
(p-one-size != p-two-size) ||
!diff_filespec_is_identical(p-one, p-two)) /* (2) */
p-skip_stat_unmatch_result = 1;
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 2e44a37..4e132f1 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -147,9 +147,11 @@ static int estimate_similarity(struct diff_filespec *src,
* is a possible size - we really should have a flag to
* say whether the size is valid or not!)
*/
- if (!src-cnt_data diff_populate_filespec(src, 1))
+ if (!src-cnt_data
+ diff_populate_filespec(src, CHECK_SIZE_ONLY))
return 0;
- if (!dst-cnt_data diff_populate_filespec(dst, 1))
+ if (!dst-cnt_data
+ diff_populate_filespec(dst, CHECK_SIZE_ONLY))
return 0;
max_size = ((src-size dst-size) ? src-size : dst-size);
diff --git a/diffcore.h b/diffcore.h
index c876dac..c80df18 100644
--- a/diffcore.h
+++ b/diffcore.h
@@ -55,7 +55,8 @@ extern void free_filespec(struct diff_filespec *);
extern void fill_filespec(struct diff_filespec *, const unsigned char *,
int, unsigned short);
-extern int diff_populate_filespec(struct diff_filespec *, int);
+#define CHECK_SIZE_ONLY 1
+extern int diff_populate_filespec(struct diff_filespec *, unsigned int);
extern void diff_free_filespec_data(struct diff_filespec *);
extern void diff_free_filespec_blob(struct diff_filespec *);
extern int diff_filespec_is_binary(struct diff_filespec *);
--
2.1.0.rc0.78.gc0d8480
--
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 http://vger.kernel.org/majordomo-info.html
