Re: [PATCH] Fix NO_LIBPCRE1_JIT to fully disable JIT

On Mon, Nov 13, 2017 at 12:53:15PM +0900, Junio C Hamano wrote: > > Thanks. This patch needs a sign-off, by the way. Signed-off-by: cbaile...@bloomberg.net (I can resend the full patch if required or if anyone requests futher changes. > > But that we should take it anyway regardless of that

[PATCH] Fix NO_LIBPCRE1_JIT to fully disable JIT

From: Charles Bailey <cbaile...@bloomberg.net> If you have a pcre1 library which is compiled with JIT enabled then PCRE_STUDY_JIT_COMPILE will be defined whether or not the NO_LIBPCRE1_JIT configuration is set. This means that we enable JIT functionality when calling pcre_stud

[PATCH] Make t4201-shortlog.sh test more robust

From: Charles Bailey <cbaile...@bloomberg.net> The test for '--abbrev' in t4201-shortlog.sh assumes that the commits generated in the test can always be uniquely abbreviated to 5 hex digits but this is not always the case. If you were unlucky and happened to run the test at (say) Thu Jun 22

Re: Handling of paths

On Thu, Jul 20, 2017 at 01:30:52PM -0700, Junio C Hamano wrote: > > I've read the function again and I think the attached patch covers > everything that ought to be a filename. > > By the way, to credit you, do you prefer your bloomberg or hashpling > address? The patch looks good to me. It's

Re: Handling of paths

On Thu, Jul 20, 2017 at 12:42:40PM -0700, Junio C Hamano wrote: > Victor Toni writes: > > > What's unexpected is that paths used for sslKey or sslCert are treated > > differently insofar as they are expected to be absolute. > > Relative paths (whether with or without "~")

Git hackathon London 8th/9th July - call for mentors

As some of you may have inferred, we had to postpone our plans for a hackathon event last month but we are now moving ahead with plans for one in London in July. Thank you to everyone who expressed interest in being a mentor after my last request. So, similar to last time... Bloomberg going to

Git hackathon New York / London - call for mentors

Bloomberg would like to host a Git hackathon over a weekend in both New York and London, towards the end of April or the beginning of May. Crucial to the success of the weekend will be having mentors available in both locations who can guide people on the project. Mentors should have some

Re: What's cooking in git.git (Jul 2016, #02; Wed, 6)

On Thu, Jul 07, 2016 at 02:21:28PM -0700, Junio C Hamano wrote: > Charles Bailey <char...@hashpling.org> writes: > > > I just wanted to clarify what was actually fixed. The actual bug that > > was reported and fixed was the fact that 'git grep' (without --cached) > >

Re: What's cooking in git.git (Jul 2016, #02; Wed, 6)

On Wed, Jul 06, 2016 at 02:39:26PM -0700, Junio C Hamano wrote: > * nd/ita-cleanup (2016-07-01) 3 commits > (merged to 'next' on 2016-07-06 at f15aeba) > + grep: fix grepping for "intent to add" files > + t7810-grep.sh: fix a whitespace inconsistency > + t7810-grep.sh: fix duplicated test

[PATCH v3 1/3] t7810-grep.sh: fix duplicated test name

Signed-off-by: Charles Bailey <char...@hashpling.org> --- t/t7810-grep.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh index 1e72971..c4302ed 100755 --- a/t/t7810-grep.sh +++ b/t/t7810-grep.sh @@ -353,7 +353,7 @@ test_expect_success

[PATCH v3 0/3] Grepping with intent to add

r for something. In effect, we are applying the "contents indeterminate" state of the index to the working tree file. Charles Bailey (3): t7810-grep.sh: fix duplicated test name t7810-grep.sh: fix a whitespace inconsistency grep: fix grepping for "intent to add" files

[PATCH v3 2/3] t7810-grep.sh: fix a whitespace inconsistency

Signed-off-by: Charles Bailey <char...@hashpling.org> --- t/t7810-grep.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh index c4302ed..6e6eaa4 100755 --- a/t/t7810-grep.sh +++ b/t/t7810-grep.sh @@ -175,7 +175,7

[PATCH v3 3/3] grep: fix grepping for "intent to add" files

From: Charles Bailey <cbaile...@bloomberg.net> This reverts commit 4d5520053 (grep: make it clear i-t-a entries are ignored, 2015-12-27) and adds an alternative fix to maintain the -L --cached behavior. 4d5520053 caused 'git grep' to no longer find matches in new files in the working tree

[PATCH v2 1/2] Fix duplicated test name

Signed-off-by: Charles Bailey <char...@hashpling.org> --- Spotted while testing t7810-grep and grep "i-t-a" fixes. t/t7810-grep.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh index 1e72971..c4302ed 100755 --- a/t/t7810

[PATCH v2 2/2] grep: fix grepping for "intent to add" files

From: Charles Bailey <cbaile...@bloomberg.net> This reverts commit 4d552005323034c1d6311796ac1074e9a4b4b57e and adds an alternative fix to maintain the -L --cached behavior. 4d5520053 caused 'git grep' to no longer find matches in new files in the working tree where the corresponding index

Re: [PATCH] grep: fix grepping for "intent to add" files

On Thu, Jun 16, 2016 at 05:57:18PM +0700, Duy Nguyen wrote: > > "git grep --cached" searches file content that will be committed by > "git commit" (no -a). An i-t-a entry will not be committed (you would > need "git add" first, or do "git commit -a"). So if I say "search > among the

Re: [PATCH] grep: fix grepping for "intent to add" files

On Thu, Jun 16, 2016 at 02:47:09PM +0700, Duy Nguyen wrote: > I don't think revert is right. It rather needs a re-fix like below. > Basically we want grep_file() to run as normal, but grep_sha1() > (i.e. git grep --cached) should ignore i-t-a entries, because empty > SHA-1 is not the right content

[PATCH] grep: fix grepping for "intent to add" files

From: Charles Bailey <cbaile...@bloomberg.net> This reverts commit 4d552005323034c1d6311796ac1074e9a4b4b57e. This commit caused 'git grep' to no longer find matches in new files in the working tree where the corresponding index entry had the "intent to add" bit set. Add tests to

Re: git branch in Bash subshell "$(git branch -a)" including ls output as part of return?

On Mon, Dec 07, 2015 at 11:52:28AM -0500, Alex Jones wrote: > git branch -a output: > > ajonespro:Deploy_Script ajones$ git branch -a > > * DWH_concurrent_api > Email_No_Error_If_No_Old_Version > IT/configs_in_app_support > PHP_Build_Repo > master > remotes/origin/DWH_concurrent_api >

Re: git branch in Bash subshell "$(git branch -a)" including ls output as part of return?

On Mon, Dec 07, 2015 at 04:58:10PM +, Charles Bailey wrote: > > Looking at the two outputs, you are seeing the shell's glob expansion of > the '*' current branch marker. You probably want to quote the command > expansion to prevent this: > > echo "$(git branch

Re: [PATCH] Fix quoting of redirect in test script

On Fri, Dec 04, 2015 at 01:05:20PM -0800, Junio C Hamano wrote: > Do you want to sign-off this patch? > > Thanks. Oops, yes please. Signed-off-by: Charles Bailey <cbaile...@bloomberg.net> -- To unsubscribe from this list: send the line "unsubscribe git" in the bo

[PATCH] Fix quoting of redirect in test script

From: Charles Bailey <cbaile...@bloomberg.net> --- t/t3404-rebase-interactive.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) If you are using bash (at least 4.3.30 or 4.3.42) this actually causes an error due to an "ambiguous redirect" because there is a space in

