Am 09.08.2017 um 19:47 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> There could be any characters except NUL and LF between the 4096 zeros
>> and "0$" for the latter to match wrongly, no? So there are 4095
>> opportunities for the misleading pattern in a page, with probabilities
>> like t
On Wed, Aug 09 2017, Johannes Schindelin jotted:
> Hi Peff,
>
> On Wed, 9 Aug 2017, Jeff King wrote:
>
>> This is a resurrection of the thread from April:
>>
>>
>> https://public-inbox.org/git/20170404025438.bgxz5sfmrawqs...@sigill.intra.peff.net/
>
> As before, I would like to point out that
On Wed, Aug 09, 2017 at 03:53:17PM -0700, Stefan Beller wrote:
> >> Right, the reason I stopped pursuing it was that I couldn't find a way
> >> to have it make suggestions for new code without nagging about existing
> >> code. If we were to aggressively reformat to match the tool for existing
> >>
On Wed, Aug 9, 2017 at 3:53 PM, Stefan Beller wrote:
> I would think based on these options, a pre commit hook can be
> written that formats precisely the touched lines of code of each file.
I did not search enough, "clang-tidy-diff.py --fix" should be all that is needed
On Wed, Aug 9, 2017 at 7:03 AM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Wed, Aug 09 2017, Jeff King jotted:
>
>> On Mon, Aug 07, 2017 at 06:25:54PM -0700, Brandon Williams wrote:
>>
>>> I'm sure this sort of thing comes up every so often on the list but back at
>>> git-merge I mentioned how it would
>>
>> I'm sure both of these things will probably happen if we decide to make
>> use of a code-formatter. This RFC is really just trying to ask the
>> question: "Is this something we want to entertain doing?"
>> My response would be 'Yes' but there's many other opinions to consider
>> first :)
Mi
Hi,
On Tue, 8 Aug 2017, Brandon Williams wrote:
> On 08/08, Stefan Beller wrote:
> > On Tue, Aug 8, 2017 at 5:05 AM, Johannes Schindelin
> > wrote:
> > > Hi Brandon,
> > >
> > > On Mon, 7 Aug 2017, Brandon Williams wrote:
> > >
> > >> Add a '.clang-format' file which outlines the git project's c
Hi Martin,
On Tue, 8 Aug 2017, Martin Koegler wrote:
> From: Martin Koegler
>
> It changes the signature of the core object access function
> including any other functions to assure a clean compile if
> sizeof(size_t) != sizeof(unsigned long).
>
> Signed-off-by: Martin Koegler
> ---
Thank yo
Hi,
On Wed, 9 Aug 2017, Junio C Hamano wrote:
> Martin Koegler writes:
>
> > On Wed, Aug 09, 2017 at 09:19:06AM +0200, Martin Koegler wrote:
> >> On Tue, Aug 08, 2017 at 11:04:20PM -0700, Junio C Hamano wrote:
> >> > As https://travis-ci.org/git/git/jobs/262463159 shows, unfortunately
> >> > it
Hi all,
On Wed, 9 Aug 2017, David Coppa wrote:
> On Wed, Aug 9, 2017 at 4:15 PM, René Scharfe wrote:
> > Am 09.08.2017 um 08:15 schrieb René Scharfe:
> >> Am 09.08.2017 um 07:29 schrieb Junio C Hamano:
> >>> René Scharfe writes:
> >>>
> Am 09.08.2017 um 00:26 schrieb Junio C Hamano:
>
On Wed, Aug 09, 2017 at 11:29:30PM +0200, Nicolas Morey-Chaisemartin wrote:
> > But the #ifdef above says 071700, which is 7.23.0. I wonder if we just
> > got it wrong back then (maybe hex confusion with 7.17.0?). I have a
> > build setup for old versions of curl, so I'll double-check that 7.19.4
On Wed, Aug 09, 2017 at 11:42:12PM +0200, Johannes Schindelin wrote:
> > This is a resurrection of the thread from April:
> >
> >
> > https://public-inbox.org/git/20170404025438.bgxz5sfmrawqs...@sigill.intra.peff.net/
>
> As before, I would like to point out that people running with older cUR
Hi Peff,
On Wed, 9 Aug 2017, Jeff King wrote:
> This is a resurrection of the thread from April:
>
>
> https://public-inbox.org/git/20170404025438.bgxz5sfmrawqs...@sigill.intra.peff.net/
As before, I would like to point out that people running with older cURL
are most likely not at liberty t
Hi,
On Wed, 9 Aug 2017, Stefan Beller wrote:
> v1.2.0~121 (New tutorial, 2006-01-22) rewrote the tutorial such that the
> original intent of 2ae6c70674 (Adapt tutorial to cygwin and add test case,
> 2005-10-13) to test the examples from the tutorial doesn't hold any more.
>
> There are dedicated
Le 09/08/2017 à 23:17, Jeff King a écrit :
> On Wed, Aug 09, 2017 at 08:03:05PM +0200, Nicolas Morey-Chaisemartin wrote:
>
-#if LIBCURL_VERSION_NUM >= 0x071700
-/* Use CURLOPT_KEYPASSWD as is */
-#elif LIBCURL_VERSION_NUM >= 0x070903
-#define CURLOPT_KEYPASSWD CURLOPT_SSLKEYPA
v1.2.0~121 (New tutorial, 2006-01-22) rewrote the tutorial such that the
original intent of 2ae6c70674 (Adapt tutorial to cygwin and add test case,
2005-10-13) to test the examples from the tutorial doesn't hold any more.
There are dedicated tests for the commands used, even "git whatchanged",
suc
On Wed, Aug 09, 2017 at 10:34:09AM -0700, Stefan Beller wrote:
> On Wed, Aug 9, 2017 at 5:02 AM, Jeff King wrote:
> > Since v2.12.0, Git does not compile with versions of curl
> > older than 7.19.4. That version of curl is about 8 years
> > old. This means it may still be used in some distributio
On Wed, Aug 09, 2017 at 08:03:05PM +0200, Nicolas Morey-Chaisemartin wrote:
> >> -#if LIBCURL_VERSION_NUM >= 0x071700
> >> -/* Use CURLOPT_KEYPASSWD as is */
> >> -#elif LIBCURL_VERSION_NUM >= 0x070903
> >> -#define CURLOPT_KEYPASSWD CURLOPT_SSLKEYPASSWD
> >> -#else
> >> -#define CURLOPT_KEYPASSWD
On Wed, Aug 09, 2017 at 10:40:13AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > -#if LIBCURL_VERSION_NUM >= 0x071700
> > -/* Use CURLOPT_KEYPASSWD as is */
> > -#elif LIBCURL_VERSION_NUM >= 0x070903
> > -#define CURLOPT_KEYPASSWD CURLOPT_SSLKEYPASSWD
> > -#else
> > -#define CURLOPT_KEY
On Wed, Aug 09, 2017 at 10:29:04AM -0700, Stefan Beller wrote:
> > Documentation/config.txt | 3 +--
> > http-push.c | 23
> > http-walker.c| 12 ---
> > http.c | 56
> > +---
> >
On Wed, Aug 09, 2017 at 11:12:19AM -0700, Junio C Hamano wrote:
> Thanks for reducing the count of binary search functions by one.
>
> I think the "just one round of newton-raphson" in sha1_pos() comes
> from [*1*]; I agree that it needs benchmarking before tweaking it.
Actually, it's weirder th
On Wed, Aug 09, 2017 at 08:02:33PM +0100, Ian Campbell wrote:
> > > Should we instead make git-mktag more lenient (possibly with a
> > > command-line option to reduce accidental omissions)?
> >
> > That sounds sensible. Thanks for injecting a dose of sanity.
>
> Indeed. I'll add a --allow-missin
Ian Campbell writes:
> Indeed. I'll add a --allow-missing-tagger option (suggestions for a
> snappier name accepted!) and pass it unconditionally from the filter-
> branch script.
Thanks. That's much better.
On Wed, 2017-08-09 at 08:50 -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Tue, Aug 08, 2017 at 09:06:20AM +0100, Ian Campbell wrote:
> >
> >> Such as v2.6.12-rc2..v2.6.13-rc3 in the Linux kernel source tree.
> >>
> >> Insert a fake tag header, since newer `git mktag` wont accept the
On Wed, 9 Aug 2017 08:24:40 -0400
Jeff King wrote:
> diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-trailers.sh
> index e5b0718ef6..525fd53e5b 100755
> --- a/t/t7513-interpret-trailers.sh
> +++ b/t/t7513-interpret-trailers.sh
> @@ -1312,4 +1312,19 @@ test_expect_success 'only-trai
On Wed, 9 Aug 2017 08:24:03 -0400
Jeff King wrote:
> diff --git a/trailer.c b/trailer.c
> index 0a0c2c264d..a4ff99f98a 100644
> --- a/trailer.c
> +++ b/trailer.c
> @@ -164,13 +164,15 @@ static void print_tok_val(FILE *outfile, const char
> *tok, const char *val)
> fprintf(outfile,
On Wed, Aug 9, 2017 at 5:26 AM, Jeff King wrote:
> The last few commits have added command line options that
> can turn interpret-trailers into a parsing tool. Since
> they'd most often be used together, let's provide a
> convenient single option for callers to invoke this mode.
>
> This is implem
On Wed, Aug 9, 2017 at 5:24 AM, Jeff King wrote:
> It can be useful to invoke interpret-trailers for the
> primary purpose of parsing existing trailers. But in that
> case, we don't want to apply existing ifMissing or ifExists
> rules from the config. Let's add a special mode where we
> avoid appl
Jeff King writes:
> This lets us remove sha1_entry_pos() entirely, as the .idx
> lookup code was the only caller. Note that sha1-lookup.c
> still contains sha1_pos(), which differs from
> sha1_entry_pos() in two ways:
>
> - it has a different interface; it uses a function pointer
> to acce
Dear Git gurus,
More context (may be different issue(s)) could be found at
http://git-annex.branchable.com/forum/git-annex_add_out_of_memory_error/
but currently I am consistently reproducing it while running
git (1:2.11.0-3 debian stretch build) within debian stretch singularity
environment [1]
Le 09/08/2017 à 19:40, Junio C Hamano a écrit :
> Jeff King writes:
>
>> -#if LIBCURL_VERSION_NUM >= 0x071700
>> -/* Use CURLOPT_KEYPASSWD as is */
>> -#elif LIBCURL_VERSION_NUM >= 0x070903
>> -#define CURLOPT_KEYPASSWD CURLOPT_SSLKEYPASSWD
>> -#else
>> -#define CURLOPT_KEYPASSWD CURLOPT_SSLCERT
On Wed, Aug 9, 2017 at 10:52 AM, Stefan Beller wrote:
> On Wed, Aug 9, 2017 at 5:24 AM, Jeff King wrote:
>> In theory it's easy for any reader who wants to parse
>> trailers to do so. But there are a lot of subtle corner
>> cases around what counts as a trailer, when the trailer
>> block begins a
On Wed, Aug 9, 2017 at 5:24 AM, Jeff King wrote:
> In theory it's easy for any reader who wants to parse
> trailers to do so. But there are a lot of subtle corner
> cases around what counts as a trailer, when the trailer
> block begins and ends, etc. Since interpret-trailers already
> has our pars
René Scharfe writes:
> There could be any characters except NUL and LF between the 4096 zeros
> and "0$" for the latter to match wrongly, no? So there are 4095
> opportunities for the misleading pattern in a page, with probabilities
> like this:
>
> 0$ 1/256 * 2/256
>
Jeff King writes:
> -#if LIBCURL_VERSION_NUM >= 0x071700
> -/* Use CURLOPT_KEYPASSWD as is */
> -#elif LIBCURL_VERSION_NUM >= 0x070903
> -#define CURLOPT_KEYPASSWD CURLOPT_SSLKEYPASSWD
> -#else
> -#define CURLOPT_KEYPASSWD CURLOPT_SSLCERTPASSWD
> -#endif
> -
This part I am not sure. Don't we st
On Wed, Aug 9, 2017 at 5:02 AM, Jeff King wrote:
> We already fail to build with versions of curl older than
> 7.19.4. But doing an explicit check with an #error has two
> benefits.
>
> One is that it makes it clear to users that the build
> failure is intentional, so they don't waste time trying
On Wed, Aug 9, 2017 at 5:02 AM, Jeff King wrote:
> Since v2.12.0, Git does not compile with versions of curl
> older than 7.19.4. That version of curl is about 8 years
> old. This means it may still be used in some distributions
> with long-running support periods. But the fact that we
> haven't r
On Wed, Aug 9, 2017 at 5:01 AM, Jeff King wrote:
> As discussed in the previous commit, Git is not well-tested
> with old versions of curl (and in fact since v2.12.0 does
> not even compile with versions older than 7.19.4). Let's
> stop pretending we support curl that old and drop any
> now-obslet
On Wed, 9 Aug 2017 14:00:40 +0200
Christian Couder wrote:
> On Tue, Aug 8, 2017 at 10:50 PM, Jonathan Tan
> wrote:
> > On Tue, 8 Aug 2017 13:36:24 -0700
> > Stefan Beller wrote:
> >>
> >> There are also packed refs, so one could (like I did) think that
> >> pack.c is for generic packing of thi
Am 09.08.2017 um 18:07 schrieb Junio C Hamano:
> René Scharfe writes:
>
>>> In the face of unreliable segfaults we need to reverse our strategy,
>>> I think. Searching for something not in the buffer (e.g. "1") and
>>> considering matches and segfaults as confirmation that the bug is
>>> still p
Jeff King writes:
> Parsing trailers out of a commit message is _mostly_ easy, but there
> area a lot of funny corner cases (e.g., heuristics for how many
> non-trailers must be present before a final paragraph isn't a trailer
> block anymore). The code in trailer.c already knows about these cor
Martin Koegler writes:
> On Wed, Aug 09, 2017 at 09:19:06AM +0200, Martin Koegler wrote:
>> On Tue, Aug 08, 2017 at 11:04:20PM -0700, Junio C Hamano wrote:
>> > As https://travis-ci.org/git/git/jobs/262463159 shows, unfortunately
>> > it turns out that things are not so simple X-<. On Linux32, s
René Scharfe writes:
>> In the face of unreliable segfaults we need to reverse our strategy,
>> I think. Searching for something not in the buffer (e.g. "1") and
>> considering matches and segfaults as confirmation that the bug is
>> still present should avoid any false positives. Right?
>
> An
Use a NULL-and-NUL check to see if we have a prefix and consistently use
C string functions on it instead of storing its length in a member of
struct apply_state. This avoids strlen() calls and simplifies the code.
Signed-off-by: Rene Scharfe
---
apply.c | 12 +---
apply.h | 1 -
2 fil
Jeff King writes:
> On Tue, Aug 08, 2017 at 09:06:20AM +0100, Ian Campbell wrote:
>
>> Such as v2.6.12-rc2..v2.6.13-rc3 in the Linux kernel source tree.
>>
>> Insert a fake tag header, since newer `git mktag` wont accept the input
>> otherwise:
>
> Hmm. Now your resulting tag will have this cruf
On Wed, Aug 09, 2017 at 04:55:43PM +0200, René Scharfe wrote:
> > I also wondered if using memcmp() could be a hint to the compiler to use
> > an intrinsic or some other trick, especially because the "len" here is a
> > constant. But in a toy function compiled with "gcc -S", it looks like we
> > d
Am 09.08.2017 um 12:16 schrieb Jeff King:
> In 1a812f3a70 (hashcmp(): inline memcmp() by hand to
> optimize, 2011-04-28), it was reported that an open-coded
> loop outperformed memcmp() for comparing sha1s.
>
> Discussion[1] a few years later in 2013 showed that this
> depends on your libc's versi
>From 7.21.5, curl can be tricked into using an open fd.
This series uses this to allow using curl over a tunnel.
I have a few doubt on patch #2:
- is socketpair working on all git supported system (windows ?)
- should socketpair always be used or limited to the curl over tunnel case ?
I don't t
Signed-off-by: Nicolas Morey-Chaisemartin
---
imap-send.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 10f668eb7..e5ff70096 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -929,18 +929,27 @@ static int auth_cram_md5(struct im
Starting from libcurl 7.21.5, libcurl can be tricked into using
an already open socket.
This allows to use tunneling with libcurl instead of the legacy imap code.
Signed-off-by: Nicolas Morey-Chaisemartin
---
Documentation/git-imap-send.txt | 4 ++--
imap-send.c | 45 +++
Signed-off-by: Nicolas Morey-Chaisemartin
---
imap-send.c | 37 ++---
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index b2d0b849b..10f668eb7 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -926,6 +926,27 @@ static int aut
On Wed, Aug 9, 2017 at 4:15 PM, René Scharfe wrote:
> Am 09.08.2017 um 08:15 schrieb René Scharfe:
>> Am 09.08.2017 um 07:29 schrieb Junio C Hamano:
>>> René Scharfe writes:
>>>
Am 09.08.2017 um 00:26 schrieb Junio C Hamano:
> ... but in the meantime, I think replacing the test with "0$"
Am 09.08.2017 um 08:15 schrieb René Scharfe:
> Am 09.08.2017 um 07:29 schrieb Junio C Hamano:
>> René Scharfe writes:
>>
>>> Am 09.08.2017 um 00:26 schrieb Junio C Hamano:
... but in the meantime, I think replacing the test with "0$" to
force the scanner to find either the end of line or
I Have A Donation For You
On Wed, Aug 09 2017, Jeff King jotted:
> On Mon, Aug 07, 2017 at 06:25:54PM -0700, Brandon Williams wrote:
>
>> I'm sure this sort of thing comes up every so often on the list but back at
>> git-merge I mentioned how it would be nice to not have to worry about style
>> when reviewing patches as t
As the LIBCURL_VERSION_NUM check at the top of http.h shows we require
curl >= 7.19.4. This means we can remove previously added ifdef's
needed to support older curl versions.
The CURLAUTH_DIGEST_IE macro conditionally used since [1] was added in
7.19.3 (see CURLOPT_HTTPAUTH(3)).
The CURLOPT_USE_
On Wed, Aug 09, 2017 at 03:14:22PM +0200, Ævar Arnfjörð Bjarmason wrote:
> This whole series looks good to me. As I commented on in the thread you
> referenced in 0/4 I think this is the right trade-off, and people like
> me who occasionally compile git on older systems can just easily package
> a
On Wed, Aug 09 2017, Jeff King jotted:
> Since v2.12.0, Git does not compile with versions of curl
> older than 7.19.4. That version of curl is about 8 years
> old. This means it may still be used in some distributions
> with long-running support periods. But the fact that we
> haven't received a
On Mon, Aug 07, 2017 at 06:25:54PM -0700, Brandon Williams wrote:
> I'm sure this sort of thing comes up every so often on the list but back at
> git-merge I mentioned how it would be nice to not have to worry about style
> when reviewing patches as that is something mechanical and best left to a
The last few commits have added command line options that
can turn interpret-trailers into a parsing tool. Since
they'd most often be used together, let's provide a
convenient single option for callers to invoke this mode.
This is implemented as a callback rather than a boolean so
that its effect
How are you today and your family, You did not acknowledge my last mail?
Best Regards
Mr. LIN
__
Sky Silk, http://aknet.kz
The point of "--only-trailers" is to give a caller an output
that's easy for them to parse. Getting rid of the
non-trailer material helps, but we still may see more
complicated syntax like whitespace continuation. Let's add
an option to normalize the output into one "key: value" line
per trailer.
It can be useful to invoke interpret-trailers for the
primary purpose of parsing existing trailers. But in that
case, we don't want to apply existing ifMissing or ifExists
rules from the config. Let's add a special mode where we
avoid applying those rules. Coupled with --only-trailers,
this gives u
In theory it's easy for any reader who wants to parse
trailers to do so. But there are a lot of subtle corner
cases around what counts as a trailer, when the trailer
block begins and ends, etc. Since interpret-trailers already
has our parsing logic, let's let callers ask it to just
output the trail
We already have two options and are about to add a few more.
To avoid having a huge number of boolean arguments, let's
convert to an options struct which can be passed in.
Signed-off-by: Jeff King
---
builtin/interpret-trailers.c | 13 ++---
trailer.c| 9 +
t
Parsing trailers out of a commit message is _mostly_ easy, but there
area a lot of funny corner cases (e.g., heuristics for how many
non-trailers must be present before a final paragraph isn't a trailer
block anymore). The code in trailer.c already knows about these corner
cases, but there's no wa
On Tue, Aug 08, 2017 at 09:54:53AM -0700, Junio C Hamano wrote:
> > For comparison, nothing older than curl 7.19.4 will work for building
> > Git since v2.12.0, as we added some unconditional uses of CURLPROTO_*
> > there. Nobody seems to have noticed or complained. I pointed this out a
> > few mo
Since v2.12.0, Git does not compile with versions of curl
older than 7.19.4. That version of curl is about 8 years
old. This means it may still be used in some distributions
with long-running support periods. But the fact that we
haven't received a single bug report about the compile-time
breakage
We already fail to build with versions of curl older than
7.19.4. But doing an explicit check with an #error has two
benefits.
One is that it makes it clear to users that the build
failure is intentional, so they don't waste time trying to
debug it.
And two is that it documents our current "too o
As discussed in the previous commit, Git is not well-tested
with old versions of curl (and in fact since v2.12.0 does
not even compile with versions older than 7.19.4). Let's
stop pretending we support curl that old and drop any
now-obslete #ifdefs.
Choosing 7.16.0 is a somewhat arbitrary cutoff,
Recent versions of Git will not build with curl older than
7.11.1 due to (at least) two issues:
- our use of CURLOPT_POSTFIELDSIZE in 37ee680d9b
(http.postbuffer: allow full range of ssize_t values,
2017-04-11). This field was introduced in curl 7.11.1.
- our use of CURLPROTO_* outsid
On Tue, Aug 8, 2017 at 10:50 PM, Jonathan Tan wrote:
> On Tue, 8 Aug 2017 13:36:24 -0700
> Stefan Beller wrote:
>>
>> There are also packed refs, so one could (like I did) think that
>> pack.c is for generic packing of things, maybe packfile.c
>> would be more clear?
>
> Good point. I'll use pack
This is a resurrection of the thread from April:
https://public-inbox.org/git/20170404025438.bgxz5sfmrawqs...@sigill.intra.peff.net/
The general idea is that we should drop support for very old curl
versions, which already fail to compile. I'm sympathetic to the case
where people actually have
Shawn Pearce wrote:
On Sun, Aug 6, 2017 at 4:37 PM, Ben Alex wrote:
> Just on the LmdbJava specific pieces:
>
> On Mon, Aug 7, 2017 at 8:56 AM, Shawn Pearce wrote:
I don't know if we need a larger key size. $DAY_JOB limits ref names
to ~200 bytes in a hook. I think GitHub does similar. But
I just made a Donation of 1.7Million Euros to you,reply back for details
On Tue, Aug 08, 2017 at 09:06:20AM +0100, Ian Campbell wrote:
> Such as v2.6.12-rc2..v2.6.13-rc3 in the Linux kernel source tree.
>
> Insert a fake tag header, since newer `git mktag` wont accept the input
> otherwise:
Hmm. Now your resulting tag will have this crufty "unkn...@example.com"
heade
In 1a812f3a70 (hashcmp(): inline memcmp() by hand to
optimize, 2011-04-28), it was reported that an open-coded
loop outperformed memcmp() for comparing sha1s.
Discussion[1] a few years later in 2013 showed that this
depends on your libc's version of memcmp(). In particular,
glibc 2.13 optimized th
Long ago in 628522ec14 (sha1-lookup: more memory efficient
search in sorted list of SHA-1, 2007-12-29) we added
sha1_entry_pos(), a binary search that uses the uniform
distribution of sha1s to scale the selection of mid-points.
As this was a performance experiment, we tied it to the
GIT_USE_LOOKUP
On Wed, Aug 09, 2017 at 05:20:05AM -0400, Jeff King wrote:
> > I still wonder if we want to retire that conditional invocation of
> > sha1_entry_pos(), though.
>
> I think so. Digging in the list for it, almost every mention is either
> somebody asking "should we scrap this?" or somebody showing
On Tue, Aug 08, 2017 at 06:25:24PM +0100, Adam Dinwoodie wrote:
> I'm running a bisect overnight to try to isolate the commit on the left
> merge parent that seems to be interacting badly with the commit on the
> right, and will send in the results from that when I have them.
For the sake of inter
On Tue, Aug 08, 2017 at 10:36:33PM -0700, Junio C Hamano wrote:
> > Actually, I take it back. The problem happens when we enter the loop
> > with no entries to look at. But both sha1_pos() and sha1_entry_pos()
> > return early before hitting their do-while loops in that case.
>
> Ah, I was not lo
Greetings from Dr. mohammad ouattara.
Assalamu`Alaikum.
My Name is Dr. mohammad ouattara, I am a banker by profession. I'm
from Ouagadougou, Burkina Faso, West Africa. My reason for contacting
you is to transfer an abandoned $14.6M to your account.
The owner of this fund died since 2004 with his
On Tue, 2017-08-08 at 13:56 -0700, Junio C Hamano wrote:
> Ian Campbell writes:
>
> > Allowing for incremental updates of large trees.
>
> "by doing what" is missing. And ...
>
> >
> > I have been using this as part of the device tree extraction from
> the Linux
> > kernel source since 2013, a
On Tue, 2017-08-08 at 14:00 -0700, Junio C Hamano wrote:
> > @@ -540,6 +540,9 @@ if [ "$filter_tag_name" ]; then
> > > new_sha1=$( ( printf 'object %s\ntype commit\ntag %s\n'
> > >\
> > > "$new_sha1" "$new_ref"
> > >
On Wed, Aug 09, 2017 at 09:19:06AM +0200, Martin Koegler wrote:
> On Tue, Aug 08, 2017 at 11:04:20PM -0700, Junio C Hamano wrote:
> > As https://travis-ci.org/git/git/jobs/262463159 shows, unfortunately
> > it turns out that things are not so simple X-<. On Linux32, size_t
> > is uint, which is th
On Tue, Aug 08, 2017 at 11:04:20PM -0700, Junio C Hamano wrote:
> Martin Koegler writes:
>
> > From: Martin Koegler
> >
> > It changes the signature of the core object access function
> > including any other functions to assure a clean compile if
> > sizeof(size_t) != sizeof(unsigned long).
>
>
Junio C Hamano writes:
>>> > +# Insert a space after a cast
>>> > +# x = (int32) y;notx = (int32)y;
>>> > +SpaceAfterCStyleCast: true
>>>
>>> Hmph, I thought we did the latter, i.e. cast sticks to the casted
>>> expression without SP.
>>
>> I've seen both and I wasn't sure which was the
87 matches
Mail list logo
