Re: t5400 failure on Windows

On Tue, May 16, 2017 at 08:35:46PM +0200, Johannes Sixt wrote: > Am 16.05.2017 um 00:24 schrieb Jeff King: > >4. There is something racy and unportable about both programs writing > > to the same trace file. It's opened with O_APPEND, which means that > > each write should

[PATCH] sha1dc: fix issues with a big endian platform

From: Marc Stevens Some big-endian platforms define _BIG_ENDIAN, which the test at the beginning of file has missed. Also, when the input is not aligned, some platforms trigger SIGBUS. This change corresponds to 33a694a9 ("Fix issues with a big endian platform",

Re: [PATCHv2 12/20] submodule.c: convert show_submodule_summary to use emit_line_fmt

Stefan Beller writes: > In a later patch, I want to propose an option to detect > moved lines in a diff, which cannot be done in a one-pass over > the diff. Instead we need to go over the whole diff twice, > because we cannot detect the first line of the two corresponding >

Re: [PATCHv2 11/20] diff.c: convert emit_rewrite_lines to use emit_line_*

Stefan Beller writes: > In a later patch, I want to propose an option to detect > moved lines in a diff, which cannot be done in a one-pass over > the diff. Instead we need to go over the whole diff twice, > because we cannot detect the first line of the two corresponding >

Re: [fixed] error using `git mergetool --tool=meld`

I'm on Meld 3.16.0, OSX 10.12.4, git 2.12.2 and haven't changed any git or meld code. Let me know when its fixed so I can turn hasOutput back on? Thanks and good luck. On 5/16/17 9:05 PM, Samuel Lijin wrote: On Tue, May 16, 2017 at 5:55 PM, Matthew Groth wrote: I

Re: t5545: reduced test coverage

Junio C Hamano writes: > Junio C Hamano writes: > >> It appears to me that only a few tests in the entire script wants to >> work with HTTP server, so perhaps moving them to the end, together >> with the inclusion of lib-httpd and start_httpd that 438fc684

Re: t5545: reduced test coverage

Junio C Hamano writes: > It appears to me that only a few tests in the entire script wants to > work with HTTP server, so perhaps moving them to the end, together > with the inclusion of lib-httpd and start_httpd that 438fc684 ("push > options: pass push options to the

Re: [PATCH v6 04/11] run-command: use the async-signal-safe execv instead of execvp

Jeff King writes: > This is about finding "/usr/bin/foo", realizing it cannot be exec'd > because it lacks a shebang line, and then pretending that it did have > "#!/bin/sh". IOW, maintaining compatibility with execvp(). > > So the command itself isn't a shell command, but it may

Re: [PATCH v1 2/5] Teach git to optionally utilize a file system monitor to speed up detecting new or changed files.

On 5/16/2017 5:41 PM, Jonathan Tan wrote: I'm not very familiar with this part of the code - here is a partial review. Firstly, if someone invokes update-index, I wonder if it's better just to do a full refresh (e.g. by deleting the last_update time from the index). A full refresh can be

Re: [PATCH] completion: add git stash push

Jonathan Nieder writes: > Thomas Gummerer wrote: > >> When introducing git stash push in f5727e26e4 ("stash: introduce push >> verb", 2017-02-19), I forgot to add it to the completion code. Add it >> now. >> >> Signed-off-by: Thomas Gummerer >> --- >>

[PATCH] t5545: enhance test coverage when no http server is installed

In commit 438fc68462 ("push options: pass push options to the transport helper", 08-02-2017), the test coverage was reduced to run no tests at all if you lack a http server. Move the http initialization to the end, such that only http tests are skipped when a http server is missing. The test in

[PATCHv2 10/20] diff.c: convert emit_rewrite_diff to use emit_line_*

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv2 18/20] diff.c: emit_line includes whitespace highlighting

Currently any whitespace highlighting happens outside the emit_line function. Teach the highlighting to emit_line, triggered by a new parameter. Signed-off-by: Stefan Beller --- diff.c | 104 +++- diff.h | 4

[PATCHv2 09/20] diff.c: convert builtin_diff to use emit_line_*

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv2 13/20] diff.c: convert emit_binary_diff_body to use emit_line_*

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv2 15/20] diff.c: convert word diffing to use emit_line_*

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv2 19/20] diff: buffer all output if asked to

