[PATCHv2] push: add recurseSubmodules config option

The --recurse-submodules command line parameter has existed for some time but it has no config file equivalent. Following the style of the corresponding parameter for git fetch, let's invent push.recurseSubmodules to provide a default for this parameter. This also requires the addition of

Re: fatal: Unable to read current working directory: No error

Hi Sean, On Tue, 27 Oct 2015, Sean Krauth wrote: > I've encountered a problem and I haven't had any success with my own > troubleshooting or googling so I'd appreciate some help. I noticed the > issue originally when I changed a file name in windows explorer. I was > working on a website and I

Re: [git-for-windows] Git a single file from remote

Hi Chaz, On Mon, 16 Nov 2015, Chaz wrote: > An origin git repository has been setup. Added a remote repository > (remotegit). > > "git remote -v show" displays both origin and remote links. > > What is the best way to copy a single file from the remote repo to the > origin repo? This is

[PATCH v4 2/2] completion: add support for completing email aliases

From: Jacob Keller Using the new --dump-aliases option from git-send-email, add completion for --to, --cc, --bcc, and --from with the available configured aliases. Signed-off-by: Jacob Keller --- Notes: - v2 * Use git-send-email for

[PATCH v4 1/2] sendemail: teach git-send-email to dump alias names

From: Jacob Keller Add an option "--dump-aliases" which changes the default behavior of git-send-email. This mode will simply read the alias files configured by sendemail.aliasesfile and sendemail.aliasfiletype and dump a list of all configured aliases, one per line. The

Problem with gitk since git-version 2.6, probably a problem with language/locale

Hello everybody, since git-version 2.6, I get the following error on all of the machines here at work: Error in startup script: bad menu entry index "Ansicht bearbeiten ..." while executing ".bar.view entryconf [mca "Edit view..."] -state normal" invoked from within "if {$cmdline_files

Re: [PATCH v2 1/2] sendemail: teach git-send-email to list aliases

On Tue, Nov 17, 2015 at 4:26 AM, SZEDER Gábor wrote: > > Quoting Eric Sunshine : > >> On Tue, Nov 17, 2015 at 12:10:35AM +, Keller, Jacob E wrote: >>> >>> On Mon, 2015-11-16 at 18:50 -0500, Eric Sunshine wrote: >>> > It should be possible to extract

Re: [PATCH v2 1/2] sendemail: teach git-send-email to list aliases

Quoting Eric Sunshine : On Tue, Nov 17, 2015 at 12:10:35AM +, Keller, Jacob E wrote: On Mon, 2015-11-16 at 18:50 -0500, Eric Sunshine wrote: > It should be possible to extract the alias within the shell itself > without a separate process. For instance: > >

Re: [PATCH 0/5] ff-refs: builtin command to fast-forward local refs

Mike Rappazzo venit, vidit, dixit 17.11.2015 14:58: > (This message is off list) [cut the message part, though no big secrets there] Hi Mike, I don't think there's a point in discussing this off-list. Your intentions are clearer now, yes, or else I would have asked more. I still don't like the

Re: [PATCH 0/5] ff-refs: builtin command to fast-forward local refs

On Tue, Nov 17, 2015 at 10:28 AM, Michael J Gruber wrote: > Mike Rappazzo venit, vidit, dixit 17.11.2015 14:58: > > I still don't like the idea of having a new command just for the purpose > of fast-forwarding local branches from specified upstreams. > > What's wrong

Re: Problem with gitk since git-version 2.6, probably a problem with language/locale

Hi Manuel, On Tue, 17 Nov 2015, Manuel Neubauer wrote: > since git-version 2.6, I get the following error on all of the machines here > at work: > > Error in startup script: bad menu entry index "Ansicht bearbeiten ..." > while executing > ".bar.view entryconf [mca "Edit view..."] -state

Re: fatal: Unable to read current working directory: No error

Hi Peff, On Wed, 28 Oct 2015, Jeff King wrote: > On Tue, Oct 27, 2015 at 07:29:39PM -0400, Sean Krauth wrote: > > > This seemed like about as good of an excuse as any to update Git. I > > was running v. 2.5.1-32-bit and so I downloaded v. 2.6.2-32-bit, > > installed it. And it ran, kinda. I no

Re: [PATCH v5 3/6] git-p4: retry kill/cleanup operations in tests with timeout

On Tue, Nov 17, 2015 at 4:34 AM, Luke Diamand wrote: >>> While implementing it I thought more about it. P4D is only >>> supported on platforms that support the date function. That means >>> these tests will only run on platforms that support the date >>> function. Consequently I

Re: [PATCH v2] blame: avoid checking if a file exists on the working tree if a revision is provided

