On Sun, Mar 26, 2017 at 04:01:28PM +, brian m. carlson wrote:
> If we had already processed the last newline in a push certificate, we
> would end up subtracting NULL from the end-of-certificate pointer when
> computing the length of the line. This would have resulted in an
> absurdly large l
On Mon, Mar 27, 2017 at 6:31 PM, Pickfire wrote:
> Johannes Schindelin wrote:
>
>> On Sat, 25 Mar 2017, Ivan Tham wrote:
>>
>> > Johannes Schindelin wrote:
>> > > On Tue, 21 Mar 2017, Ivan Tham wrote:
>> > > > Stefan Beller wrote:
>> > > > > On Mon, Mar 20, 2017 at 9:41 AM, Ivan Tham
>> > > >
Hi,
On Tue, Mar 28, 2017 at 12:17 AM, Devin Lehmacher wrote:
> Hello everyone,
>
> I am a student studying Computer Science at Cornell University. I
> already completed a microproject, Move ~/.git-credential-cache/socket to
> $XDG_CACHE_HOME/credential/socket a week and a half ago or so.
Nice. I
On Sat, Mar 25, 2017 at 11:32:02PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > So hopefully it's clear that the two are functionally equivalent, and
> > differ only in syntax (in this case we manually decided which options
> > are safe to pull from the config, but we'd have to parse the options.log
Replaces recursive traversing of opendir with dir_iterator.
Signed-off-by: Robert Stanca
---
builtin/repack.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/builtin/repack.c b/builtin/repack.c
index 677bc7c..27a5597 100644
--- a/builtin/repack.c
+++ b/builtin
Junio C Hamano wrote:
> Shouldn't this done as part of 4/7 where is_submodule_modified()
> starts reading from the porcelain v2 output? 4/7 does adjust for
> the change from double question mark (porcelain v1) to a single one
> for untracked, but at the same time it needs to prepare for these
> '
Hi,
Romuald Brunet wrote:
> On ven., 2017-03-24 at 12:29 -0700, Junio C Hamano wrote:
>> Jeff King writes:
>>> My one question would be whether people would want this to actually be
>>> specific to a particular remote, and not just on for a given repository
>>> (your "site-specific" in the descr
> -Original Message-
> From: Jonathan Tan [mailto:jonathanta...@google.com]
> Sent: Monday, March 27, 2017 3:00 PM
> To: Ben Peart ; git@vger.kernel.org
> Cc: Ben Peart
> Subject: Re: [PATCH v2 2/2] sub-process: refactor the filter process code into
> a reusable module
>
> On 03/24/2017 0
On Mon, Mar 27, 2017 at 04:32:10PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > Hrm, there shouldn't be any dependency of the config on the index (and
> > there are a handful of options which impact the index already). Did you
> > try it and run into problems?
> >
> > In general, I'd mu
Jeff King wrote:
> Hrm, there shouldn't be any dependency of the config on the index (and
> there are a handful of options which impact the index already). Did you
> try it and run into problems?
>
> In general, I'd much rather see us either:
>
> 1. Rip the code out entirely if it is not meant t
On Mon, Mar 27, 2017 at 09:09:38PM +, g...@jeffhostetler.com wrote:
> From: Jeff Hostetler
>
> Teach git to skip verification of the index SHA in read_index().
>
> This is a performance optimization. The index file SHA verification
> can be considered an ancient relic from the early days o
On Mon, Mar 27, 2017 at 09:09:37PM +, g...@jeffhostetler.com wrote:
> From: Jeff Hostetler
>
> Version 2 of this patch series simplifies this to just
> turn off the hash verification. Independent comments
> from Linus and Peff suggested that we could just turn
> this off and not worry about
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes described
> -Original Message-
> From: Torsten Bögershausen [mailto:tbo...@web.de]
> Sent: Saturday, March 25, 2017 1:47 AM
> To: Ben Peart ; git@vger.kernel.org
> Cc: Ben Peart ; christian.cou...@gmail.com;
> larsxschnei...@gmail.com
> Subject: Re: [PATCH v2 1/2] pkt-line: add packet_writel() and
>
> Junio C Hamano writes:
>
>
> To avoid confusion (although readers may not require), even though I
> explained "boring mechanical part" first and "refactoring", that was purely
> for explanation.
>
> In practice, I would expect that it would be easier to both do and review if
> refactoring is
Hello everyone,
I am a student studying Computer Science at Cornell University. I
already completed a microproject, Move ~/.git-credential-cache/socket to
$XDG_CACHE_HOME/credential/socket a week and a half ago or so.
I am interested in 2 different projects and would like some advice on
them, to
On Mon, Mar 27, 2017 at 11:08:08PM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Jan 6, 2017 at 5:20 AM, Jeff King wrote:
>
> > +for output in porcelain line-porcelain
> > +do
> > + test_expect_success "generate --$output output" '
> > + git blame --root -C --$output combin
Stefan Beller writes:
> When a nested submodule has untracked files, it would be reported as
> "modified submodule" in the superproject, because submodules are not
> parsed correctly in is_submodule_modified as they are bucketed into
> the modified pile as "they are not an untracked file".
I can
From: Jeff Hostetler
Teach git to skip verification of the index SHA in read_index().
This is a performance optimization. The index file SHA verification
can be considered an ancient relic from the early days of git and only
useful for detecting disk corruption. For small repositories, this
SH
From: Jeff Hostetler
Created test to measure read_index() with and without
skip_verify_index set and report performance differences.
Signed-off-by: Jeff Hostetler
---
Makefile | 1 +
t/helper/.gitignore | 1 +
t/helper/test-skip-verify-index.c | 73
From: Jeff Hostetler
Version 2 of this patch series simplifies this to just
turn off the hash verification. Independent comments
from Linus and Peff suggested that we could just turn
this off and not worry about it. So I've updated this
patch to do that. I added a global variable to allow
the
On Fri, Jan 6, 2017 at 5:20 AM, Jeff King wrote:
> +for output in porcelain line-porcelain
> +do
> + test_expect_success "generate --$output output" '
> + git blame --root -C --$output combined >output
> + '
> +
The --root option isn't needed here, the tests pass if it'
Junio C Hamano writes:
> As this thing is about fixing a regression visible to end users, I
> may get around to fixing things up myself, but I have other topics
> to attend to, so...
So I ended up with this version before merging it to 'next'.
I moved 'allow' back on the line it is declared,
On 3/27/2017 4:24 PM, Junio C Hamano wrote:
g...@jeffhostetler.com writes:
+/*
+ * We use n mutexes to guard n partitions of the "istate->dir_hash"
+ * hashtable. Since "find" and "insert" operations will hash to a
+ * particular bucket and modify/search a single chain, we can say
+ * that "
Michael J Gruber writes:
> v2 computes the width for the localized output dynamically.
> In fact, it might overcalculated a bit depending on the encoding,
> but this does not do any harm.
Thanks.
As you said, if we wanted to actually _align_, then it needs much
more work. But that is not what
Luke Diamand writes:
> Yes. The test passes with your change.
>>
>> IOW, can we have a follow up to this patch that fixes a known
>> breakage the patch documents ;-)?
>
> Yes.
Thanks.
Jean-Noël AVILA writes:
>> ... Doesn't that workflow apply equally well for the
>> documentation l10n?
>
> Theoretically, this workflow should apply to the documentation, so that a
> version of the documentation can be cut at each release of git. I still have
> to convince po4a not to update t
g...@jeffhostetler.com writes:
> +/*
> + * We use n mutexes to guard n partitions of the "istate->dir_hash"
> + * hashtable. Since "find" and "insert" operations will hash to a
> + * particular bucket and modify/search a single chain, we can say
> + * that "all chains mod n" are guarded by the sa
Le dimanche 26 mars 2017, 15:56:55 CEST Junio C Hamano a écrit :
> Jean-Noël AVILA writes:
> > ... So I would
> > think the other way around: for those interested in translated the
> > documentation, some script would allow to checkout the git project inside
> > the gitman-l10n project (like a kin
Dear Git users,
It is my pleasure to announce that Git for Windows 2.12.2 is available from:
https://git-for-windows.github.io/
Changes since Git for Windows v2.12.1 (March 21st 2017)
New Features
* Comes with Git v2.12.2.
* An earlier iteration of the changes speeding up the
c
On 03/24/2017 08:27 AM, Ben Peart wrote:
Refactor the filter..process code into a separate sub-process
module that can be used to reduce the cost of starting up a sub-process
for multiple commands. It does this by keeping the external process
running and processing all commands by communicating
Zenobiusz Kunegunda writes:
> Od: "Junio C Hamano"
> Do: "René Scharfe" ;
> Wysłane: 2:40 Poniedziałek 2017-03-27
> Temat: Re: [PATCH] strbuf: support long paths w/o read rights in
> strbuf_getcwd() on FreeBSD
>
>>
>> Nicely analysed and fixed (or is the right word "worked around"?)
>>
>> Tha
On Mon, Mar 27, 2017 at 7:45 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> Before this change:
>>
>> |+-+--+-|
>> | What? | CI? | CIP? | AG? |
>> |+-+--+-|
>> | sha1 | Y | -| N |
Ævar Arnfjörð Bjarmason writes:
> Before this change:
>
> |+-+--+-|
> | What? | CI? | CIP? | AG? |
> |+-+--+-|
> | sha1 | Y | -| N |
> | describeOutput | N | N| N |
> | refname
Jeff King writes:
> Yeah, I think we can assume it will be possible with SHAttered levels of
> effort. An attacker can use it to create a persistent corruption by
> having somebody fetch from them twice. So not really that interesting an
> attack, but it is something. I still think that ditching
Johannes Schindelin writes:
>> So here is what I came up with as a replacement (this time as a
>> proper patch not a comment on a patch).
>>
>> Dscho, could you see if this fixes your build?
>
> The Continuous Testing is back to normal, thanks.
Thanks for a quick response.
I wished if we can r
Ævar Arnfjörð Bjarmason writes:
> On Fri, Mar 24, 2017 at 6:17 PM, Romuald Brunet wrote:
>> +test_expect_success 'atomic option possible via git-config' '
>> + # prepare the repo
>> + mk_repo_pair &&
>> + (
>> + cd workbench &&
>> + test_commit one &
v2 computes the width for the localized output dynamically.
In fact, it might overcalculated a bit depending on the encoding,
but this does not do any harm.
Michael J Gruber (2):
describe: localize debug output fully
l10n: de: translate describe debug terms
builtin/describe.c | 15 ++
Signed-off-by: Michael J Gruber
---
po/de.po | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/po/de.po b/po/de.po
index e9c86f5488..913db393dc 100644
--- a/po/de.po
+++ b/po/de.po
@@ -7530,7 +7530,19 @@ msgstr "git describe [] [...]"
msgid "git describe [] --dir
git describe --debug localizes all debug messages but not the terms
head, lightweight, annotated that it outputs for the candidates.
Localize them, too.
Signed-off-by: Michael J Gruber
---
builtin/describe.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/bui
Johannes Schindelin wrote:
> On Sat, 25 Mar 2017, Ivan Tham wrote:
>
> > Johannes Schindelin wrote:
> > > On Tue, 21 Mar 2017, Ivan Tham wrote:
> > > > Stefan Beller wrote:
> > > > > On Mon, Mar 20, 2017 at 9:41 AM, Ivan Tham
> > > > > wrote:
> > > > >
> > > > > > I am interested to work on "
Hi Junio,
On Sat, 25 Mar 2017, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Which leads me to wonder if a more robust solution that is in line
> > with the original design of sha1dc/sha1.c code may be to do an
> > unconditional "#undef BIGENDIAN" before the above block, so that no
> > m
Hi Ivan,
On Sat, 25 Mar 2017, Inaw Tham wrote:
> Johannes Schindelin wrote:
> > On Tue, 21 Mar 2017, Ivan Tham wrote:
> > > Stefan Beller wrote:
> > > > On Mon, Mar 20, 2017 at 9:41 AM, Ivan Tham wrote:
> > > >
> > > > > I am interested to work on "Convert interactive rebase to C"
> > > >
> >
Change the revision parsing logic to match @{upstream}, @{u} & @{push}
case-insensitively.
Before this change supplying anything except the lower-case forms
emits an "unknown revision or path not in the working tree"
error. This change makes upper-case & mixed-case versions equivalent
to the lower
On Fri, Mar 24, 2017 at 6:17 PM, Romuald Brunet wrote:
> +test_expect_success 'atomic option possible via git-config' '
> + # prepare the repo
> + mk_repo_pair &&
> + (
> + cd workbench &&
> + test_commit one &&
> + git checkout -b second
On Fri, Mar 24, 2017 at 6:17 PM, Romuald Brunet wrote:
> +push.atomic::
> + If set to true enable `--atomic` option by default. You
> + may override this configuration at time of push by specifying
> + `--no-atomic`.
> +
This should also be mentioned in the --atomic documentati
On ven., 2017-03-24 at 12:29 -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > My one question would be whether people would want this to actually be
> > specific to a particular remote, and not just on for a given repository
> > (your "site-specific" in the description made me think of that
On Mon, Mar 27, 2017 at 4:53 AM, Jeff King wrote:
> On Sun, Mar 26, 2017 at 12:16:53PM +, Ævar Arnfjörð Bjarmason wrote:
>
>> Add @{p} as a shorthand for @{push} for consistency with the @{u}
>> shorthand for @{upstream}.
>>
>> This wasn't added when @{push} was introduced in commit
>> adfe5d0
On Mon, Mar 27, 2017 at 4:58 AM, Jeff King wrote:
> On Sun, Mar 26, 2017 at 05:36:21PM -0700, Junio C Hamano wrote:
>
>> It's not "potential confusion". This closes the door for us to
>> introduce "TREE" as a separate object type in the future.
>>
>> If we agree to make a declaration that all typ
On Sun, Mar 26, 2017 at 10:39:18PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > FWIW, I cannot see us ever adding TREE (or Tree) as a separate type.
> > It's too confusing for no gain. We'd call it "tree2" or something more
> > obvious.
>
> In case it was not clear, I didn't mean to s
On Sun, Mar 26, 2017 at 11:07:02PM -0700, Junio C Hamano wrote:
> > No, I don't think so. We don't trust the trailer hash for anything to do
> > with corruption; we actually inflate the objects and see which ones we
> > got. So the victim will notice immediately that what the attacker sent
> > it
51 matches
Mail list logo
