Dear Web-mail Account User

Dear Web-mail Account User, You have receive this message as resulting to a wrong multiple password attempt on this account, Hence we shall be blocking this account temporarily to verify the IP location. If you know this has not been done by you and want to prevent blocking of this account as

Re: 2.11.0-rc1 will not be tagged for a few days

Am 08.11.2016 um 01:40 schrieb Jeff King: In addition to J6t's fix in t0021, ... Just to get things straight: Of my two patches, this one ("uniq -c variations") https://public-inbox.org/git/c842e0a7-b032-e0c4-0995-f11d93c17...@kdbg.org/ is a bug fix in my environment, and I have a

Re: [PATCH 07/18] link_alt_odb_entry: handle normalize_path errors

On Mon, Nov 07, 2016 at 05:12:43PM -0800, Bryan Turner wrote: > > The obvious solution is one of: > > > > 1. Stop calling normalize() at all when we do not have a relative base > > and the path is not absolute. This restores the original quirky > > behavior (plus makes the

Re: [PATCH v4 1/2] lib-proto-disable: variable name fix

On Mon, Nov 7, 2016 at 12:48 PM, Jeff King wrote: > It's possible that I'm overly picky about my commit messages, but that > does not stop me from trying to train an army of picky-commit-message > clones. :) > > -Peff You're not the only one ;) Regards, Jake

[PATCH v5 1/2] lib-proto-disable: variable name fix

The test_proto function assigns the positional parameters to named variables, but then still refers to "$desc" as "$1". Using $desc is more readable and less error-prone. Signed-off-by: Brandon Williams --- t/lib-proto-disable.sh | 12 ++-- 1 file changed, 6

Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate

On Mon, Nov 7, 2016 at 4:52 PM, Ian Jackson wrote: > +log.noAbbrevTags:: > + Each value is a glob pattern, specifying tag nammes which > + should always be displayed in full, even when other tags may > + be omitted or abbreviated (for example, by

Re: [PATCH 4/5] attr: do not respect symlinks for in-tree .gitattributes

On Tue, Nov 8, 2016 at 4:15 AM, Jeff King wrote: > On Mon, Nov 07, 2016 at 04:10:10PM -0500, Jeff King wrote: > >> And I'll admit my main motivation is not that index/filesystem parity, >> but rather just that: >> >> git clone git://host.com/malicious-repo.git >> git log >> >>

Re: [PATCH 07/18] link_alt_odb_entry: handle normalize_path errors

On Mon, Nov 7, 2016 at 4:30 PM, Jeff King wrote: > On Mon, Nov 07, 2016 at 03:42:35PM -0800, Bryan Turner wrote: > >> > @@ -335,7 +340,9 @@ static void link_alt_odb_entries(const char *alt, int >> > len, int sep, >> > } >> > >> > strbuf_add_absolute_path(,

Re: [PATCH 0/6] Provide for config to specify tags not to abbreviate

Ian Jackson writes ("[PATCH 0/6] Provide for config to specify tags not to abbreviate"): > Please find in the following mails patches which provide a way to make > gitk display certain tags in full, even if they would normally be > abbreviated. > > There are four patches to gitk, three to

[PATCH 0/6] Provide for config to specify tags not to abbreviate

Hi. Please find in the following mails patches which provide a way to make gitk display certain tags in full, even if they would normally be abbreviated. There are four patches to gitk, three to prepare the ground, and one to introduce the new feature. There is one patch for git, to just

[PATCH GITK 2/6] gitk: Internal: drawtags: Idempotently reset "ntags"

The previous code tracked its change to the length of `marks' by updateing the variable `ntags'. This is a bit fragile and cumbersome, and we are going to want to modify `marks' some more in a moment. Instead, simply reset ntags to the length of marks, after we have possibly done any needed

[PATCH GITK 1/6] gitk: Internal: drawtags: Abolish "singletag" variable

We are going to want to make the contents of `marks' somewhat more complicated in a moment, so it won't be possible to use what is effectively a single variable to represent the status of the whole of the non-heads part of the marks list. Luckily the strings that replace actual tag names, in the

[PATCH GITK 4/6] gitk: Provide for config to specify tags not to abbreviate

Tags matching a new multi-valued config option log.noAbbrevTags are not abbreviated. The config setting is in git config logs.* rather than gitk's own configuration, because: - Tools which manage git trees may want to set this, depending on their knowledge of the nature of the tags likely to

[PATCH GITK 3/6] gitk: drawtags: Introduce concept of unabbreviated marks

We are going to want to show some tags in full, even if they are long or there are other tags. Do this by filtering the tags into `marks_unabbrev' and `marks'. `marks_unabbrev' bypasses the tag abbreviation, and is put on the front of the marks array after any abbreviation has been done. No

[PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate

Tags matching a new multi-valued config option log.noAbbrevTags should not be abbreviated. Currently this config option is used only by gitk (and the patch to gitk will come via the gitk maintainer tree). The config setting is in git config logs.* rather than gitk's own configuration, because:

Re: 2.11.0-rc1 will not be tagged for a few days

On Sun, Nov 06, 2016 at 06:32:05PM -0800, Junio C Hamano wrote: > I regret to report that I won't be able to tag 2.11-rc1 as scheduled > in tinyurl.com/gitCal (I am feverish and my brain is not keeping > track of things correctly) any time soon. I'll report back an > updated schedule when able.

Re: [PATCH 07/18] link_alt_odb_entry: handle normalize_path errors

On Mon, Nov 07, 2016 at 03:42:35PM -0800, Bryan Turner wrote: > > @@ -335,7 +340,9 @@ static void link_alt_odb_entries(const char *alt, int > > len, int sep, > > } > > > > strbuf_add_absolute_path(, get_object_directory()); > > - normalize_path_copy(objdirbuf.buf,

Re: [PATCH 07/18] link_alt_odb_entry: handle normalize_path errors

On Mon, Oct 3, 2016 at 1:34 PM, Jeff King wrote: > When we add a new alternate to the list, we try to normalize > out any redundant "..", etc. However, we do not look at the > return value of normalize_path_copy(), and will happily > continue with a path that could not be

Re: Git issue - ignoring changes to tracked file with assume-unchanged

W dniu 01.11.2016 o 19:11, Junio C Hamano pisze: > Jeff King writes: >> On Tue, Nov 01, 2016 at 10:28:57AM +, Halde, Faiz wrote: >> >>> I frequently use the following command to ignore changes done in a file >>> >>> git update-index --assume-unchanged somefile >>> >>> Now when

Re: [PATCH 1/3] gitk: turn off undo manager in the text widget

On Mon, Nov 7, 2016 at 10:57 AM, Markus Hitter wrote: > From e965e1deb9747bbc2b40dc2de95afb65aee9f7fd Mon Sep 17 00:00:00 2001 > From: Markus Hitter > Date: Sun, 6 Nov 2016 20:38:03 +0100 > Subject: [PATCH 1/3] gitk: turn off undo manager in the text widget >

[PATCH v5 2/2] transport: add protocol policy config option

Previously the `GIT_ALLOW_PROTOCOL` environment variable was used to specify a whitelist of protocols to be used in clone/fetch/push commands. This patch introduces new configuration options for more fine-grained control for allowing/disallowing protocols. This also has the added benefit of

Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS

On Sun, Nov 06, 2016 at 10:42:36PM +0100, Lars Schneider wrote: > > From: Lars Schneider > > > > TravisCI changed their default macOS image from 10.10 to 10.11 [1]. > > Unfortunately the HTTPD tests do not run out of the box using the > > pre-installed Apache web

Re: [PATCH 4/5] attr: do not respect symlinks for in-tree .gitattributes

On Mon, Nov 07, 2016 at 04:10:10PM -0500, Jeff King wrote: > And I'll admit my main motivation is not that index/filesystem parity, > but rather just that: > > git clone git://host.com/malicious-repo.git > git log > > might create and read symlinks to arbitrary files on the cloner's box. >

Re: [PATCH 4/5] attr: do not respect symlinks for in-tree .gitattributes

On Mon, Nov 07, 2016 at 05:03:42PM +0700, Duy Nguyen wrote: > On Wed, Nov 2, 2016 at 8:08 PM, Jeff King wrote: > > The attributes system may sometimes read in-tree files from > > the filesystem, and sometimes from the index. In the latter > > case, we do not resolve symbolic links

Re: [PATCH v4 2/2] transport: add protocol policy config option

On 11/07, Jeff King wrote: > > + test_expect_success "clone $desc (env var has precedence)" ' > > + rm -rf tmp.git && > > + ( > > + GIT_ALLOW_PROTOCOL=none && > > + export GIT_ALLOW_PROTOCOL && > > + test_must_fail git -c

Re: git push remote syntax

On Mon, Nov 07, 2016 at 01:49:40PM +, Diggory Hardy wrote: > One thing I find a little frustrating about git is that the syntax needed > differs by command. I wish the 'remote/branch' syntax was more universal: The reason it's not is that "remote/branch" refers to a branch in your local

Re: [PATCH v4 1/2] lib-proto-disable: variable name fix

On Mon, Nov 07, 2016 at 12:40:28PM -0800, Brandon Williams wrote: > On 11/07, Jeff King wrote: > > On Mon, Nov 07, 2016 at 11:35:22AM -0800, Brandon Williams wrote: > > > > > Small fix to use '$desc' instead of '$1' in lib-proto-disable.sh. > > > > Even for a trivial fixup like this, I think

Re: [PATCH] submodules: allow empty working-tree dirs in merge/cherry-pick

On Mon, Nov 7, 2016 at 12:38 PM, David Turner wrote: >> -Original Message- >> From: Stefan Beller [mailto:sbel...@google.com] >> Sent: Monday, November 07, 2016 2:14 PM >> To: David Turner >> Cc: git@vger.kernel.org >> Subject: Re: [PATCH] submodules: allow

Re: [PATCH v4 1/2] lib-proto-disable: variable name fix

On 11/07, Jeff King wrote: > On Mon, Nov 07, 2016 at 11:35:22AM -0800, Brandon Williams wrote: > > > Small fix to use '$desc' instead of '$1' in lib-proto-disable.sh. > > Even for a trivial fixup like this, I think it's good to say why. > Because what seems trivial and obvious to you while

Re: [PATCH v4 2/2] transport: add protocol policy config option

On Mon, Nov 07, 2016 at 11:35:23AM -0800, Brandon Williams wrote: > Previously the `GIT_ALLOW_PROTOCOL` environment variable was used to > specify a whitelist of protocols to be used in clone/fetch/push > commands. This patch introduces new configuration options for more > fine-grained control

RE: [PATCH] submodules: allow empty working-tree dirs in merge/cherry-pick

> -Original Message- > From: Stefan Beller [mailto:sbel...@google.com] > Sent: Monday, November 07, 2016 2:14 PM > To: David Turner > Cc: git@vger.kernel.org > Subject: Re: [PATCH] submodules: allow empty working-tree dirs in > merge/cherry-pick > > On Mon, Nov 7, 2016 at 10:31 AM, David

Re: [PATCH v4 1/2] lib-proto-disable: variable name fix

On Mon, Nov 07, 2016 at 11:35:22AM -0800, Brandon Williams wrote: > Small fix to use '$desc' instead of '$1' in lib-proto-disable.sh. Even for a trivial fixup like this, I think it's good to say why. Because what seems trivial and obvious to you while working on the patch may not be so to a

[PATCH v4 1/2] lib-proto-disable: variable name fix

Small fix to use '$desc' instead of '$1' in lib-proto-disable.sh. Signed-off-by: Brandon Williams --- t/lib-proto-disable.sh | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/t/lib-proto-disable.sh b/t/lib-proto-disable.sh index b0917d9..be88e9a

[PATCH v4 2/2] transport: add protocol policy config option

Previously the `GIT_ALLOW_PROTOCOL` environment variable was used to specify a whitelist of protocols to be used in clone/fetch/push commands. This patch introduces new configuration options for more fine-grained control for allowing/disallowing protocols. This also has the added benefit of

Re: [PATCH] submodules: allow empty working-tree dirs in merge/cherry-pick

On Mon, Nov 7, 2016 at 10:31 AM, David Turner wrote: > When a submodule is being merged or cherry-picked into a working > tree that already contains a corresponding empty directory, do not > record a conflict. > > One situation where this bug appears is: > > - Commit 1 adds

Re: [PATCH v3] transport: add protocol policy config option

On 11/04, Jeff King wrote: > > diff --git a/Documentation/config.txt b/Documentation/config.txt > > index 27069ac..5d845c4 100644 > > --- a/Documentation/config.txt > > +++ b/Documentation/config.txt > > @@ -2308,6 +2308,31 @@ pretty.:: > > Note that an alias with the same name as a built-in

[PATCH 3/3] gitk: clear array 'commitinfo' on reload

>From 8359452f426c68cc02250f25f20eaaacd2ddd001 Mon Sep 17 00:00:00 2001 From: Markus Hitter Date: Mon, 7 Nov 2016 19:02:51 +0100 Subject: [PATCH 3/3] gitk: clear array 'commitinfo' on reload After a reload we might have an entirely different set of commits, so keeping all of

[PATCH 2/3] gitk: remove closed file descriptors from $blobdifffd

>From 0a463fcd977dc9558835c373e24a095e35ca3c82 Mon Sep 17 00:00:00 2001 From: Markus Hitter Date: Mon, 7 Nov 2016 16:01:17 +0100 Subject: [PATCH 2/3] gitk: remove closed file descriptors from $blobdifffd One shouldn't have descriptors of already closed files around. The first

[PATCH 1/3] gitk: turn off undo manager in the text widget

>From e965e1deb9747bbc2b40dc2de95afb65aee9f7fd Mon Sep 17 00:00:00 2001 From: Markus Hitter Date: Sun, 6 Nov 2016 20:38:03 +0100 Subject: [PATCH 1/3] gitk: turn off undo manager in the text widget The diff text widget is read-only, so there's zero point in building an undo

[PATCH 0/3] gitk: memory consumption improvements

List, Paul, after searching for a while on why Gitk sometimes consumes exorbitant amounts of memory I found a pair of minor issues and also a big one: the text widget comes with an unlimited undo manager, which is turned on be default. Considering that each line is inserted seperately, this

Re: [PATCH v3] transport: add protocol policy config option

On 11/04, Stefan Beller wrote: > By default, if unset, ... have a default policy ... > sounds strange. How about just dropping the first 4 words here: > > Known-safe protocols (http, https, git, ssh, file) have a > default policy of `always`, known-dangerous protocols (ext) have a >

Re: git submodule add broken (2.11.0-rc1): Cannot open git-sh-i18n

On Mon, Nov 7, 2016 at 10:30 AM, Anthony Sottile wrote: > This has worked great up until now (and is very convenient for trying things > out without blowing away the system installation). What changed? > (Just guessing myself:) $ git log --grep git-sh-i18n

[PATCH] submodules: allow empty working-tree dirs in merge/cherry-pick

When a submodule is being merged or cherry-picked into a working tree that already contains a corresponding empty directory, do not record a conflict. One situation where this bug appears is: - Commit 1 adds a submodule - Commit 2 removes that submodule and re-adds it into a subdirectory

Re: git submodule add broken (2.11.0-rc1): Cannot open git-sh-i18n

$ git --version git version 1.8.5.6 $ if [ "$LATEST_GIT" = "1" ]; then ... export PATH="/tmp/git:$PATH" fi make -j 8 ... $ git --version git version 2.11.0-rc0 So you compile 2.11.0-rc0 yourself, but you do not install it, instead the $PATH

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

On Mon, 2016-11-07 at 12:46 -0500, Jeff King wrote: > Specifically I wanted to make sure that > >   FOO = bar >   FOO = >   ifdef FOO >   ... something ... >   endif > > works as if FOO had never been set in the first place. Which it seems > to, at least in GNU make (and that is the only one we

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

On Mon, Nov 07, 2016 at 12:36:34PM -0500, Paul Smith wrote: > On Mon, 2016-11-07 at 12:26 -0500, Jeff King wrote: > > I have in the back of my mind a fear that it is harder to unset a > > make variable than it is to override it with a new value (which is > > what you'd want to do here to turn

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

On Mon, 2016-11-07 at 12:26 -0500, Jeff King wrote: > I have in the back of my mind a fear that it is harder to unset a > make variable than it is to override it with a new value (which is > what you'd want to do here to turn openssl back on), It depends on what you mean by "unset". If you mean

git submodule add broken (2.11.0-rc1): Cannot open git-sh-i18n

Noticed as part of my automated tests here: https://travis-ci.org/pre-commit/pre-commit/jobs/173957051 Minimal reproduction: rm -rf /tmp/git /tmp/foo /tmp/bar git clone git://github.com/git/git --depth 1 /tmp/git pushd /tmp/git make -j 8 popd export PATH="/tmp/git:$PATH" git init /tmp/foo git

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

On Sun, Nov 06, 2016 at 08:35:04PM +0100, Lars Schneider wrote: > Good point. I think I found an even easier way to achieve the same. > What do you think about the patch below? > > [...] > > diff --git a/Makefile b/Makefile > index 9d6c245..f53fcc9 100644 > --- a/Makefile > +++ b/Makefile > @@

Re: git -C has unexpected behaviour

Hi Felix, On Mon, 7 Nov 2016, Felix Nairz wrote: > From what you are saying I can see that this expects as designed. It's > confusing in the submodule case, but I get you don't want to add extra > rules which slow down performance and mess with other people at the > same time. The "messing with

Re: Regarding "git log" on "git series" metadata

On Mon, Nov 07, 2016 at 04:42:04PM +0700, Duy Nguyen wrote: > On Mon, Nov 7, 2016 at 8:18 AM, Josh Triplett wrote: > > Once we have gitrefs, you have both alternatives: reachable (gitref) or > > not reachable (gitlink). > > > > However, if you want some way to mark

Re: [PATCH v4 08/14] i18n: add--interactive: mark edit_hunk_manually message for translation

A Seg, 10-10-2016 às 12:54 +, Vasco Almeida escreveu: > diff --git a/git-add--interactive.perl b/git-add--interactive.perl > index 045b847..861f7b0 100755 > --- a/git-add--interactive.perl > +++ b/git-add--interactive.perl > @@ -1058,6 +1058,30 @@ sub color_diff { > } @_; >  } >   >

git push remote syntax

Dear all, One thing I find a little frustrating about git is that the syntax needed differs by command. I wish the 'remote/branch' syntax was more universal: > git pull myremote/somebranch complains about the syntax; IMO it should either pull from that branch (and merge if necessary) or

Re: gitk: avoid obscene memory consumption

Am 07.11.2016 um 05:11 schrieb Paul Mackerras: >> - Storing only the actually viewed diff. It's an interactive tool, so >> there's no advantage in displaying the diff in 0.001 seconds over viewing it >> in 0.1 seconds. As far as I can see, Gitk currently stores every diff it >> gets a hold of

Forbid access to /gitweb but authorize the sub projets

Hello, I have several projects under https://myserver/gitweb and I would like to forbid the access to the root, so that the users can't list the differents projects. However, I need to let the access to the sub projects (ex: https://myserver/gitweb/?p=project1;a=summary How can I do

Re: [PATCH v1 03/19] split-index: add {add,remove}_split_index() functions

On Sun, Oct 30, 2016 at 5:06 AM, Christian Couder wrote: > On Tue, Oct 25, 2016 at 11:58 AM, Duy Nguyen wrote: >> On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder >> wrote: >>> +void remove_split_index(struct

Re: [PATCH 4/5] attr: do not respect symlinks for in-tree .gitattributes

On Wed, Nov 2, 2016 at 8:08 PM, Jeff King wrote: > The attributes system may sometimes read in-tree files from > the filesystem, and sometimes from the index. In the latter > case, we do not resolve symbolic links (and are not likely > to ever start doing so). Let's open filesystem

Re: Regarding "git log" on "git series" metadata

On Mon, Nov 7, 2016 at 8:18 AM, Josh Triplett wrote: > Once we have gitrefs, you have both alternatives: reachable (gitref) or > not reachable (gitlink). > > However, if you want some way to mark reachable objects as not > reachable, such as for a sparse checkout, external

Re: [PATCH v1 12/19] Documentation/config: add splitIndex.maxPercentChange

(sorry I got sick in the last few weeks and could not respond to this earlier) On Mon, Nov 7, 2016 at 4:44 AM, Christian Couder wrote: > Le 6 nov. 2016 09:16, "Junio C Hamano" a écrit : >> >> Christian Couder writes: >>

NOTIFICATION

We are pleased to inform you of the result of the last Email qqannual draw of our Chevrolet International Lottery Programs. The Chevrolet Email lotto draws was conducted from an exclusive list of 25,000,000 Email all over the world. and your Email is to receive a cash prize of Four Crore Thirty