On Tue, Nov 17, 2015 at 2:48 PM, Jeff King wrote: > On Tue, Nov 17, 2015 at 12:11:25AM -0500, Eric Sunshine wrote: > >> > blame content even if the path provided does match an existing >> > blob on said revision. >> >> git-blame documentation does not advertise "blame " as a >>

Re: [PATCH v5 3/6] git-p4: retry kill/cleanup operations in tests with timeout

>> >> Which other platforms are we talking about here? >> >> https://www.perforce.com/downloads/helix >> >> From there, you can get Solaris10, HP-UX, AIX and various flavours of BSD. >> Solaris supports "date +%s". > > The question about "date +%s" portability arose with a suggestion to > employ

Re: [PATCH v2] blame: avoid checking if a file exists on the working tree if a revision is provided

On Tue, Nov 17, 2015 at 5:37 PM, Edmundo Carmona Antoranz wrote: > So, do I forget about the blame patch (given that I'm not fixing an > advertised syntax, even if it's supported) and fix annotate instead or > do I fix both? And if I should swing for both, do I create a

Re: [PATCH v2] blame: avoid checking if a file exists on the working tree if a revision is provided

On Tue, Nov 17, 2015 at 5:48 PM, Jeff King wrote: > On Tue, Nov 17, 2015 at 12:11:25AM -0500, Eric Sunshine wrote: >> > blame content even if the path provided does match an existing >> > blob on said revision. >> >> git-blame documentation does not advertise "blame " as a >>

Re: [PATCH v2] blame: avoid checking if a file exists on the working tree if a revision is provided

On Mon, Nov 16, 2015 at 11:11 PM, Eric Sunshine wrote: > > This subject is a bit long; try to keep it to about 72 characters or less. > > More importantly, though, it doesn't give us a high level overview of > the purpose of the patch, which is that it is fixing blame to

Re: [PATCH 3/4] diff-highlight: match up lines before highlighting

