Re: [PATCH v3 4/8] dir: hide untracked contents of untracked dirs

Samuel Lijin writes: > When we taught read_directory_recursive() to recurse into untracked > directories in search of ignored files given DIR_SHOW_IGNORED_TOO, that > had the side effect of teaching it to collect the untracked contents of > untracked directories. It doesn't always make sense to r

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

On Wed, May 17, 2017 at 4:45 AM, Junio C Hamano wrote: > Æ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. [Re-arranged your mail because it worked better with my r

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

On Wed, May 17, 2017 at 7:39 AM, Junio C Hamano wrote: > 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

Re: [PATCH v3 3/8] dir: recurse into untracked dirs for ignored files

Samuel Lijin writes: > We consider directories containing only untracked and ignored files to > be themselves untracked, which in the usual case means we don't have to > search these directories. This is problematic when we want to collect > ignored files with DIR_SHOW_IGNORED_TOO, though, so we

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 atomical

[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", 2017-05-15) in the history of th

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&color > 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 -)

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&color > 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 -)

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 needed to use `git config

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 ("push >> options: pass push options to

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 transport helper", 2017-02-

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 execute a shell

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 ver

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 >> --- >> contrib/completion/git-completion.bash | 5

[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 b

[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&color 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

[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 ++- submodule.c |

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

In a later patch, I want to propose an option to detect&color 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

[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&color 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

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

In a later patch, I want to propose an option to detect&color 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

[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 l

[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 -- 1 file changed, 4

[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&color 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

[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 throu

[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&color 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

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

In a later patch, I want to propose an option to detect&color 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

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

In a later patch, I want to propose an option to detect&color 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

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

In a later patch, I want to propose an option to detect&color 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

[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 a/diff.c b/diff.c inde

[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&color 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

[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 em

[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 @@ -3283,8 +3283,8 @@ static

[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 changed, 14 insertions(

[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 the

[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 insertions(+), 5 delet

[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 b

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 can do this instead: > > $ gi

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 together well with our lat

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 438fc68462 ("push options: > pass

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 let

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 ENOEXEC we can > +

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 (gloriazi...@hotmail.com

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 wo

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 to be one. >> >>

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 the one who's contri

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 `git prune` does not remove refs checked out > in

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 configure core.use_exp

[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 100644 --- a/reachable.c +++ b/reachable.c @@ -178,6

[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 --- refs.c | 16 refs.h | 1 + 2

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. Thi

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 f

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 worktrees Signed-off-b

[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 that

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 credential helper >>> (e.g. the 'sendemail.smtppass' config opt

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 same for the ones you

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 you will have >> to retype password eve

[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: https://gitlab.com/gitla

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 GIT_TEST_GIT_ANNEX

[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 f

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 > else? Some of th

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 default, see http.proxyAu

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 careful. Is this

[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 relea

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 > > ABC=1 my-executable my-

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: 5932092, done. >> rem

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 (since we can't all

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 file changed, 4 insertion

[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 deletion(-) diff --git a/contr

[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 > > - cmd->pid = fork(); > + cmd->pi

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 not

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 forked child, if we

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 fal

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 > # fine > git add

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 there's

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 "/usr/local/bin/me

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 post. > > I seems that setti

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. > > That links's broken

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 wiki it looks like

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 > trivial:

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 >> /usr/lib/git-core/git-send-email line 1679 >> >> when --batch-size is

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 function,

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 transparent optimization that t

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: [...] >> Hm

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 shell. That's why

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 shell sounds like a good id

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 += sizeof(ui

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 that

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 `git rebase -i` w

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 handle it all tr

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 think that's tr

  1   2   >