Am 11.11.2016 um 19:33 schrieb Johannes Schindelin:
> Hi Stefan,
>
> On Fri, 11 Nov 2016, Johannes Schindelin wrote:
>
>> Will keep you posted,
>
> I published the prerelease:
>
> https://github.com/git-for-windows/git/releases/tag/v2.11.0-rc0.windows.2
That version brings all my PATH entries
> On 13 Nov 2016, at 02:13, Junio C Hamano wrote:
>
> Johannes Schindelin writes:
>
>>> Thanks. Dscho, does this fix both of these issues to you?
>>
>> Apparently it does because the CI jobs for `master` and for `next` pass.
>
> OK, thanks for a quick confirmation.
>
>> The one for `pu` st
Dear Sir/Madam.
Assalamu`Alaikum.
I am Dr mohammad ouattara, I have ($10.6 Million us dollars) to transfer into
your account,
I will send you more details about this deal and the procedures to follow when
I receive a positive response from you,
Have a great day,
Dr mohammad ouattara.
The delta_limit parameter to diffcore_count_changes() has been unused
since commit ba23bbc8e ("diffcore-delta: make change counter to byte
oriented again.", 2006-03-04).
Remove the parameter and adjust all callers.
Signed-off-by: Tobias Klauser
---
v2: In the commit message, reference the correc
On Mon, Nov 14, 2016 at 02:39:05PM +0100, Tobias Klauser wrote:
> The delta_limit parameter to diffcore_count_changes() has been unused
> since commit ba23bbc8e ("diffcore-delta: make change counter to byte
> oriented again.", 2006-03-04).
>
> Remove the parameter and adjust all callers.
>
> Sig
Johannes Schindelin venit, vidit, dixit 12.11.2016 11:08:
> Hi,
>
> On Fri, 11 Nov 2016, Jacob Keller wrote:
>
>> On Fri, Nov 11, 2016 at 1:27 PM, Junio C Hamano wrote:
>>> Dennis Kaarsemaker writes:
>>>
No tests or documentation updates yet, and I'm not sure whether
--follow-symlinks
Dear Git Team,
I'm having some trouble with my git software. I just would like to
'pull' a project out of a repository.
At the beginning git worked just fine but since a few days ago I'm
constantly getting the error:
Couldn't resolve host 'gitlab.lrz.de'
git did not exit cleanly (exit cod
Sorry about that -- the first version of this patch noted:
"""This one is on top of yesterday's patch, "remote-curl: don't hang when
a server dies before any output".
That's because I want my test to show that allowanysha1inhead allows a
fetch to succeed where allowreachablesha1inhead would fail.
On Mon, 14 Nov 2016 16:59:41 +0100
Robert Fellendorf wrote:
[...]
> Couldn't resolve host 'gitlab.lrz.de'
[...]
So, what happens when you open a console prompt (Click the Start menu
icon, type "cmd" without the double quotes and activate the application
found), type
ping gitlab.lrz.de
there
On 14.11.16 10:11, Lars Schneider wrote:
>
>> On 13 Nov 2016, at 02:13, Junio C Hamano wrote:
>>
>> Johannes Schindelin writes:
>>
Thanks. Dscho, does this fix both of these issues to you?
>>>
>>> Apparently it does because the CI jobs for `master` and for `next` pass.
>>
>> OK, thanks for
Hi Michael,
On Mon, 14 Nov 2016, Michael J Gruber wrote:
> why should a *file* argument (which is not a pathspec in --no-index
> mode) not be treated in the same way in which every other command treats
> a file argument?
We are talking about `<(command)` here, which is most distinctly not a
file
On Mon, Nov 14, 2016 at 05:35:56PM +0100, Torsten Bögershausen wrote:
> > What is the goal for 'pu'?
>
> > (1) Builds clean on all platforms + passes all tests
> Yes
> > (2) Builds clean on all platforms
> Yes
> > (3) Builds clean on Linux
> Yes
> > (4) Just makes new topics easily available to a
Lars Schneider writes:
>> On 13 Nov 2016, at 02:13, Junio C Hamano wrote:
>> ...
>> Earlier you said 'pu' did even not build, but do we know where this
>> "still times out" comes from? As long as I don't merge anything
>> prematurely, which I need to be careful about, it shouldn't impact
>> the
Mr. Steve Bhatti,
Drift / regionsjef
Santander Bank Plc,
47-48 Piccadilly
PICCADILLY
W1J0DT
London, Storbritannia
Hei,
Jeg er Steve Bhatti, fra Harlesden North West London, leder for regnskap
Revisjonen og formell senior programmerer sjef hos Deutsche bank, her i England
(Santander Bank Plc).
On 11/11, Stefan Beller wrote:
> On Fri, Nov 11, 2016 at 3:51 PM, Brandon Williams wrote:
>
> > +
> > + rm -rf parent sub
>
> This line sounds like a perfect candidate for "test_when_finished"
> at the beginning of the test
K will do.
--
Brandon Williams
Michael J Gruber writes:
> *My* idea of --no-index was for it to behave as similar to the
> --index-version as possible, regarding formatting etc., and to be a good
> substitute for ordinary diff. The proposed patch achieves exactly that -
Does it? It looks to me that it does a lot more.
> why
Brandon Williams writes:
> Teach grep to recursively search in submodules when provided with a
> object. This allows grep to search a submodule based on the state
> of the submodule that is present in a commit of the super project.
>
> When grep is provided with a object, the name of the object
On Wed, Nov 09, 2016 at 05:18:30PM -0500, David Turner wrote:
> In the event that a HTTP server closes the connection after giving a
> 200 but before giving any packets, we don't want to hang forever
> waiting for a response that will never come. Instead, we should die
> immediately.
I agree we
On Sun, 2016-11-13 at 18:57 -0800, Junio C Hamano wrote:
> Matt McCutchen writes:
>
> >
> > Documentation/fetch-push-security.txt | 9 +
>
> A new (consolidated) piece like this that can be included in
> multiple places is a good idea. I wonder if the original
> description in "namespa
The "SECURITY" section of the gitnamespaces(7) man page described two
ways for a client to steal data from a server that wasn't intended to be
shared. Similar attacks can be performed by a server on a client, so
adapt the section to cover both directions and add it to the
git-fetch(1), git-pull(1),
On 11/14/2016 10:10 AM, Junio C Hamano wrote:
Brandon Williams writes:
Teach grep to recursively search in submodules when provided with a
object. This allows grep to search a submodule based on the state
of the submodule that is present in a commit of the super project.
When grep is provide
Jonathan Tan writes:
>>> to:
>>> HEAD:file
>>> HEAD:sub/file
>>>
>>> Signed-off-by: Brandon Williams
>>> ---
>>
>> Unrelated tangent, but this makes readers wonder what the updated
>> trailer code would do to the last paragraph ;-). Does it behave
>> sensibly (with some sane definition of sensi
Matt McCutchen writes:
>> Yup, and then "do not push to untrustworthy place without checking
>> what you are pushing", too?
>
> If there is no private data in the repository, then there is no need
> for the user to check what they are pushing. As I've indicated before,
> IMO manually checking eac
On Mon, Nov 14, 2016 at 11:00:04AM -0800, Junio C Hamano wrote:
> Matt McCutchen writes:
>
> >> Yup, and then "do not push to untrustworthy place without checking
> >> what you are pushing", too?
> >
> > If there is no private data in the repository, then there is no need
> > for the user to che
On 11/14/2016 10:56 AM, Junio C Hamano wrote:
Jonathan Tan writes:
to:
HEAD:file
HEAD:sub/file
Signed-off-by: Brandon Williams
---
Unrelated tangent, but this makes readers wonder what the updated
trailer code would do to the last paragraph ;-). Does it behave
sensibly (with some sane def
On 11/14, Jonathan Tan wrote:
> On 11/14/2016 10:56 AM, Junio C Hamano wrote:
> >Jonathan Tan writes:
> >
> to:
> HEAD:file
> HEAD:sub/file
>
> Signed-off-by: Brandon Williams
> ---
> >>>
> >>>Unrelated tangent, but this makes readers wonder what the updated
> >>>trailer
On Mon, 2016-11-14 at 11:00 -0800, Junio C Hamano wrote:
> Matt McCutchen writes:
>
> >
> > >
> > > Yup, and then "do not push to untrustworthy place without
> > > checking
> > > what you are pushing", too?
> >
> > If there is no private data in the repository, then there is no
> > need
> > fo
Matt McCutchen writes:
> The "SECURITY" section of the gitnamespaces(7) man page described two
> ways for a client to steal data from a server that wasn't intended to be
> shared. Similar attacks can be performed by a server on a client, so
> adapt the section to cover both directions and add it
Hello
On Wed, Nov 9, 2016 at 5:44 AM, Jacob Keller wrote:
> On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak wrote:
>> From: Karthik Nayak
>>
>> Port branch.c to use ref-filter APIs for printing. This clears out
>> most of the code used in branch.c for printing and replaces them with
>> calls mad
Hello,
On Wed, Nov 9, 2016 at 5:45 AM, Jacob Keller wrote:
> On Tue, Nov 8, 2016 at 12:11 PM, Karthik Nayak wrote:
>> This is part of unification of the commands 'git tag -l, git branch -l
>> and git for-each-ref'. This ports over branch.c to use ref-filter's
>> printing options.
>>
>> Initially
On Mon, Nov 14, 2016 at 7:25 AM, Junio C Hamano wrote:
> Karthik Nayak writes:
>
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index 600b703..f4ad297 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-r
On Mon, Nov 14, 2016 at 01:24:31PM -0500, Jeff King wrote:
> 2. Have remote-curl understand enough of the protocol that it can
> abort rather than hang.
>
> I think that's effectively the approach of your patch, but for one
> specific case. But could we, for example, make sure th
On 14/11/16 17:01, Jeff King wrote:
> On Mon, Nov 14, 2016 at 05:35:56PM +0100, Torsten Bögershausen wrote:
>
>>> Git 'pu' does not compile on macOS right now:
>>> builtin/bisect--helper.c:299:6: error: variable 'good_syn' is used
>>> uninitialized
>>> whenever 'if' condition is true [-Werror,
Jeff King writes:
> So I think the in-between answer is "it is OK to push to an
> untrustworthy place, but do not do it from a repo that may contain
> secret contents".
Yes, that sounds like a sensible piece of advice to give to the
readers.
Karthik Nayak writes:
>> - More importantly, what do these do? I do not think of a good
>>description that generalizes "base of refs/foo/bar/boz is foo" to
>>explain your :base.
>
> $ ./git for-each-ref --format "%(refname)%(end) %(refname:dir)"
> refs/heads/master refs
On Sun, Nov 13, 2016 at 8:42 AM, Ramsay Jones
wrote:
>
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Stefan,
>
> If you need to re-roll your 'sb/attr' branch, could you please
> squash this into the relevant patch.
will do. I have it applied locally
>
> Alternatively, since there is only a single
Junio C Hamano venit, vidit, dixit 14.11.2016 19:01:
> Michael J Gruber writes:
>
>> *My* idea of --no-index was for it to behave as similar to the
>> --index-version as possible, regarding formatting etc., and to be a good
>> substitute for ordinary diff. The proposed patch achieves exactly that
Hi,
Git always performs a clean/smudge filter on files in sequential order.
Sometimes a filter operation can take a noticeable amount of time.
This blocks the entire Git process.
I would like to give a filter process the possibility to answer Git with
"I got your request, I am processing it, ask
Michael J Gruber writes:
> Junio C Hamano venit, vidit, dixit 14.11.2016 19:01:
>> Michael J Gruber writes:
>>
>>> *My* idea of --no-index was for it to behave as similar to the
>>> --index-version as possible, regarding formatting etc., and to be a good
>>> substitute for ordinary diff. The pr
Jeff King writes:
> So something like this. It turned out to be a lot uglier than I had
> hoped because we get fed the data from curl in odd-sized chunks, so we
> need a state machine.
It is unfortunate that we have to snoop the protocol like this to
infer an error, but I do not think we can do
On Tue, Oct 25, 2016 at 06:46:21PM +0700, Duy Nguyen wrote:
> > So it seems like left-anchoring the refspecs can never be fully correct.
> > We can communicate "master" to the server, who can then look at every
> > ref it would advertise and ask "could this be called master"? But it
> > will be se
On Mon, Nov 14, 2016 at 01:19:49PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > So something like this. It turned out to be a lot uglier than I had
> > hoped because we get fed the data from curl in odd-sized chunks, so we
> > need a state machine.
>
> It is unfortunate that we have t
Hi,
I saw in the recent "What's cooking" mail that this is still waiting
for review, so I thought I could interfere and help reviewing it from a
non-git-developer point of view.
But only two commits for today. The first one seems fine. The second
one makes me write this mail ;-)
On 10/14/2016 04:
On Thu, 2016-11-10 at 16:53 -0500, Matt McCutchen wrote:
> On Wed, 2016-10-26 at 19:07 -0400, Matt McCutchen wrote:
> >
> > Maybe we would never hit any of these problems in practice, but they
> > give me a bad enough feeling that I'm planning to write my own tool
> > that tracks the upstream comm
> -Original Message-
> From: Jeff King [mailto:p...@peff.net]
> Sent: Monday, November 14, 2016 2:41 PM
> To: David Turner
> Cc: git@vger.kernel.org; spea...@spearce.org
> Subject: Re: [PATCH] remote-curl: don't hang when a server dies before any
> output
>
> On Mon, Nov 14, 2016 at 01:24:
On Mon, Nov 14, 2016 at 11:25:30PM +, David Turner wrote:
> > But it does seem to work. At least it doesn't seem to break anything
> > in the test suite, and it fixes the new tests you added. I'd worry
> > that there's some obscure case where the response isn't packetized
> > in the same way.
On Mon, Nov 14, 2016 at 02:40:49PM -0500, Jeff King wrote:
> On Mon, Nov 14, 2016 at 01:24:31PM -0500, Jeff King wrote:
>
> > 2. Have remote-curl understand enough of the protocol that it can
> > abort rather than hang.
> >
> > I think that's effectively the approach of your patch, b
Jeff King writes:
> Actually, I take it back. I think it works for a single round of ref
> negotiation, but not for multiple. Enabling GIT_TEST_LONG=1 causes it to
> fail t5551.
>
> I think I've probably made a mis-assumption on exactly when in the HTTP
> protocol we will see a flush packet (and
Lars Schneider wrote:
> Hi,
>
> Git always performs a clean/smudge filter on files in sequential order.
> Sometimes a filter operation can take a noticeable amount of time.
> This blocks the entire Git process.
I have the same problem in many places which aren't git :>
> I would like to give a
This patch adds a test to illustrate how push run with --dry-run doesn't
actually perform a dry-run when push is configured to push submodules
on-demand. Instead all submodules which need to be pushed are actually
pushed to their remotes while any updates for the superproject are
performed as a dr
While trying to understand how the recursive pushing of submodules worked I
discovered that when push was instructed to do a dry-run, while also configured
to push unpushed submodules 'on-demand', that the submodule pushes weren't
configured to perform dry-runs, but actually performed the pushes.
Teach push to respect the --dry-run option when configured to
recursively push submodules 'on-demand'. This is done by passing the
--dry-run flag to the child process which performs a push for a
submodules when performing a dry-run.
In order to preserve good user experience, the additional check
On Mon, Nov 14, 2016 at 11:23 AM, Karthik Nayak wrote:
> Hello
>
> On Wed, Nov 9, 2016 at 5:44 AM, Jacob Keller wrote:
>> On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak wrote:
>>> From: Karthik Nayak
>>>
>>> Port branch.c to use ref-filter APIs for printing. This clears out
>>> most of the code
On Mon, Nov 14, 2016 at 07:44:26PM -0500, Jeff King wrote:
> > But it does seem to work. At least it doesn't seem to break anything in
> > the test suite, and it fixes the new tests you added. I'd worry that
> > there's some obscure case where the response isn't packetized in the
> > same way.
>
On Mon, Nov 14, 2016 at 05:02:27PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Actually, I take it back. I think it works for a single round of ref
> > negotiation, but not for multiple. Enabling GIT_TEST_LONG=1 causes it to
> > fail t5551.
> >
> > I think I've probably made a mis-ass
Hey Stephan,
On Tue, Nov 15, 2016 at 3:50 AM, Stephan Beyer wrote:
> Hi,
>
> I saw in the recent "What's cooking" mail that this is still waiting
> for review, so I thought I could interfere and help reviewing it from a
> non-git-developer point of view.
> But only two commits for today. The firs
On Tue, Nov 15, 2016 at 1:21 AM, Junio C Hamano wrote:
> Karthik Nayak writes:
>
>>> - More importantly, what do these do? I do not think of a good
>>>description that generalizes "base of refs/foo/bar/boz is foo" to
>>>explain your :base.
>>
>> $ ./git for-each-ref --format "%(refname)
Am 15.11.2016 um 02:18 schrieb Brandon Williams:
diff --git a/t/t5531-deep-submodule-push.sh b/t/t5531-deep-submodule-push.sh
index 198ce84..e6ccc30 100755
--- a/t/t5531-deep-submodule-push.sh
+++ b/t/t5531-deep-submodule-push.sh
@@ -427,7 +427,31 @@ test_expect_success 'push unpushable submodule
On Mon, Nov 14, 2016 at 10:48 PM, Karthik Nayak wrote:
> On Tue, Nov 15, 2016 at 1:21 AM, Junio C Hamano wrote:
>> Karthik Nayak writes:
>>
- More importantly, what do these do? I do not think of a good
description that generalizes "base of refs/foo/bar/boz is foo" to
expl
On Mon, Nov 14, 2016 at 11:55 PM, Jacob Keller wrote:
> On Mon, Nov 14, 2016 at 10:48 PM, Karthik Nayak wrote:
>> On Tue, Nov 15, 2016 at 1:21 AM, Junio C Hamano wrote:
>>> Karthik Nayak writes:
>>>
> - More importantly, what do these do? I do not think of a good
>description that
60 matches
Mail list logo