On Tue, Nov 17, 2015 at 12:18:28AM -0500, Jonathan Lebon wrote: > > In the other thread I mentioned earlier, the solution I cooked up was > > dropping highlighting entirely for hunks over a certain percentage of > > highlighting. I wonder if we could do something similar here (e.g., > > don't

[PATCH 2/2] send-email: expand paths in sendemail.{to,cc}cmd config

These configuration variables specify the paths to commands so we should support tilde-expansion for files inside a user's home directory. Signed-off-by: John Keeping --- git-send-email.perl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH] check-ignore: correct documentation about output

On Mon, Nov 16, 2015 at 04:22:16PM -0800, Stefan Beller wrote: > +cc Jeff > > On Mon, Nov 16, 2015 at 6:13 AM, Dennis Kaarsemaker > wrote: > > Ping. > > Junio is on vacation, so Jeff is our interim maintainer, > and it seems he isn't up to full power as Junio. :) Yes,

Re: [PATCH v2] blame: avoid checking if a file exists on the working tree if a revision is provided

On Tue, Nov 17, 2015 at 12:11:25AM -0500, Eric Sunshine wrote: > > blame content even if the path provided does match an existing > > blob on said revision. > > git-blame documentation does not advertise "blame " as a > valid invocation. It does advertise "blame -- ", and this > case already

Re: [PATCH v2] blame: avoid checking if a file exists on the working tree if a revision is provided

On Tue, Nov 17, 2015 at 06:01:25PM -0500, Eric Sunshine wrote: > On Tue, Nov 17, 2015 at 5:48 PM, Jeff King wrote: > > On Tue, Nov 17, 2015 at 12:11:25AM -0500, Eric Sunshine wrote: > >> > blame content even if the path provided does match an existing > >> > blob on said revision.

verify_pack ignores return value of verify_fn

In pack-check.c, line 129, a caller-supplied verification function is called. The function returns an int, but that return value is ignored. The only caller of verify_pack is in builtin/fsck.c, whose verify_fn *does* return a meaningful error code (which is then ignored). If it were not

Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail

On Mon, Nov 16, 2015 at 8:25 PM, Stefan Beller wrote: > Instead of having to search all branches for the requested sha1, we could have > some sort of data structure to make it not an O(n) operation (n being > all objects > in the repo). > > Maybe I overestimate the work which

Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail

On Tue, Nov 17, 2015 at 12:39 PM, Jens Lehmann wrote: > Am 17.11.2015 um 21:04 schrieb Stefan Beller: >> >> On Tue, Nov 17, 2015 at 11:46 AM, Jens Lehmann >> wrote: >>> >>> >>> But for quite some time you'll have older servers out there that >>> don't

Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail

On Tue, Nov 17, 2015 at 11:46 AM, Jens Lehmann wrote: > > But for quite some time you'll have older servers out there that > don't support fetching a single sha1 or aren't configured to do so. Only when talking about the open source side. If you have all the

Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail

Am 16.11.2015 um 23:56 schrieb Stefan Beller: On Mon, Nov 16, 2015 at 1:42 PM, Jens Lehmann wrote: Am 16.11.2015 um 20:25 schrieb Stefan Beller: On Mon, Nov 16, 2015 at 10:59 AM, Jens Lehmann wrote: Am 14.11.2015 um 01:10 schrieb Stefan Beller:

Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail

Am 17.11.2015 um 21:49 schrieb Stefan Beller: I assumed we'd have yet another flag to activate the new behavior, but if you want to roll out that new feature as a default, I agree on needing the fallback. Ah, I was under the impression that users are surprised by --depth not propagating into

[PATCH 1/2] send-email: expand path in sendemail.smtpsslcertpath config

As it says in the name, the SSL certificate path is a path so treat it as one and support tilde-expansion. Signed-off-by: John Keeping --- git-send-email.perl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-send-email.perl b/git-send-email.perl index

[PATCH v1] annotate: skip checking working tree if a revision is provided

If a file has been deleted/renamed, annotate refuses to work because the file does not exist on the working tree anymore (even if the path provided does match a blob on said revision). Signed-off-by: Edmundo Carmona Antoranz --- builtin/blame.c | 5 +++--

[BUG] pre-applypatch can no longer add to staging area

Hi, At $dayjob we've been using a pre-applypatch hook to keep an eye on some software metrics as sub-area maintainers receive changes from developers. When a particular metric goes up we inform the maintainer that they should reject the patch and stop 'git am' from continuing. When the metric

[RFC/PATCH] send-email: die if CA path doesn't exist

If the CA path isn't found it's most likely to indicate a misconfiguration, in which case accepting any certificate is unlikely to be the correct thing to do. Signed-off-by: John Keeping --- git-send-email.perl | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff

[PATCH] blame: add test case for using tag object as a final ref

It was discovered [1] that 1b0d4a broke blaming starting from tag object. Add test which verifies such blaming works. [1] http://mid.gmane.org/20151117224809.ge27...@sigill.intra.peff.net Signed-off-by: Max Kirillov --- Thank you. Sorry, I should have noticed that obj ended

Re: [PATCH] blame: add test case for using tag object as a final ref

On Wed, Nov 18, 2015 at 07:36:32AM +0200, Max Kirillov wrote: > It was discovered [1] that 1b0d4a broke blaming starting from tag object. > Add test which verifies such blaming works. > > [1] http://mid.gmane.org/20151117224809.ge27...@sigill.intra.peff.net > > Signed-off-by: Max Kirillov

Re: [PATCH v2 1/2] sendemail: teach git-send-email to list aliases

On Mon, Nov 16, 2015 at 11:20 PM, Eric Sunshine wrote: > Since git-send-email.perl already configures GetOpt::Long with the > 'pass_through' option, one possibility would be to invoke > GetOptions() once for --list-aliases (or --dump-aliases), and then > again for the

Re: [PATCH v3 1/2] sendemail: teach git-send-email to dump alias names

On Mon, Nov 16, 2015 at 7:29 PM, Jacob Keller wrote: > Add an option "dump-aliases" which changes the default behavior of It would be easier to understand that this is a new command-line option (as opposed to a configuration or other option) if you spelled it

Re: [PATCH v3 2/2] completion: add support for completing email aliases

On Mon, Nov 16, 2015 at 7:29 PM, Jacob Keller wrote: > Using the new --dump-alias-names option from git-send-email, add completion s/dump-alias-names/dump-aliases/ > for --to, --cc, and --bcc with the available configured aliases. "--from" is missing from this list.

Re: [PATCH v3 1/2] sendemail: teach git-send-email to dump alias names

On Tue, Nov 17, 2015 at 12:07 AM, Eric Sunshine wrote: > On Mon, Nov 16, 2015 at 7:29 PM, Jacob Keller > wrote: >> Add an option "dump-aliases" which changes the default behavior of > > It would be easier to understand that this is a new

[PATCH 0/5] parse-options: allow -h as a short option

The short option -h is hard-wired in parseopt to list the options of a command together with a short explanation. If -h is to be given a different meaning then the flag PARSE_OPT_NO_INTERNAL_HELP has to be specified, which turns off handling for -h, --help and --help-all (except that --help

[PATCH 3/5] parse-options: allow -h as a short option

Let callers provide their own handler for the short option -h even without the flag PARSE_OPT_NO_INTERNAL_HELP, but call the internal handler (showing usage information) if that is the only parameter. Implement the first part by checking for -h only if parse_short_opt() can't find it and returns

[PATCH 4/5] grep: stop using PARSE_OPT_NO_INTERNAL_HELP

The flag PARSE_OPT_NO_INTERNAL_HELP is set to allow overriding the option -h, except when it's the only one given. This is the default behavior now, so remove the flag and the hand-rolled --help-all handling. The internal --help-all handler now actually shows hidden options, i.e. --debug in this

[PATCH 2/5] parse-options: inline parse_options_usage() at its only remaining caller

Signed-off-by: Rene Scharfe --- parse-options.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/parse-options.c b/parse-options.c index f0b6d9b..4863966 100644 --- a/parse-options.c +++ b/parse-options.c @@ -5,10 +5,6 @@ #include "color.h"

[PATCH 5/5] show-ref: stop using PARSE_OPT_NO_INTERNAL_HELP

The flag PARSE_OPT_NO_INTERNAL_HELP is set to allow overriding the option -h, except when it's the only one given. This is the default behavior now, so remove the flag and the hand-rolled --help-all handling. The internal --help-all handler now actually shows hidden options, i.e. -h in this

Re: [PATCH v5 3/6] git-p4: retry kill/cleanup operations in tests with timeout

On 16 Nov 2015, at 22:14, Eric Sunshine wrote: > On Sun, Nov 15, 2015 at 8:08 AM, wrote: >> From: Lars Schneider >> >> In rare cases kill/cleanup operations in tests fail. Retry these >> operations with a timeout

Re: [PATCH v5 5/6] git-p4: add trap to kill p4d on test exit

On 16 Nov 2015, at 09:43, Luke Diamand wrote: > On 15/11/15 13:08, larsxschnei...@gmail.com wrote: >> From: Lars Schneider >> >> Sometimes the "prove" test runner hangs on test exit because p4d is >> still running. Add a trap to always kill "p4d" on

Re: [PATCH v5 3/6] git-p4: retry kill/cleanup operations in tests with timeout

While implementing it I thought more about it. P4D is only supported on platforms that support the date function. That means these tests will only run on platforms that support the date function. Consequently I wondered if this would justify the slightly more complicated code. However, if you

[PATCH 1/5] parse-options: deduplicate parse_options_usage() calls

Avoid long lines and repeating parse_options_usage() calls with their duplicate parameters by providing labels with speaking names to jump to. Signed-off-by: Rene Scharfe --- parse-options.c | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git

Re: [PATCH v5 3/6] git-p4: retry kill/cleanup operations in tests with timeout

On 16 Nov 2015, at 09:36, Luke Diamand wrote: > On 15/11/15 13:08, larsxschnei...@gmail.com wrote: >> From: Lars Schneider >> >> In rare cases kill/cleanup operations in tests fail. Retry these >> operations with a timeout to make the test less

Re: [PATCH v5 3/6] git-p4: retry kill/cleanup operations in tests with timeout

On 17/11/15 08:22, Lars Schneider wrote: On 16 Nov 2015, at 09:36, Luke Diamand wrote: On 15/11/15 13:08, larsxschnei...@gmail.com wrote: From: Lars Schneider In rare cases kill/cleanup operations in tests fail. Retry these operations with a

Re: [PATCH v5 3/6] git-p4: retry kill/cleanup operations in tests with timeout

On Tue, Nov 17, 2015 at 3:28 AM, Lars Schneider wrote: > On 16 Nov 2015, at 22:14, Eric Sunshine wrote: >> On Sun, Nov 15, 2015 at 8:08 AM, wrote: >>> From: Lars Schneider >>> >>> In rare

Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail

On Sun, Nov 15, 2015 at 01:53:31PM +0100, Lars Schneider wrote: > > Hrm. Do we want to make these workarounds work correctly? Or is the > > final solution going to be that the first command you gave simply works, > > and no workarounds are needed. If the latter, I wonder if we want to be > >

Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail

On Tue, Nov 17, 2015 at 09:17:43PM +0100, Duy Nguyen wrote: > On Mon, Nov 16, 2015 at 8:25 PM, Stefan Beller wrote: > > Instead of having to search all branches for the requested sha1, we could > > have > > some sort of data structure to make it not an O(n) operation (n

Re: [PATCH] Optimize usage of grep by passing -q

On Mon, Nov 16, 2015 at 05:04:24PM -0800, Stefan Beller wrote: > >> This is true for the gnu version of grep. I am not sure if all > >> versions of grep support this optimization. In case it is not, > >> we'd revert this patch. > > > > POSIX specifies -q, so you should be fine. > >

[PATCH 0/2] send-email config path expansion

These two patches enable tilde-expansion for a few more config variables in git-send-email. The first case is the one that surprised me when it didn't work, the second two are the other ones that look like they should be handled as paths. John Keeping (2): send-email: expand path in

Re: [PATCH 2/6] remote-http(s): Support SOCKS proxies

Pat Thoyts writes: > A bit late to the party but 'yes'. Frankly by posting something to SO I > rather consider it public domain ... Unless otherwise noted, material posted on stackoverflow by default becomes CC-SA-BY (which may not be the best choice for open