I am Ms.Ella Golan, I am the Executive Vice President Banking Division with
FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI).
I am getting in touch with you regarding an extremely important and urgent
matter. If you would oblige me the opportunity, I shall provide you with
details upon your Response
Jeff King writes:
> All of the regressions people have actually _noticed_ stem from my
> 136c8c8b8f in v2.14.2. So I think it is a viable option to try to go
> back to the pre-v2.14.2 state. I.e.:
> ...
> That takes us back to the pre-regression state. The ancient bug from
> 4c7f1819 still exists
Jeff King writes:
> Here it is cleaned up and with a commit message. There's another case
> that can be optimized, too: --remove-empty with an all-deletions commit.
> That's probably even more obscure and pathological, but it was easy to
> cover in the same breath.
This one looks good. It appea
Jeff King writes:
> So there are two separate questions/tasks:
>
> 1. Should we remove the special handling of "-q" leftover from this
> deprecation? I think the answer is yes.
>
> 2. Should we teach the diff machinery as a whole to treat "-q" as a
> synonym for "--quiet".
Good que
Junio C Hamano writes:
>> Should we test that:
>>
>> git update-ref refs/heads/HEAD HEAD^
>>
>> continues to work?
>
> Perhaps. Also we may want to make sure that "git branch -D HEAD"
> still works as a way to recover from historical mistakes.
The only difference is improved tests where we us
Jeff King writes:
> On Fri, Oct 13, 2017 at 02:11:32PM +0900, Junio C Hamano wrote:
>
>> strbuf_check_branch_ref() is the central place where many codepaths
>> see if a proposed name is suitable for the name of a branch. It was
>> designed to allow us to get stricter than the check_refname_forma
Kevin Daudt writes:
> On Thu, Oct 05, 2017 at 02:19:15PM +0200, Johannes Schindelin wrote:
>> From: J Wyman
>> [..]
>>
>> diff --git a/Documentation/git-for-each-ref.txt
>> b/Documentation/git-for-each-ref.txt
>> index 39f50bd53eb..22767025850 100644
>> --- a/Documentation/git-for-each-ref.tx
On 10/10, Jonathan Tan wrote:
> On Tue, 3 Oct 2017 13:15:04 -0700
> Brandon Williams wrote:
>
> > 2. ssh://, file://
> >Set 'GIT_PROTOCOL' environment variable with the desired protocol
> >version. With the file:// transport, 'GIT_PROTOCOL' can be set
> >explicitly in the locally ru
On 10/10, Jonathan Nieder wrote:
> Hi,
>
> Brandon Williams wrote:
>
> > Given some of this discussion though, maybe we want to change the
> > semantics of 'protocol.version' so that both servers and clients respect
> > it. As of right now, these patches have the server always allow
> > protocol
On 10/10, Jonathan Tan wrote:
> Document the server support for Extra Parameters, additional information
> that the client can send in its first message to the server during a
> Git client-server interaction.
>
> Signed-off-by: Jonathan Tan
> ---
> I noticed that Documentation/technical was not u
On 10/10, Jonathan Tan wrote:
> On Tue, 3 Oct 2017 13:15:02 -0700
> Brandon Williams wrote:
>
> > + switch (determine_protocol_version_server()) {
> > + case protocol_v1:
> > + if (advertise_refs || !stateless_rpc)
> > + packet_write_fmt(1, "version 1\n");
> > +
On 10/10, Jonathan Tan wrote:
> On Tue, 3 Oct 2017 13:15:01 -0700
> Brandon Williams wrote:
>
> > /*
> > * Read the host as supplied by the client connection.
>
> The return value is probably worth documenting. Something like "Returns
> a pointer to the character *after* the NUL byte termina
Am 13.10.2017 um 19:51 schrieb Ralf Thielow:
> When ftruncate() in rearrange_squash() fails, we write
> that we couldn't finish the operation on the todo file.
> It is more accurate to write that we couldn't truncate
> as we do in other calls of ftruncate().
Would it make sense to factor out rewri
Previously, `-q` was silently ignored:
Before:
$ git diff -q -- Documentation/; echo $?
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index a88c767..aa6e724 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -587,6 +587,7 @@ ifndef::
Functionality was removed in c48f6816f0 but the cli option was not removed.
Signed-off-by: Anthony Sottile
---
builtin/diff-files.c | 2 --
builtin/diff.c | 2 --
diff.h | 4 +---
3 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/builtin/diff-files.c b/builtin/dif
On Fri, Oct 13, 2017 at 09:44:15AM -0700, Anthony Sottile wrote:
> Previously, `-q` was silently ignored:
I'm not sure if is totally ignored. Normally if we have an unknown
options we'd complain:
$ git diff -x
error: invalid option: -x
but we don't with "-q". Why?
In builtin/diff.c:471, we
When ftruncate() in rearrange_squash() fails, we write
that we couldn't finish the operation on the todo file.
It is more accurate to write that we couldn't truncate
as we do in other calls of ftruncate().
While at there, remove a full stop in another error message.
Signed-off-by: Ralf Thielow
-
On Fri, Oct 13, 2017 at 11:58:12AM +0900, 小川恭史 wrote:
> I want to remove multiple stashed states at a time.
>
> But "git stash drop " removes only one stashed state at a time
> and "git stash clear" remove all.
>
> Can I do that?
There isn't a way to do it through "git stash", I don't think. Th
Since 11b087adfd (ref-filter: consult want_color() before
emitting colors, 2017-07-13), we expect that setting
"color.ui" to "always" will enable color tag formats even
without a tty. As that commit was built on top of
136c8c8b8f (color: check color.ui in git_default_config(),
2017-07-13) from the
This reverts commit 136c8c8b8fa39f1315713248473dececf20f8fe7.
That commit was trying to address a bug caused by 4c7f1819b3
(make color.ui default to 'auto', 2013-06-10), in which
plumbing like diff-tree defaulted to "auto" color, but did
not respect a "color.ui" directive to disable it.
But it al
This reverts commit c5bdfe677cfab5b2e87771c35565d44d3198efda.
That commit was done primarily to prepare for the weakening
of "always" in 6be4595edb (color: make "always" the same as
"auto" in config, 2017-10-03). But since we've now reverted
6be4595edb, there's no need for us to remove "-c
color.u
This reverts commit 6be4595edb8e5b616c6e8b9fbc78b0f831fa2a87.
That commit weakened the "always" setting of color config so
that it acted as "auto". This was meant to solve regressions
in v2.14.2 in which setting "color.ui=always" in the on-disk
config broke scripts like add--interactive, because t
On Fri, Oct 13, 2017 at 09:06:38AM -0400, Jeff King wrote:
> > I think that it is too late, regardless of our release cycle.
> >
> > "Plumbing never looks at color.ui" implies that "plumbing must not
> > get color.ui=auto from 4c7f1819", but given that 4c7f1819 is from
> > 2013, I'd be surprised
Previously, `-q` was silently ignored:
Before:
$ git diff -q -- Documentation/; echo $?
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index a88c767..aa6e724 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -587,6 +587,7 @@ ifndef::
On Thu, Oct 05, 2017 at 02:19:15PM +0200, Johannes Schindelin wrote:
> From: J Wyman
> [..]
>
> diff --git a/Documentation/git-for-each-ref.txt
> b/Documentation/git-for-each-ref.txt
> index 39f50bd53eb..22767025850 100644
> --- a/Documentation/git-for-each-ref.txt
> +++ b/Documentation/git-for
On Fri, Oct 13, 2017 at 11:37:50AM -0400, Derrick Stolee wrote:
> Thanks, Peff. This patch looks good to me.
>
> I tried a few other things like adding a flag DIFF_OPT_HAS_ANY_CHANGE next
> to DIFF_OPT_HAS_CHANGES that we could check in diff_can_quit_early() but it
> had side-effects that broke e
On 10/13/2017 11:27 AM, Jeff King wrote:
On Fri, Oct 13, 2017 at 10:26:46AM -0400, Jeff King wrote:
On Fri, Oct 13, 2017 at 10:25:10AM -0400, Derrick Stolee wrote:
This does appear to be the problem. The missing DIFF_OPT_HAS_CHANGES is
causing diff_can_quit_early() to return false. Due to the
On Fri, Oct 13, 2017 at 10:26:46AM -0400, Jeff King wrote:
> On Fri, Oct 13, 2017 at 10:25:10AM -0400, Derrick Stolee wrote:
>
> > This does appear to be the problem. The missing DIFF_OPT_HAS_CHANGES is
> > causing diff_can_quit_early() to return false. Due to the corner-case of the
> > bug it se
On 10/13/2017 10:26 AM, Jeff King wrote:
On Fri, Oct 13, 2017 at 10:25:10AM -0400, Derrick Stolee wrote:
This does appear to be the problem. The missing DIFF_OPT_HAS_CHANGES is
causing diff_can_quit_early() to return false. Due to the corner-case of the
bug it seems it will not be a huge perfor
On Fri, Oct 13, 2017 at 10:25:10AM -0400, Derrick Stolee wrote:
> This does appear to be the problem. The missing DIFF_OPT_HAS_CHANGES is
> causing diff_can_quit_early() to return false. Due to the corner-case of the
> bug it seems it will not be a huge performance improvement in most cases.
> Sti
On 10/13/2017 10:20 AM, Jeff King wrote:
On Fri, Oct 13, 2017 at 10:10:18AM -0400, Jeff King wrote:
Hmm. So this patch makes it go fast:
diff --git a/revision.c b/revision.c
index d167223e69..b52ea4e9d8 100644
--- a/revision.c
+++ b/revision.c
@@ -409,7 +409,7 @@ static void file_add_remove(st
On Fri, Oct 13, 2017 at 10:10:18AM -0400, Jeff King wrote:
> Hmm. So this patch makes it go fast:
>
> diff --git a/revision.c b/revision.c
> index d167223e69..b52ea4e9d8 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -409,7 +409,7 @@ static void file_add_remove(struct diff_options *options,
>
On Fri, Oct 13, 2017 at 09:56:36AM -0400, Jeff King wrote:
> On Fri, Oct 13, 2017 at 09:55:15AM -0400, Derrick Stolee wrote:
>
> > > We should be comparing an empty tree and d0/d0/d0/d0 (or however deep
> > > your pathspec goes). We should be able to see immediately that the entry
> > > is not pr
On Fri, Oct 13, 2017 at 09:55:15AM -0400, Derrick Stolee wrote:
> > We should be comparing an empty tree and d0/d0/d0/d0 (or however deep
> > your pathspec goes). We should be able to see immediately that the entry
> > is not present between the two and not bother descending. After all,
> > we've
On 10/13/2017 9:50 AM, Jeff King wrote:
On Fri, Oct 13, 2017 at 09:39:14AM -0400, Derrick Stolee wrote:
Since I don't understand enough about the consumers to diff_tree_oid() (and
the fact that the recursive behavior may be wanted in some cases), I think
we can fix this in builtin/rev-list.c wi
On Fri, Oct 13, 2017 at 09:39:14AM -0400, Derrick Stolee wrote:
> Since I don't understand enough about the consumers to diff_tree_oid() (and
> the fact that the recursive behavior may be wanted in some cases), I think
> we can fix this in builtin/rev-list.c with this simple diff:
>
> ---
>
> di
On 10/13/2017 9:15 AM, Derrick Stolee wrote:
On 10/13/2017 8:44 AM, Jeff King wrote:
On Fri, Oct 13, 2017 at 03:12:43PM +0300, Constantine wrote:
On 13.10.2017 15:04, Junio C Hamano wrote:
Christian Couder writes:
Yeah, but perhaps Git could be smarter when rev-listing too and avoid
proces
On 10/13/2017 8:44 AM, Jeff King wrote:
On Fri, Oct 13, 2017 at 03:12:43PM +0300, Constantine wrote:
On 13.10.2017 15:04, Junio C Hamano wrote:
Christian Couder writes:
Yeah, but perhaps Git could be smarter when rev-listing too and avoid
processing files or directories it has already seen?
On Fri, Oct 13, 2017 at 02:11:32PM +0900, Junio C Hamano wrote:
> strbuf_check_branch_ref() is the central place where many codepaths
> see if a proposed name is suitable for the name of a branch. It was
> designed to allow us to get stricter than the check_refname_format()
> check used for refna
On Fri, Oct 13, 2017 at 12:37:57PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > OK. For the record, I'm not against scrapping this whole thing and
> > trying to rollback to your "plumbing never looks at color.ui" proposal.
> > It's quite late in the -rc cycle to do that, but there's no
Johannes,
On Thu, Oct 12, 2017 at 5:53 PM, Johannes Schindelin
wrote:
> Dear Git users,
>
> It is my pleasure to announce that Git for Windows 2.14.2(3) is available
> from:
>
> https://git-for-windows.github.io/
>
> Changes since Git for Windows v2.14.2(2) (October 5th 2017)
>
> New Fea
On Fri, Oct 13, 2017 at 03:12:43PM +0300, Constantine wrote:
> On 13.10.2017 15:04, Junio C Hamano wrote:
> > Christian Couder writes:
> >
> > > Yeah, but perhaps Git could be smarter when rev-listing too and avoid
> > > processing files or directories it has already seen?
> >
> > Aren't you su
On Fri, Oct 13, 2017 at 07:06:03PM +0900, Mike Hommey wrote:
> On Fri, Oct 13, 2017 at 12:51:58PM +0300, Constantine wrote:
> > There's a gitbomb on github. It is undoubtedly creative and funny, but since
> > this is a bug in git, I thought it'd be nice to report. The command:
> >
> > $ git c
On 13.10.2017 15:04, Junio C Hamano wrote:
Christian Couder writes:
Yeah, but perhaps Git could be smarter when rev-listing too and avoid
processing files or directories it has already seen?
Aren't you suggesting to optimize for a wrong case?
Anything that is possible with a software shou
Christian Couder writes:
> Yeah, but perhaps Git could be smarter when rev-listing too and avoid
> processing files or directories it has already seen?
Aren't you suggesting to optimize for a wrong case?
Moy Matthieu writes:
>>> --path::
>>> - 'git-config' will expand leading '{tilde}' to the value of
>>> + 'git config' will expand leading '{tilde}' to the value of
>>> '$HOME', and '{tilde}user' to the home directory for the
>
> Didn't notice yesterday, but you still have forward quotes
You won a donation funds of one million united states dollar. get back for
more details
On Thu, Oct 05 2017, Johannes Sixt jotted:
> Am 05.10.2017 um 21:33 schrieb Stefan Beller:
>> On Thu, Oct 5, 2017 at 12:13 PM, Johannes Sixt wrote:
>>> +git-post(1)
>>> +===
>>> +
>>> +NAME
>>> +
>>> +git-post - Apply a commit on top of a branch that is not checked out
It would be g
On Fri, Oct 13, 2017 at 12:37 PM, Mike Hommey wrote:
> On Fri, Oct 13, 2017 at 12:26:46PM +0200, Christian Couder wrote:
>>
>> After cloning it with -n, there is the following "funny" situation:
>>
>> $ time git rev-list HEAD
>> 7af99c9e7d4768fa681f4fe4ff61259794cf719b
>> 18ed56cbc5012117e24a603e7
On Fri, Oct 13, 2017 at 12:26:46PM +0200, Christian Couder wrote:
> On Fri, Oct 13, 2017 at 12:06 PM, Mike Hommey wrote:
> > On Fri, Oct 13, 2017 at 12:51:58PM +0300, Constantine wrote:
> >> There's a gitbomb on github. It is undoubtedly creative and funny, but
> >> since
> >> this is a bug in gi
On Fri, Oct 13, 2017 at 12:06 PM, Mike Hommey wrote:
> On Fri, Oct 13, 2017 at 12:51:58PM +0300, Constantine wrote:
>> There's a gitbomb on github. It is undoubtedly creative and funny, but since
>> this is a bug in git, I thought it'd be nice to report. The command:
>>
>> $ git clone https:
On Fri, Oct 13, 2017 at 12:51:58PM +0300, Constantine wrote:
> There's a gitbomb on github. It is undoubtedly creative and funny, but since
> this is a bug in git, I thought it'd be nice to report. The command:
>
> $ git clone https://github.com/x0rz/ShadowBrokersFiles
What fills memory is
There's a gitbomb on github. It is undoubtedly creative and funny, but
since this is a bug in git, I thought it'd be nice to report. The command:
$ git clone https://github.com/x0rz/ShadowBrokersFiles
quickly fills out the RAM (e.g. 4GB of free memory for me). To recover,
call oom-kill
Updated patch and added tests:
(feel free to modify Documentation)
---
Subject: [PATCH] Added support for new configuration parameter push.pushOption
builtin/push.c: add push.pushOption config
Currently push options need to be given explicitly, via
the command line as "git push --push-option".
Junio C Hamano writes:
> second.pa...@gmail.com writes:
>
>> From: PAYRE NATHAN p1508475
>
> Should I assume that the name/address on the last Signed-off-by: we
> see below is what you want to be known as? As a part of school
> work, I'd imagine that Matthieu wants your work to be associated
>
On Fri, Oct 13, 2017 at 1:11 AM, Junio C Hamano wrote:
> The function takes a parameter "attr_only" (which is a name that is
> hard to reason about, which will be corrected soon) and skips some
> checks when it is set. Reorganize the conditionals to make it move
s/move/more/
> obvious that some
On Thu, 12 Oct 2017, Jeff King wrote:
> On Fri, Oct 13, 2017 at 01:18:00AM +0200, Johannes Schindelin wrote:
>
> > [who I had to cull from the To:/Cc: headers, as my mailer consistently
> > told me that there is no valid DNS record to route mail to
> > rpj...@crashcourse.ca, which *is* weird.]
>
>
57 matches
Mail list logo