[PATCH] Fix detection of uname failure

From: Charles Bailey cbaile...@bloomberg.net According to POSIX specification uname must return -1 on failure and a non-negative value on success. Although many implementations do return 0 on success it is valid to return any positive value for success. In particular, Solaris returns 1. Signed

Re: [PATCH] Fix detection of uname failure

On Fri, Jul 17, 2015 at 03:06:57PM +0200, Johannes Schindelin wrote: From a quick `git grep '== -1'` and another quick `git grep ' 0'` it appears to me that we prefer the latter. Maybe you want to adjust it in the patch, too? I did the same grep and found lots of examples of both. Many of

[PATCH v2] Fix detection of uname failure

From: Charles Bailey cbaile...@bloomberg.net According to POSIX specification uname must return -1 on failure and a non-negative value on success. Although many implementations do return 0 on success it is valid to return any positive value for success. In particular, Solaris returns 1. Signed

[PATCH] Fix definition of ARRAY_SIZE for non-gcc builds

From: Charles Bailey cbaile...@bloomberg.net The improved ARRAY_SIZE macro uses BARF_UNLESS_AN_ARRAY which is expands to a valid check for recent gcc versions and to 0 for older gcc versions but is not defined on non-gcc builds. Non-gcc builds need this macro to expand to 0 as well. The current