Introduce a new option 'use_buffer' in the struct diff_options which controls whether all output is buffered up until all output is available. We'll have a new struct 'buffered_patch_line' in diff.h which will be used to buffer each line. The buffered_patch_line will duplicate the memory of the

[PATCHv2 05/20] diff.c: emit_line_0 can handle no color setting

In later patches we may pass lines that are not colored to the central function emit_line_0, so we need to emit the color only when it is non-NULL. We could have chosen to pass "" instead of NULL, but that would be more work. Signed-off-by: Stefan Beller --- diff.c | 6

[PATCHv2 08/20] diff.c: convert fn_out_consume to use emit_line

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv2 20/20] diff.c: color moved lines differently

When there is a lot of code moved around such as in 11979b9 (2005-11-18, "http.c: reorder to avoid compilation failure.") for example, the review process is quite hard, as it is not mentally challenging. It is a rather tedious process, that gets boring quickly. However you still need to read

[PATCHv2 12/20] submodule.c: convert show_submodule_summary to use emit_line_fmt

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv2 17/20] diff.c: convert diff_summary to use emit_line_*

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv2 16/20] diff.c: convert diff_flush to use emit_line_*

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv2 14/20] diff.c: convert show_stats to use emit_line_*

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv2 06/20] diff.c: emit_line_0 takes parameter whether to output line prefix

In later patches we'll make extensive use of emit_line_0, as we'd want to funnel all output through this function such that we can add buffering there. Signed-off-by: Stefan Beller --- diff.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git

[PATCHv2 11/20] diff.c: convert emit_rewrite_lines to use emit_line_*

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv2 02/20] diff: move line ending check into emit_hunk_header

The emit_hunk_header() function is responsible for assembling a hunk header and calling emit_line() to send the hunk header to the output file. Its only caller fn_out_consume() needs to prepare for a case where the function emits an incomplete line and add the terminating LF. Instead make sure

[PATCHv2 01/20] diff: readability fix

We already have dereferenced 'p->two' into a local variable 'two'. Use that. Signed-off-by: Stefan Beller --- diff.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/diff.c b/diff.c index 74283d9001..3f5bf8b5a4 100644 --- a/diff.c +++ b/diff.c @@

[PATCHv2 07/20] diff.c: inline emit_line_0 into emit_line

The argument list of emit_line_0 is just 2 more arguments that are hard-coded in emit_line. Eliminate this intermediate function and rename the remaining function by dropping the '_0'. Signed-off-by: Stefan Beller --- diff.c | 34 ++ 1 file

[PATCHv2 04/20] diff.c: teach emit_line_0 to accept sign parameter

Teach emit_line_0 take an optional "sign" parameter specifically intended to hold the sign of the line instead of a separate "first" parameter representing the first character of the line to be printed. Callers that store the sign and line separately can use the "sign" parameter like they used

[PATCHv2 03/20] diff.c: factor out diff_flush_patch_all_file_pairs

In a later patch we want to do more things before and after all filepairs are flushed. So factor flushing out all file pairs into its own function that the new code can be plugged in easily. Signed-off-by: Stefan Beller --- diff.c | 17 - 1 file changed, 12

[PATCHv2 00/20] Diff machine: highlight moved lines.

v2: * emit_line now takes an argument that indicates if we want it to emit the line prefix as well. This should allow for a more faithful refactoring in the beginning. (Thanks Jonathan!) * fixed memleaks (Thanks Brandon!) * "git -c color.moved=true log -p" works now! (Thanks Jeff) * interdiff

Re: Diff topic branch + working copy changes?

Robert Dailey writes: > So for a topic branch based on master, I can diff ONLY my changes on > the topic branch by doing this simple command: > > $ git diff origin/master... > > However, this does not include uncommitted working copy changes. To > work around this, I

Re: [PATCH] tests: add an optional test to test git-annex

Ævar Arnfjörð Bjarmason writes: > Add an optional test to test git-annex. It's guarded by a new > EXTERNAL_TESTS environment variable. Running this test takes me 10 > minutes. Well, it is one thing to place git-annex under CI to make sure its latest and greatest works

Re: t5545: reduced test coverage

Ramsay Jones writes: > Hi Junio, > > I noticed, when comparing the test-suite output from v2.12.0 > versus v2.13.0-rc0 on cygwin, that t5545-push-options.sh was > no longer being run. (Well, now being skipped because it can't > find a web-server). Prior to commit

Re: [PATCH v6 04/11] run-command: use the async-signal-safe execv instead of execvp

On Tue, May 16, 2017 at 10:26:02PM -0400, Jeff King wrote: > On Wed, May 17, 2017 at 11:15:43AM +0900, Junio C Hamano wrote: > > > > + if (errno == ENOEXEC) > > > + execv(argv.argv[0], (char *const *) argv.argv); > > > > "/bin/sh" tries to run "/usr/bin/git" that was not

Re: [PATCH v6 04/11] run-command: use the async-signal-safe execv instead of execvp

On Wed, May 17, 2017 at 11:15:43AM +0900, Junio C Hamano wrote: > > + if (errno == ENOEXEC) > > + execv(argv.argv[0], (char *const *) argv.argv); > > "/bin/sh" tries to run "/usr/bin/git" that was not executable (well, > the one in "usr/bin/" would have +x bit, but

Re: [PATCH v6 04/11] run-command: use the async-signal-safe execv instead of execvp

Brandon Williams writes: > @@ -238,6 +238,12 @@ static void prepare_cmd(struct argv_array *out, const > struct child_process *cmd) > if (!cmd->argv[0]) > die("BUG: command is empty"); > > + /* > + * Add SHELL_PATH so in the event exec fails with

RE: Donation

From: Bamasi, Benafsha Sent: Tuesday, May 16, 2017 5:35 PM Cc: taylorrobinson...@outlook.com Subject: Donation I am terry Jones , Mrs Gloria Mackenzie is donating 700,000$ contact her through her personal email

Re: [PATCH 0/2] Demonstrate and partially work around a gitattributes problem

On Wed, May 17, 2017 at 10:38:36AM +0900, Junio C Hamano wrote: > > - add_pending_object(revs, a_obj, this); > > - add_pending_object(revs, b_obj, next); > > + add_pending_object_with_path(revs, a_obj, this, > > +

Re: git-scm.com status report

On Tue, May 16, 2017 at 09:56:37PM -0400, Samuel Lijin wrote: > So I've finally found the time to get everything set up (in the > process discovering that remote_genbook2 consistently induces a > segfault in VirtualBox's networking driver, impressively enough) and > am taking a look at how much

Re: git-scm.com status report

On Mon, Feb 6, 2017 at 1:27 PM, Jeff King wrote: > On Thu, Feb 02, 2017 at 03:33:50AM +0100, Jeff King wrote: > >> We (the Git project) got control of the git-scm.com domain this year. We >> have never really had an "official" website, but I think a lot of people >> consider this

Re: [PATCH 0/2] Demonstrate and partially work around a gitattributes problem

Jeff King writes: > diff --git a/builtin/diff.c b/builtin/diff.c > index d184aafab..8ed1e99e3 100644 > --- a/builtin/diff.c > +++ b/builtin/diff.c > @@ -409,7 +409,7 @@ int cmd_diff(int argc, const char **argv, const char > *prefix) > if (2 <= blobs) >

Re: [fixed] error using `git mergetool --tool=meld`

On Tue, May 16, 2017 at 5:55 PM, Matthew Groth wrote: > I needed to use `git config mergetool.meld.hasOutput false` Hm, that's interesting - the source code snippet you quoted from meld implies it supports --output. What version of meld do you have? David Aguilar seems to be

Re: [PATCH 1/2] refs: Add for_each_worktree_ref for iterating over all worktree HEADs

I *think* I got send-email to work but I can't be certain :) The tabs seem to be back! It didn't thread correctly, unsure why. Sorry about the patch problems, On Tue, May 16, 2017 at 5:50 PM, wrote: > From: Manish Goregaokar > > To ensure that

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Ævar Arnfjörð Bjarmason writes: > It seems pretty haphazard to me, is it even documented somewhere? > > I'm talking about an establish process backed up by code, where for > example I can add an experimental feature in v2.14.0, it'll be subject > to change & warn unless you

[PATCH 2/2] reachable: Add HEADs of all worktrees to reachability analysis

From: Manish Goregaokar * reachable.c: mark_reachable_objects: Include other worktrees Signed-off-by: Manish Goregaokar --- reachable.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/reachable.c b/reachable.c index d0199ca..439708e

[PATCH 1/2] refs: Add for_each_worktree_ref for iterating over all worktree HEADs

From: Manish Goregaokar To ensure that `git prune` does not remove refs checked out in other worktrees, we need to include these HEADs in the set of roots. This adds the iteration function necessary to do this. Signed-off-by: Manish Goregaokar ---

Re: [PATCH 1/2] refs: Add for_each_worktree_ref for iterating over all worktree HEADs

(+cc: Duy, worktree expert) Hi Manish, Manish Goregaokar wrote: > Git prune will happily delete commits checked out in other worktrees. > This is probably not desired. Yikes. Thanks for working on it. > (Tabs have been converted to spaces in this email sadly, because GMail > garbles these.

RE: Donation

Good Day, My wife and I have awarded you with a donation of $ 1,000,000.00 Dollars from part of our Jackpot Lottery of 50 Million Dollars, respond with your details for claims. We await your earliest response and God Bless you. Friedrich And Annand Mayrhofer. --- This email has been checked

Re: [PATCH 1/2] refs: Add for_each_worktree_ref for iterating over all worktree HEADs

>From 3f8015efdcc122e0d345baeb5f1f0485a9f0fcd8 Mon Sep 17 00:00:00 2001 From: Manish Goregaokar Date: Tue, 16 May 2017 16:46:36 -0700 Subject: [PATCH 2/2] reachable: Add HEADs of all worktrees to reachability analysis * reachable.c: mark_reachable_objects: Include other

[PATCH 1/2] refs: Add for_each_worktree_ref for iterating over all worktree HEADs

Git prune will happily delete commits checked out in other worktrees. This is probably not desired. (Tabs have been converted to spaces in this email sadly, because GMail garbles these. This should suffice for review, and I'll send the patch as an attachment or in some other form when done so

Re: [PATCH v4] send-email: --batch-size to work around some SMTP server limit

> 在 2017年5月17日，07:49，Junio C Hamano 写道： > > Junio C Hamano writes: > >> xiaoqiang zhao writes: >> ... >>> Note: >>> Re-authentication will happen every $ messages, so it >>> will be much more acceptable if you use some form of

Re: [PATCH v4] send-email: --batch-size to work around some SMTP server limit

在 2017年5月17日，01:43，Ævar Arnfjörð Bjarmason 写道： >>> Regards >>> Jan >> >> Thank you for reporting this，I will take a look . > > You just need to initialize the variables you're using, see e.g. these > existing ones: > >my ($quiet, $dry_run) = (0, 0); > > Just do the

Re: [PATCH v4] send-email: --batch-size to work around some SMTP server limit

Junio C Hamano writes: > xiaoqiang zhao writes: > ... >> Note: >>Re-authentication will happen every $ messages, so it >> will be much more acceptable if you use some form of credential helper >> (e.g. the 'sendemail.smtppass' config option), otherwise

[Bug] git branch -v has problems with carriage returns

Hi, I upgraded to git v2.13.0 and since then git branch -v has problems with carriage returns in subject lines. We are using gitlab (not the newest version). So this bug (It's about carriage returns in auto-generated merge messages (\r\n)) is not yet fixed in our version:

Re: [PATCH] tests: add an optional test to test git-annex

Nice work. Note that you can export BUILDER=stack and git-annex will build with a known good dependency stack, which can be more reliable/cross platform than using apt to install its build dependencies. That needs https://docs.haskellstack.org/ installed. Also it currently needs

[fixed] error using `git mergetool --tool=meld`

I needed to use `git config mergetool.meld.hasOutput false`

RE: Donation

Good Day, My wife and I have awarded you with a donation of $ 1,000,000.00 Dollars from part of our Jackpot Lottery of 50 Million Dollars, respond with your details for claims. We await your earliest response and God Bless you. Friedrich And Annand Mayrhofer. --- This email has been checked

Re: [PATCH v1 2/5] Teach git to optionally utilize a file system monitor to speed up detecting new or changed files.

I'm not very familiar with this part of the code - here is a partial review. Firstly, if someone invokes update-index, I wonder if it's better just to do a full refresh (e.g. by deleting the last_update time from the index). Also, the change to unpack-trees.c doesn't match my mental model. I

Re: error using `git mergetool --tool=meld`

I tried `git config mergetool.meld.hasOutput true` followed again by `git mergetool --tool=meld` and got the same error. My original message: When using `git mergetool --tool=kdiff3`, it works fine. But with `git mergetool --tool=meld` I get this for every merge conflict:

Re: [TANGENT] run-command: use vfork instead of fork

On 05/16, Linus Torvalds wrote: > On Tue, May 16, 2017 at 12:35 PM, Eric Wong wrote: > > > > Fwiw, most of the vfork preparation was already done by Brandon > > and myself a few weeks ago, and cooking in pu. > > Oh, interesting. Was that done for vfork(), or is it for something >

Re: clone vs submodule operation with HTTP cURL

On Tue, May 16, 2017 at 8:15 PM, Jean-Francois Bouchard wrote: > Hello, > > Anyone can help with this ? The workaround is hardly possible in a > medium environment as it needs editing and adding env to everyone and > in every clone. According to git-config anyauth is the

Re: [TANGENT] run-command: use vfork instead of fork

On Tue, May 16, 2017 at 12:35 PM, Eric Wong wrote: > > Fwiw, most of the vfork preparation was already done by Brandon > and myself a few weeks ago, and cooking in pu. Oh, interesting. Was that done for vfork(), or is it for something else? Some of the changes seem almost overly

[PATCH] tests: add an optional test to test git-annex

Add an optional test to test git-annex. It's guarded by a new EXTERNAL_TESTS environment variable. Running this test takes me 10 minutes. As reported by Joey Hess in "reversion in GIT_COMMON_DIR refs path"[1] commit f57f37e2e1 ("files-backend: remove the use of git_path()", 2017-03-26) first

Re: git rebase regression: cannot pass a shell expression directly to --exec

On Tue, May 16, 2017 at 1:12 PM, Johannes Schindelin wrote: >> >> I think it would be better to just >> >> (a) get rid of the magic strcspn() entirely >> >> (b) make the 'can we optimize this' test be simply just looking up >> 'argv[0]' in $PATH > > What about > >

Re: Cant clone/pull/fetch because of "Unable to create temporary file '$HOME/Dev/linux-stable/.git/objects/pack/tmp_pack_'

2017-05-16 12:38 GMT+02:00 Kevin Daudt : > On Mon, May 15, 2017 at 12:28:58AM +0200, Thomas Schweikle wrote: >> $ git clone >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git >> linux-stable >> Cloning into 'linux-stable'... >> remote: Counting objects:

Re: git rebase regression: cannot pass a shell expression directly to --exec

Hi Linus, On Tue, 16 May 2017, Linus Torvalds wrote: > On Tue, May 16, 2017 at 10:23 AM, Jeff King wrote: > > > > I think the logic here would be more like: > > > > 1. During prepare_shell_cmd(), even if we optimize out the shell call, > > still prepare a fallback argv

Re: [PATCH] completion: add git stash push

Thomas Gummerer wrote: > When introducing git stash push in f5727e26e4 ("stash: introduce push > verb", 2017-02-19), I forgot to add it to the completion code. Add it > now. > > Signed-off-by: Thomas Gummerer > --- > contrib/completion/git-completion.bash | 5 - > 1

[PATCH] completion: add git stash push

When introducing git stash push in f5727e26e4 ("stash: introduce push verb", 2017-02-19), I forgot to add it to the completion code. Add it now. Signed-off-by: Thomas Gummerer --- contrib/completion/git-completion.bash | 5 - 1 file changed, 4 insertions(+), 1

[TANGENT] run-command: use vfork instead of fork

Linus Torvalds wrote: > Also, if people really want to optimize the code that executes an > external program (whether in shell or directly), I think it might be > worth it to look at replacing the "fork()" with a "vfork()". > > Something like this > > -

Diff topic branch + working copy changes?

So for a topic branch based on master, I can diff ONLY my changes on the topic branch by doing this simple command: $ git diff origin/master... However, this does not include uncommitted working copy changes. To work around this, I can do this instead: $ git diff origin/master (No three-dot

Re: git rebase regression: cannot pass a shell expression directly to --exec

On Tue, May 16, 2017 at 10:23 AM, Jeff King wrote: > > I think the logic here would be more like: > > 1. During prepare_shell_cmd(), even if we optimize out the shell call, > still prepare a fallback argv (since we can't allocate memory > post-fork). > > 2. In the

Re: [PATCH v1 2/5] Teach git to optionally utilize a file system monitor to speed up detecting new or changed files.

Am 16.05.2017 um 19:17 schrieb Ben Peart: OK, now I'm confused as to the best path for adding a get_be64. This one is trivial: #define get_be64(p)ntohll(*(uint64_t *)(p)) I cringe when I see a cast like this. Unless you can guarantee that p is char* (bare or signed or unsigned), you

Re: bug with git add and .gitignore

On Wed, May 10, 2017 at 9:44 AM, Orgad Shaneh wrote: > Hi, > > When a not-ignored file inside an ignore directory is added along with > other files, a false alarm is shown: > > git init > echo /d/ > .gitignore > mkdir d > touch d/file foo > git add -f d/file foo > git add d/file

Re: error using `git mergetool --tool=meld`

Can you try `git config mergetool.meld.hasOutput true` and see if that fixes the issue?

Re: t5400 failure on Windows

Am 16.05.2017 um 00:24 schrieb Jeff King: 4. There is something racy and unportable about both programs writing to the same trace file. It's opened with O_APPEND, which means that each write should atomically position the pointer at the end of the file. Is it possible

error using `git mergetool --tool=meld`

When using `git mergetool --tool=kdiff3`, it works fine. But with `git mergetool --tool=meld` I get this for every merge conflict: ``` Normal merge conflict for 'builders/pdfBuilder.py': {local}: created file {remote}: created file Traceback (most recent call last): File

Re: clone vs submodule operation with HTTP cURL

Hello, Anyone can help with this ? The workaround is hardly possible in a medium environment as it needs editing and adding env to everyone and in every clone. Thanks !! JF On Mon, May 15, 2017 at 5:38 PM, Jean-Francois Bouchard wrote: > Hello, > > Follow-up to this

Re: reversion in GIT_COMMON_DIR refs path

Ævar Arnfjörð Bjarmason wrote: > On Tue, May 16, 2017 at 7:10 PM, Joey Hess wrote: > > Bisecting this test suite failure > > https://git-annex.branchable.com/git-annex_in_nixpkgs_fails_with_git-2.13.0/ > > I landed on commit f57f37e2e1bf11ab4cdfd221ad47e961ba9353a0 to git. > >

Re: reversion in GIT_COMMON_DIR refs path

On Tue, May 16, 2017 at 7:10 PM, Joey Hess wrote: > Bisecting this test suite failure > https://git-annex.branchable.com/git-annex_in_nixpkgs_fails_with_git-2.13.0/ > I landed on commit f57f37e2e1bf11ab4cdfd221ad47e961ba9353a0 to git. That links's broken for me. Looking at your

Re: [PATCH v1 2/5] Teach git to optionally utilize a file system monitor to speed up detecting new or changed files.

On Tue, May 16, 2017 at 01:17:56PM -0400, Ben Peart wrote: > > Thanks for the pointers. I'll update this to use the existing get_be32 > > and have created a get_be64 and will use that for the last_update. > > OK, now I'm confused as to the best path for adding a get_be64. This one is >

Re: [PATCH v4] send-email: --batch-size to work around some SMTP server limit

On Tue, May 16, 2017 at 3:55 PM, 赵小强 wrote: > > >> 在 2017年5月16日，20:10，Jan Viktorin 写道： >> >> Hello, >> >> with this patch applied to git 2.12, I could see: >> >> Use of uninitialized value $batch_size in numeric eq (==) at >>

Re: git rebase regression: cannot pass a shell expression directly to --exec

On Tue, May 16, 2017 at 10:29:31AM -0700, Eric Rannaud wrote: > > It does not really work that way. Git runs in a separate process that > > does not have access to your current shell. That's why you need to do > > 'export -f foo'. > > > > If you want git to be able to ecute the foo shell

Re: git rebase regression: cannot pass a shell expression directly to --exec

On Tue, May 16, 2017 at 10:21:51AM -0700, Eric Rannaud wrote: > On Tue, May 16, 2017 at 9:59 AM, Eric Rannaud wrote: > > When I use "git rebase --exec " I'm basically writing a "foreach > > commit in range { }" in my shell. Same idea with git bisect run. > > > > A

Re: git rebase regression: cannot pass a shell expression directly to --exec

Jeff King wrote: >>> On Mon, May 15, 2017 at 11:25:03PM -0400, Jeff King wrote: One hack would be to look for BASH_FUNC_* in the environment and disable the optimization in that case. I think that would make your case Just Work. It doesn't help other oddball cases, like: [...] >>

Re: git rebase regression: cannot pass a shell expression directly to --exec

On 05/16, Jeff King wrote: > On Tue, May 16, 2017 at 10:15:40AM -0700, Brandon Williams wrote: > > > > > > So I was thinking something like the patch below, though I guess > > > > > technically you could look for BASH_FUNC_$argv[0]%%, which seems to be > > > > > bash's magic variable name. I hate

Re: git rebase regression: cannot pass a shell expression directly to --exec

On Tue, May 16, 2017 at 10:14 AM, Kevin Daudt wrote: >> A transparent optimization that tries execve() then falls back to the >> user's shell sounds like a good idea. > > It does not really work that way. Git runs in a separate process that > does not have access to your current

Re: git rebase regression: cannot pass a shell expression directly to --exec

On Tue, May 16, 2017 at 10:15:40AM -0700, Brandon Williams wrote: > > > > So I was thinking something like the patch below, though I guess > > > > technically you could look for BASH_FUNC_$argv[0]%%, which seems to be > > > > bash's magic variable name. I hate to get too intimate with those > > >

Re: git rebase regression: cannot pass a shell expression directly to --exec

On Tue, May 16, 2017 at 9:59 AM, Eric Rannaud wrote: > When I use "git rebase --exec " I'm basically writing a "foreach > commit in range { }" in my shell. Same idea with git bisect run. > > A transparent optimization that tries execve() then falls back to the > user's

Re: [PATCH v1 2/5] Teach git to optionally utilize a file system monitor to speed up detecting new or changed files.

On 5/15/2017 9:55 PM, Ben Peart wrote: On 5/15/2017 8:34 PM, Jeff King wrote: On Tue, May 16, 2017 at 12:22:14AM +, brian m. carlson wrote: On Mon, May 15, 2017 at 03:13:44PM -0400, Ben Peart wrote: +istate->last_update = (time_t)ntohll(*(uint64_t *)index); +index +=

reversion in GIT_COMMON_DIR refs path

Bisecting this test suite failure https://git-annex.branchable.com/git-annex_in_nixpkgs_fails_with_git-2.13.0/ I landed on commit f57f37e2e1bf11ab4cdfd221ad47e961ba9353a0 to git. It seems that changed resolving refs paths when GIT_DIR and GIT_COMMON_DIR are both set. While before refs were looked

Re: git rebase regression: cannot pass a shell expression directly to --exec

On 05/16, Jeff King wrote: > On Tue, May 16, 2017 at 09:41:24AM -0700, Jonathan Nieder wrote: > > > Jeff King wrote: > > > On Mon, May 15, 2017 at 11:25:03PM -0400, Jeff King wrote: > > > > >> One hack would be to look for BASH_FUNC_* in the environment and disable > > >> the optimization in

Re: git rebase regression: cannot pass a shell expression directly to --exec

On Tue, May 16, 2017 at 09:59:03AM -0700, Eric Rannaud wrote: > On Tue, May 16, 2017 at 9:18 AM, Jeff King wrote: > > On Tue, May 16, 2017 at 12:23:02PM +0200, Johannes Schindelin wrote: > >> It would appear to me that you used a side effect of an implementation > >> detail: that

Re: git rebase regression: cannot pass a shell expression directly to --exec

On Tue, May 16, 2017 at 9:47 AM, Jeff King wrote: >> I think we want to behave consistently for shell builtins and for >> exported functions --- they are different sides of the same problem, >> and behaving differently between the two feels confusing. > > Yes, I think ideally we'd

Re: git rebase regression: cannot pass a shell expression directly to --exec

On Tue, May 16, 2017 at 9:18 AM, Jeff King wrote: > On Tue, May 16, 2017 at 12:23:02PM +0200, Johannes Schindelin wrote: >> It would appear to me that you used a side effect of an implementation >> detail: that `git rebase -i` was implemented entirely as a shell script. > > I don't

Re: git rebase regression: cannot pass a shell expression directly to --exec

On Tue, May 16, 2017 at 09:41:24AM -0700, Jonathan Nieder wrote: > Jeff King wrote: > > On Mon, May 15, 2017 at 11:25:03PM -0400, Jeff King wrote: > > >> One hack would be to look for BASH_FUNC_* in the environment and disable > >> the optimization in that case. I think that would make your case

Re: git rebase regression: cannot pass a shell expression directly to --exec

On Mon, May 15, 2017 at 8:53 PM, Jeff King wrote: >> > So I suspect if you added an extraneous semi-colon, your case would work >> > again (and that would confirm for us that this is indeed the problem). >> >> Wow, that's a brilliant analysis. > > If it's right. :) It's all theory

Re: [PATCH 18/19] diff: buffer all output if asked to

On Mon, May 15, 2017 at 9:14 PM, Jonathan Tan wrote: > Overall, this patch seems larger than it should to me, although there > might be good reasons for that that I don't know. I'll remark on what > I find unexpected. > >> >> +static void

Re: git rebase regression: cannot pass a shell expression directly to --exec

(+Brandon Williams, who may have more context for execvp-related things) Hi, Jeff King wrote: > On Mon, May 15, 2017 at 11:25:03PM -0400, Jeff King wrote: >> One hack would be to look for BASH_FUNC_* in the environment and disable >> the optimization in that case. I think that would make your

  1   2   >