[PATCH v2] Fix definition of ARRAY_SIZE for non-gcc builds

From: Charles Bailey cbaile...@bloomberg.net The improved ARRAY_SIZE macro uses BARF_UNLESS_AN_ARRAY which is expands to a valid check for recent gcc versions and to 0 for older gcc versions but is not defined on non-gcc builds. Non-gcc builds need this macro to expand to 0 as well. The current

Re: [Question] Is it normal for accented characters to be shown as decomposed Unicode on GNU/Linux?

On Mon, Jun 22, 2015 at 03:17:40PM +0200, Bastien Traverse wrote: test case: $ mkdir accent-test cd !$ $ git init $ touch rêve réunion $ git status On branch master Initial commit Untracked files: (use git add file... to include in what will be committed) r\303\251union

Re: [PATCH] Add list-all-objects command

On Mon, Jun 22, 2015 at 06:33:21AM -0400, Jeff King wrote: On Mon, Jun 22, 2015 at 04:38:22AM -0400, Jeff King wrote: + prepare_packed_git(); + for (p = packed_git; p; p = p-next) { + open_pack_index(p); + } Yikes. The fact that you need to do this means that

Re: [PATCH 8/7] cat-file: sort and de-dup output of --batch-all-objects

On Mon, Jun 22, 2015 at 07:06:32AM -0400, Jeff King wrote: On Mon, Jun 22, 2015 at 06:33:21AM -0400, Jeff King wrote: By the way, in addition to not showing objects in order, list-all-objects (and my cat-file option) may show duplicates. Do we want to sort -u for the user? It might be

Re: Improvements to integer option parsing

On 22 Jun 2015, at 23:09, Junio C Hamano gits...@pobox.com wrote: Charles Bailey char...@hashpling.org writes: - marginally improved the opterror message on failed parses I'd queue with s/a integer/a non-negative integer/. Ha! That's what I had before I submitted, but then the source

Re: [PATCH] Add list-all-objects command

On Mon, Jun 22, 2015 at 04:38:22AM -0400, Jeff King wrote: On Sun, Jun 21, 2015 at 08:20:31PM +0100, Charles Bailey wrote: + prepare_packed_git(); + for (p = packed_git; p; p = p-next) { + open_pack_index(p); + } Yikes. The fact that you need to do this means

[PATCH 2/3] contrib/subtree: Fix broken -chains and revealed test error

From: Charles Bailey cbaile...@bloomberg.net This fixes two instances where a -chain was broken in the subtree tests and fixes a test error that was revealed because of this. Many tests in t7900-subtree.sh make a commit and then use 'undo' to reset the state for the next test. In the 'check hash

[PATCH 1/3] contrib/subtree: Use tabs consitently for indentation in tests

From: Charles Bailey cbaile...@bloomberg.net Although subtrees tests uses more spaces for indentation than tabs, there are still quite a lot of lines indented with tabs. As tabs conform with Git coding guidelines resolve the inconsistency in favour of tabs. Signed-off-by: Charles Bailey cbaile

[PATCH 3/3] contrib/subtree: Small tidy-up to test

From: Charles Bailey cbaile...@bloomberg.net There's no need to switch branches to parse another branch's ancestry. Signed-off-by: Charles Bailey cbaile...@bloomberg.net --- contrib/subtree/t/t7900-subtree.sh | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/contrib/subtree

Re: [PATCH 2/2] Move unsigned long option parsing out of pack-objects.c

On Sun, Jun 21, 2015 at 07:25:44PM +0100, Charles Bailey wrote: From: Charles Bailey cbaile...@bloomberg.net diff --git a/parse-options.c b/parse-options.c index 80106c0..101b649 100644 --- a/parse-options.c +++ b/parse-options.c @@ -180,6 +180,23 @@ static int get_value(struct

[PATCH 1/2] Correct test-parse-options to handle negative ints

From: Charles Bailey cbaile...@bloomberg.net Fix the printf specification to treat 'integer' as the signed type that it is and add a test that checks that we parse negative option arguments. Signed-off-by: Charles Bailey cbaile...@bloomberg.net --- t/t0040-parse-options.sh | 2 ++ test-parse

[PATCH 2/2] Move unsigned long option parsing out of pack-objects.c

From: Charles Bailey cbaile...@bloomberg.net The unsigned long option parsing (including 'k'/'m'/'g' suffix parsing) is more widely applicable. Add support for OPT_MAGNITUDE to parse-options.h and change pack-objects.c use this support. The error behavior on parse errors follows

Improvements to integer option parsing

This is a re-roll of the first two patches in my previous series which used to include filter-objects which is now a separate topic. [PATCH 1/2] Correct test-parse-options to handle negative ints The first one has changed only in that I've moved the additional test to a more logical place in the

Fast enumeration of objects

This is a re-casting of my previous filter-objects command but without any of the filtering so it is now just list-all-objects. I have retained the --verbose option which outputs the same format as the default cat-file --batch-check as it provides a useful performance gain to filtering though

[PATCH] Add list-all-objects command

From: Charles Bailey cbaile...@bloomberg.net list-all-objects is a command to print the ids of all objects in the object database of a repository. It is designed as a low overhead interface for scripts that want to analyse all objects but don't require the ordering implied by a revision walk

Re: [PATCH 2/3] Move unsigned long option parsing out of pack-objects.c

On Fri, Jun 19, 2015 at 10:58:51AM -0700, Junio C Hamano wrote: Charles Bailey char...@hashpling.org writes: Please place it immediately after INTEGER, as they are conceptually siblings---group similar things together. Sorry, this is a bad habit from working on projects where changing

[PATCH 3/3] Add filter-objects command

From: Charles Bailey cbaile...@bloomberg.net filter-objects is a command to scan all objects in the object database for the repository and print the ids of those which match the given criteria. The current supported criteria are object type and the minimum size of the object. The guiding use

Re: [PATCH 3/3] Add filter-objects command

On Fri, Jun 19, 2015 at 06:10:10AM -0400, Jeff King wrote: On Fri, Jun 19, 2015 at 10:10:59AM +0100, Charles Bailey wrote: filter-objects is a command to scan all objects in the object database for the repository and print the ids of those which match the given criteria. The current

Re: [PATCH 2/3] Move unsigned long option parsing out of pack-objects.c

On Fri, Jun 19, 2015 at 01:03:25PM +0200, Remi Galan Alfonso wrote: It's trivial matter but the line: + output 2 output.err should be written: + output 2output.err It was incorrectly written before but since you are modifying the line, it might be a good thing to change it now.

[PATCH 2/3] Move unsigned long option parsing out of pack-objects.c

From: Charles Bailey cbaile...@bloomberg.net The unsigned long option parsing (including 'k'/'m'/'g' suffix parsing) is more widely applicable. Add support for OPT_ULONG to parse-options.h and change pack-objects.c use this support. Signed-off-by: Charles Bailey cbaile...@bloomberg.net

Improvements to parse-options and a new filter-objects command

In my team we've been looking for a fast way to check a large number of repositories for large files, which are typically unintentionally checked in binaries, so that we can warn repository owners and help them tidy up as desired. There seem to be two main approaches to scripting this. The first

[PATCH 1/3] Correct test-parse-options to handle negative ints

From: Charles Bailey cbaile...@bloomberg.net Fix the printf specification to treat 'integer' as the signed type that it is and add a test that checks that we parse negative option arguments. Signed-off-by: Charles Bailey cbaile...@bloomberg.net --- t/t0040-parse-options.sh | 2 ++ test-parse

Re: [PATCH v8 2/4] cat-file: teach cat-file a '--literally' option

On Mon, Apr 20, 2015 at 09:22:47PM +0530, karthik nayak wrote: On 04/20/2015 02:49 PM, Charles Bailey wrote: As far as I could tell - and please correct me if I've misunderstood, cat-file's literally is about dealing with unrecognized types whereas hash-object's --literally is about both

Re: [PATCH v8 2/4] cat-file: teach cat-file a '--literally' option

On Mon, Apr 20, 2015 at 02:27:44PM +0530, Karthik Nayak wrote: Sorry, but I didn't get you, broken objects created using hash-object --literally do not work with cat-file without the --literally option. Perhaps an example would help: I cannot create a bad tree without --literally: $ echo

Re: [PATCH v8 2/4] cat-file: teach cat-file a '--literally' option

On 20 Apr 2015, at 06:30, Junio C Hamano gits...@pobox.com wrote: Charles Bailey char...@hashpling.org writes: The option isn't a true opposite of hash-object's --literally because that also allows the creation of known types with invalid contents (e.g. corrupt trees) whereas cat-file

Re: [PATCH v8 2/4] cat-file: teach cat-file a '--literally' option

On Wed, Apr 15, 2015 at 10:29:34PM +0530, Karthik Nayak wrote: Currently 'git cat-file' throws an error while trying to print the type or size of a broken/corrupt object. This is because these objects are usually of unknown types. Teach git cat-file a '--literally' option where it prints

Re: [PATCH] Add failing test for fetching from multiple packs over dumb httpd

On Tue, Jan 27, 2015 at 01:12:21PM -0500, Jeff King wrote: On Tue, Jan 27, 2015 at 03:20:41PM +, Charles Bailey wrote: From: Charles Bailey cbaile...@bloomberg.net When objects are spread across multiple packs, if an initial fetch does require all pack files, a subsequent fetch

Re: [PATCH] dumb-http: do not pass NULL path to parse_pack_index

On Tue, Jan 27, 2015 at 03:02:27PM -0500, Jeff King wrote: Discovery and tests by Charles Bailey char...@hashpling.org. Signed-off-by: Jeff King p...@peff.net --- I'm happy to flip the authorship on this. You have more lines in it than I do. :) No, I'm happy with you taking the blame

[PATCH] Add failing test for fetching from multiple packs over dumb httpd

From: Charles Bailey cbaile...@bloomberg.net When objects are spread across multiple packs, if an initial fetch does require all pack files, a subsequent fetch for objects in packs not retrieved in the initial fetch will fail. --- I'm not very familiar with the http client code so this analysis

Re: git ls-files -o seems to ignore .gitignore

On Mon, Oct 27, 2014 at 07:16:49AM +0100, Richard PALO wrote: Hash: SHA1 I'm having an issue in that 'git ls-files -o' seems to ignore [parts of] .gitignore whereas other commands, such as 'git status' seem fine. This is, as far as I am aware, by design. If you want to apply the standard

Re: [PATCH v2 1/2] mergetool: don't require a work tree for --tool-help

On 11 Oct 2014, at 09:29, David Aguilar dav...@gmail.com wrote: Thanks for the heads-up. I tested mergetool and it seems fine but indeed there's an `if test -e $GIT_DIR/MERGE_RR` in there that is surely not working as intended. One solution would be to move the work done in the test

Re: [PATCH] mergetool: use more conservative temporary filenames

While you have the lid of this section of code, should we consider (optionally?) using a tmpdir to alleviate the eclipse issue where it wants temporary merge files to be the canonical locations for definitions of things that it finds when scanning source files in the project tree? [Apologies

Re: [PATCH v2 1/2] mergetool: don't require a work tree for --tool-help

On 10 Oct 2014, at 09:51, David Aguilar dav...@gmail.com wrote: Changes since v1: NONGIT_OK=Yes was added to make it actually work outside of a git repo. Does this actually work? The reason that I haven't got around to resending my re-roll is that I found that I needed changes to

Re: What's cooking in git.git (Aug 2014, #02; Fri, 8)

On Fri, Aug 08, 2014 at 03:18:11PM -0700, Junio C Hamano wrote: * cb/mergetool-difftool (2014-07-21) 2 commits - difftool: don't assume that default sh is sane - mergetool: don't require a work tree for --tool-help Update the way the difftool --help shows the help message that is shared

Re: Apple violating git LGPL?

On Wed, Aug 06, 2014 at 02:10:08PM -0400, Robert P Fischer wrote: 3. The version of git I ran is clearly NOT a plain vanilla official git, it is a derivative work. Has Apple provided the source code of the special version that I just ran? If not, that would seem to be a violation of the

[PATCH] Fix contrib/subtree Makefile to patch #! line

From: Charles Bailey cbaile...@bloomberg.net Signed-off-by: Charles Bailey cbaile...@bloomberg.net --- The main Git Makefile does this, but not the contrib/subtree Makefile. SHELL_PATH should be respected if set (especially on Solaris where /bin/sh is very legacy). The sed command is a copy

[PATCH 1/2] mergetool: don't require a work tree for --tool-help

From: Charles Bailey cbaile...@bloomberg.net Signed-off-by: Charles Bailey cbaile...@bloomberg.net --- You can call git difftool --tool-help outside of a work tree but not mergetool --tool-help but there's not real reason for this restriction and it can be easily relaxed by deferring

[PATCH 2/2] difftool: don't assume that default sh is sane

From: Charles Bailey cbaile...@bloomberg.net git-difftool used to create a command list script containing $( ... ) and explicitly call sh -c with this list. Instead, allow mergetool --tool-help to take a mode parameter and call mergetool directly to invoke the show_tool_help function. This mode

Re: [PATCH 2/2] difftool: don't assume that default sh is sane

On Sat, Jul 19, 2014 at 06:21:32PM +0100, John Keeping wrote: What's the reason for forcing `--tool-help` to be the last option? Wouldn't it be simpler to just change the top-level case statement to: --tool-help=*) TOOL_MODE=${1#--tool-help=}

Re: [PATCH] Fix filter-branch to eliminate duplicate mapped parents

On Mon, Jun 30, 2014 at 10:20:27PM +0100, Charles Bailey wrote: From: Charles Bailey cbaile...@bloomberg.net This change ensure that duplicate parents are pruned before the parent filter and ensures that --prune-empty is idempotent, removing all empty non-merge commits in a singe pass. s

[PATCH] Fix filter-branch to eliminate duplicate mapped parents

From: Charles Bailey cbaile...@bloomberg.net When multiple parents of a merge commit get mapped to the same commit, filter-branch used to pass all instances of the parent commit to the parent and commit filters and to git commit-tree or git_commit_non_empty_tree. This can often happen when

Re: [PATCH] Add extra logic required to detect endianness on Solaris

On Thu, May 01, 2014 at 11:58:26AM -0700, Junio C Hamano wrote: This patch seems to address two unrelated issues in that. (1) The existing support does not help a platform where the convention is to define either _BIG_ENDIAN (with one leading underscore) or _LITTLE_ENDIAN and

[PATCH] Detect endianness on more platforms that don't use BYTE_ORDER

--- compat/bswap.h | 33 - 1 file changed, 24 insertions(+), 9 deletions(-) diff --git a/compat/bswap.h b/compat/bswap.h index 120c6c1..f08a9fe 100644 --- a/compat/bswap.h +++ b/compat/bswap.h @@ -101,19 +101,34 @@ static inline uint64_t git_bswap64(uint64_t x)

Re: [PATCH] Detect endianness on more platforms that don't use BYTE_ORDER

On Fri, May 02, 2014 at 09:48:58AM -0700, Junio C Hamano wrote: Charles Bailey cbaile...@bloomberg.net writes: --- Please sign-off your patches ;-) Oops! Please consider this patch... Signed-off-by: Charles Bailey cbaile...@bloomberg.net This swaps the precedence of BYTE_ORDER

Re: [PATCH] Detect endianness on more platforms that don't use BYTE_ORDER

On Fri, May 02, 2014 at 12:43:32PM -0700, Junio C Hamano wrote: So,... I am inclined to queue this on top of your patch at least for now, before I go into incommunicado-mode to finish preparing -rc2. Yes, I'd agree with that. -- To unsubscribe from this list: send the line unsubscribe git in

[PATCH] Add extra logic required to detect endianness on Solaris

Signed-off-by: Charles Bailey cbaile...@bloomberg.net --- The endian detection added in 7e3dae494 isn't sufficient for the Solaris Studio compilers. This adds some fallback logic which works for Solaris but would also work for AIX and Linux if it were needed. compat/bswap.h | 21

Re: [PATCH 2/2] mergetool: run prompt only if guessed tool

On Tue, Apr 22, 2014 at 02:56:22AM -0500, Felipe Contreras wrote: An explicitly set mergetool.prompt = true would override the default. See the patch. I have had a chance to test the patch now and it looks good. I think when glancing at it before I missed the change that dropped || echo true

Re: [PATCH 2/2] mergetool: run prompt only if guessed tool

On Mon, Apr 21, 2014 at 09:59:52PM -0700, David Aguilar wrote: [Cc:ing Charles in case he has an opinion, this behavior dates back to the original MT] On Sun, Apr 20, 2014 at 07:17:34PM -0500, Felipe Contreras wrote: It's annoying to see the prompt: Hit return to start merge

Re: [PATCH 2/2] mergetool: run prompt only if guessed tool

On Tue, Apr 22, 2014 at 01:24:09AM -0500, Felipe Contreras wrote: This is what I get when a tool is not working: Documentation/config.txt seems unchanged. Was the merge successful? [y/n] Does this happen now even with merge tools for which we do trust the exit code? If so, my original

Re: [PATCH 2/2] mergetool: run prompt only if guessed tool

On Tue, Apr 22, 2014 at 01:53:46AM -0500, Felipe Contreras wrote: Charles Bailey wrote: On Tue, Apr 22, 2014 at 01:24:09AM -0500, Felipe Contreras wrote: This is what I get when a tool is not working: Documentation/config.txt seems unchanged. Was the merge successful? [y/n

[PATCH 2/2] Don't rely on strerror text when testing rmdir failure

. Signed-off-by: Charles Bailey cbaile...@bloomberg.net --- t/t3600-rm.sh | 5 ++--- t/t7001-mv.sh | 3 +-- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh index 3d30581..23eed17 100755 --- a/t/t3600-rm.sh +++ b/t/t3600-rm.sh @@ -709,10 +709,9

[PATCH 1/2] Remove inline from git_fnmatch in dir.c

Now that it calls a static inline function, it cannot be an inline definition with external linkage. Remove inline and make it an external definition. Signed-off-by: Charles Bailey cbaile...@bloomberg.net --- dir.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/dir.c b

AIX fixes

[PATCH 1/2] Remove inline from git_fnmatch in dir.c There are currently a few issues with building on AIX. These two patches address two of them. The first removes 'inline' from a function in dir.c. The function has grown such that I don't really see a benefit in explicitly encouraging the

Re: [PATCH 2/2] Don't rely on strerror text when testing rmdir failure

On Sat, Mar 29, 2014 at 04:48:44PM +0100, Jens Lehmann wrote: Am 29.03.2014 16:39, schrieb Charles Bailey: diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh index 3d30581..23eed17 100755 --- a/t/t3600-rm.sh +++ b/t/t3600-rm.sh @@ -709,10 +709,9 @@ test_expect_success 'checking out a commit

Re: [PATCH 5/5] log: do not segfault on gmtime errors

On Mon, Feb 24, 2014 at 02:49:05AM -0500, Jeff King wrote: +# date is within 2^63-1, but enough to choke glibc's gmtime +test_expect_success 'absurdly far-in-future dates produce sentinel' ' + commit=$(munge_author_date HEAD 99) + echo Thu Jan 1 00:00:00 1970 +

Re: [PATCH] t4212: handle systems with post-apocalyptic gmtime

On Wed, Mar 26, 2014 at 03:40:43PM -0400, Jeff King wrote: On Wed, Mar 26, 2014 at 03:33:59PM -0400, Jeff King wrote: That being said, is the AIX value actually right? I did not look closely at first, but just assumed that it was vaguely right. But: 99 / (86400 * 365)

Re: [PATCH] t4212: handle systems with post-apocalyptic gmtime

On Wed, Mar 26, 2014 at 04:38:30PM -0400, Jeff King wrote: By the way, can you confirm that this is a 64-bit system? On a 32-bit system, we should be triggering different code paths (we fail at the strtoul level). Those should be checked by the previous tests, but I'd like to make sure.

Re: [PATCH] t4212: handle systems with post-apocalyptic gmtime

On Wed, Mar 26, 2014 at 03:33:59PM -0400, Jeff King wrote: That being said, is the AIX value actually right? I did not look closely at first, but just assumed that it was vaguely right. But: 99 / (86400 * 365) is something like 31 billion years in the future, not 160

Re: [PATCH] t4212: handle systems with post-apocalyptic gmtime

On Wed, Mar 26, 2014 at 05:57:41PM -0400, Jeff King wrote: Hmm, so the year you got is actually: 1623969404. That still seems off to me by a factor 20. I don't know if this is really worth digging into that much further, but I wonder what you would get for timestamps of: 9

Re: [RFC 0/3] Make git more user-friendly during a merge conflict

On Fri, Feb 28, 2014 at 03:01:53AM -0600, Stephen Leake wrote: Jonathan Nieder jrnie...@gmail.com writes: And for experienced users, this would be a bad regression. Backward incompatibility is a real concern. It might be best if git reset (with _no_ option) be made to error out, so all

Re: [RFC PATCH 2/3] mergetools/kdiff3: allow opting-out of auto-merges

On Thu, May 09, 2013 at 03:17:30PM -0700, David Aguilar wrote: Generally, mergetool.tool.cmd is not general enough since we've always special cased the base vs. no-base code paths and we run different commands depending on whether a base is available. Then this is a deficiency of the .cmd

Re: What should mergetool do with --no-prompt?

On Tue, Aug 14, 2012 at 12:07:26AM -0700, David Aguilar wrote: Right now there are two code paths, resolving deletion conflicts and resolving symlink conflicts, in git-mergetool that do not honor --no-prompt. They force user-interaction with the shell even though the caller (such as a

Re: What should mergetool do with --no-prompt?

On Tue, Aug 14, 2012 at 08:06:56AM -0700, Junio C Hamano wrote: Could it be that the calling user or script does not even have a terminal but still can spawn the chosen mergetool backend and interact with the user via its GUI? Or it may have a terminal that is hard for the user to interact