Jonathan Nieder writes:
> In other words, a long lifetime for the hash absolutely is a design
> goal. Coping well with an unexpectedly short lifetime for the hash is
> also a design goal.
>
> If the hash function lasts 10 years then I am happy.
Absolutely. When two functions have similar expec
Jonathan Nieder writes:
> The NewHash-based signature is included in the SHA-1 content as well,
> for the sake of round-tripping. It is not stripped out.
Ah, OK, that allays my worries. We rely on the fact that unknown
object headers from the future are ignored. We use something other
than "g
On 13/09/17 23:43, Ramsay Jones wrote:
>
>
> On 13/09/17 19:58, Jeff King wrote:
>> On Wed, Sep 13, 2017 at 11:24:31AM -0700, Jonathan Nieder wrote:
>>
>>> For what it's worth,
>>> Reviewed-by: Jonathan Nieder
>>
>> Thanks, and thank you for questioning the ptrdiff_t bits that didn't
>> make s
On Wed, Sep 13, 2017 at 6:43 AM, demerphq wrote:
>
> SHA3 however uses a completely different design where it mixes a 1088
> bit block into a 1600 bit state, for a leverage of 2:3, and the excess
> is *preserved between each block*.
Yes. And considering that the SHA1 attack was actually predicate
Dear Friend
I write to seek if I can have your professional assistance in this important
matter which I bring to you. Hence I believe you have the right experience
needed to accomplish this.
There are fund available and ready for investment which we will need your
assistance to proceed. Please
On Wed, Sep 13, 2017 at 10:16 AM, Michael Haggerty wrote:
> We've made huge changes to this file, and some of the old names and
> comments are no longer very fitting. So rename a bunch of things:
>
> * `struct packed_ref_cache` → `struct snapshot`
> * `acquire_packed_ref_cache()` → `acquire_snapsh
Hi,
Yves wrote:
> On 13 September 2017 at 14:05, Johannes Schindelin
>> For example, I am still in favor of SHA-256 over SHA3-256, after learning
>> some background details from in-house cryptographers: it provides
>> essentially the same level of security, according to my sources, while
>> hardw
On 13/09/17 19:58, Jeff King wrote:
> On Wed, Sep 13, 2017 at 11:24:31AM -0700, Jonathan Nieder wrote:
>
>> For what it's worth,
>> Reviewed-by: Jonathan Nieder
>
> Thanks, and thank you for questioning the ptrdiff_t bits that didn't
> make sense. I _thought_ they felt like nonsense, but could
On Wed, Sep 13, 2017 at 2:54 PM, Brandon Williams wrote:
> A normal request to git-daemon is structured as
> "command path/to/repo\0host=..\0" and due to a bug in an old version of
> git-daemon 73bb33a94 (daemon: Strictly parse the "extra arg" part of the
> command, 2009-06-04) we aren't able to p
Junio C Hamano wrote:
> In the proposed transition plan, the treatment of various signatures
> (deliberately) makes the conversion not quite roundtrip.
That's not precisely true. Details below.
> When existing SHA-1 history in individual clones are converted to
> NewHash, we obviously cannot re
On Wed, Sep 13, 2017 at 2:54 PM, Brandon Williams wrote:
> Create protocol.{c,h} and provide functions which future servers and
> clients can use to determine which protocol to use or is being used.
>
> Also introduce the 'GIT_PROTOCOL' environment variable which will be
> used to communicate a co
Hi,
Stefan Beller wrote:
> On Wed, Sep 13, 2017 at 2:52 PM, Junio C Hamano wrote:
>> This is a tangent, but it may be fine for a shallow clone to treat
>> the cut-off points in the history as if they are root commits and
>> compute generation numbers locally, just like everybody else does.
[...]
Jacob Keller writes:
> By definition if you do a sparse checkout, you're telling git "I only
> care about the files in this sparse checkout, and do not concern me
> with anything else"... So the proposed fix is "since git cleared the
> skip-worktree flag, we should actually also copy the file out
Junio C Hamano writes:
> Jonathan Nieder writes:
>
>> Treating generation numbers as derived data (as in Jeff King's
>> preferred design, if I have understood his replies correctly) would
>> also be possible but it does not interact well with shallow clone or
>> narrow clone.
>
> Just like we ha
On Wed, Sep 13, 2017 at 2:52 PM, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
>> Treating generation numbers as derived data (as in Jeff King's
>> preferred design, if I have understood his replies correctly) would
>> also be possible but it does not interact well with shallow clone or
>> na
Signed-off-by: Brandon Williams
---
t/interop/i5700-protocol-transition.sh | 68 ++
1 file changed, 68 insertions(+)
create mode 100755 t/interop/i5700-protocol-transition.sh
diff --git a/t/interop/i5700-protocol-transition.sh
b/t/interop/i5700-protocol-transiti
Tell a server that protocol v1 can be used by sending the http header
'Git-Protocol' indicating this.
Also teach the apache http server to pass through the 'Git-Protocol'
header as an environment variable 'GIT_PROTOCOL'.
Signed-off-by: Brandon Williams
---
cache.h | 2 ++
http.
Teach the connection logic to tell a serve that it understands protocol
v1. This is done in 2 different ways for the built in protocols.
1. git://
A normal request is structured as "command path/to/repo\0host=..\0"
and due to a bug in an old version of git-daemon 73bb33a94 (daemon:
Stric
Add a function which can be used to write the contents of an arbitrary
buffer. This makes it easy to build up data in a buffer before writing
the packet instead of formatting the entire contents of the packet using
'packet_write_fmt()'.
Signed-off-by: Brandon Williams
---
pkt-line.c | 6 ++
Teach upload-pack and receive-pack to understand and respond using
protocol version 1, if requested.
Protocol version 1 is simply the original and current protocol (what I'm
calling version 0) with the addition of a single packet line, which
precedes the ref advertisement, indicating the protocol
Here is the non-RFC version of of my proposed protocol transition plan which
can be found here:
https://public-inbox.org/git/20170824225328.8174-1-bmw...@google.com/
The main take away from the comments on the RFC were that the first transition
shouldn't be drastic, so this patch set introduces pr
Teach a client to recognize that a server understands protocol v1 by
looking at the first pkt-line the server sends in response. This is
done by looking for the response "version 1" send by upload-pack or
receive-pack.
Signed-off-by: Brandon Williams
---
connect.c | 22 ++
1
A normal request to git-daemon is structured as
"command path/to/repo\0host=..\0" and due to a bug in an old version of
git-daemon 73bb33a94 (daemon: Strictly parse the "extra arg" part of the
command, 2009-06-04) we aren't able to place any extra args (separated
by NULs) besides the host.
In orde
Create protocol.{c,h} and provide functions which future servers and
clients can use to determine which protocol to use or is being used.
Also introduce the 'GIT_PROTOCOL' environment variable which will be
used to communicate a colon separated list of keys with optional values
to a server. Unkno
Jonathan Nieder writes:
> Treating generation numbers as derived data (as in Jeff King's
> preferred design, if I have understood his replies correctly) would
> also be possible but it does not interact well with shallow clone or
> narrow clone.
Just like we have skewed committer timestamps, the
Michael Haggerty writes:
> Following lots of work to extract the `packed_ref_store` into a
> separate module and decouple it from the `files_ref_store`, it is now
> possible to fundamentally change how the `packed-refs` file is read.
>
> * `mmap()` the whole file rather than `read()`ing it.
>
> *
Jonathan Nieder writes:
> Jeff King wrote:
>
>> What I missed is that copy_begin and copy_end here are actually size_t
>> variables, not the pointers. Sorry for the confusion, and here's an
>> updated version of the patch with this paragraph amended (the patch
>> itself is identical):
>
> Subtle.
Hi,
Jeff King wrote:
> The store_write_section() and store_write_pairs() functions
> are basically high-level wrappers around write(). But their
> return values are flipped from our usual convention, using
> "1" for success and "0" for failure.
>
> Let's flip them to follow the usual write() conv
Jeff King wrote:
> We store the return value of write_in_full() in a long,
> though the return is actually an ssize_t. This probably
> doesn't matter much in practice (since the buffer size is
> alredy an unsigned long), but it might if the size if
> between what can be represented in "long" and "
Jeff King wrote:
> As with the previous two commits, we prefer to check
> write_in_full()'s return value to see if it is negative,
> rather than comparing it to the input length.
>
> These cases actually flip the logic to check for success,
> making conversion a little different than in other case
Jeff King wrote:
> The prior commit converted many sites to check the return
> value of write_in_full() for negativity, rather than a
> mismatch with the input length. This patch covers similar
> cases, but where the return value is stored in an
> intermediate variable. These should get the same t
Jeff King wrote:
> The return value of write_in_full() is either "-1", or the
> requested number of bytes[1]. If we make a partial write
> before seeing an error, we still return -1, not a partial
> value. This goes back to f6aa66cb95 (write_in_full: really
> write in full or return error on disk
Hi,
Jeff King wrote:
> We ask to write 41 bytes and make sure that the return value
> is at least 41. This is the same "dangerous" pattern that
> was fixed in the prior commit (wherein a negative return
> value is promoted to unsigned), though it is not dangerous
> here because our "41" is a cons
Jeff King wrote:
> AFAIK there's no way to turn it on for specific functions, but I'm far
> from a gcc-warning guru. Even if you could, though, the error may be far
> from the function (e.g., if we store the result in an ssize_t and then
> compare that with a size_t).
It turns out that yes, we ha
Ramsay Jones wrote:
> On cygwin (and MinGW), the 'ulimit' built-in bash command does not have
> the desired effect of limiting the resources of new processes, at least
> for the stack and file descriptors. However, it always returns success
> and leads to several test prerequisites being erroneous
Jeff King wrote:
> On Wed, Sep 13, 2017 at 11:24:31AM -0700, Jonathan Nieder wrote:
>> Compilers' signed/unsigned comparison warning can be noisy, but I'm
>> starting to feel it's worth the suppression noise to turn it on when
>> DEVELOPER=1 anyway. What do you think? Is there a way to turn it o
Jeff King wrote:
> Subject: [PATCH] read_pack_header: handle signed/unsigned comparison in read
> result
>
> The result of read_in_full() may be -1 if we saw an error.
> But in comparing it to a sizeof() result, that "-1" will be
> promoted to size_t. In fact, the largest possible size_t
> which
On cygwin (and MinGW), the 'ulimit' built-in bash command does not have
the desired effect of limiting the resources of new processes, at least
for the stack and file descriptors. However, it always returns success
and leads to several test prerequisites being erroneously set to true.
Add a check
On Wed, Sep 13, 2017 at 11:24:31AM -0700, Jonathan Nieder wrote:
> For what it's worth,
> Reviewed-by: Jonathan Nieder
Thanks, and thank you for questioning the ptrdiff_t bits that didn't
make sense. I _thought_ they felt like nonsense, but couldn't quite
puzzle it out.
> Compilers' signed/unsi
Please I like you to keep this proposal as a top secret and delete it if you
are not interested and get back to
me if you are interested for details as regards to the transfer of $24,500,000
to you. This money initially
belongs to a Libyan client who died in the libya crisis and had no next
On Wed, Sep 13, 2017 at 01:08:07PM -0400, Jeff King wrote:
> Here's the fix, along with some related cleanups. The actual bugfix is
> in the first patch, which I think should go to "maint". The rest are not
> as important, so could go to master (but would also be fine for maint,
> as there should
On Wed, Sep 13, 2017 at 02:02:32PM -0400, Jeff King wrote:
> > Does read_in_full need a similar treatment?
>
> It might actually return fewer than the requested number of bytes, so it
> can't just use "< 0" in the same way (nor be adapted to return 0 on
> success). But I think it's still a bug t
Jeff King wrote:
> What I missed is that copy_begin and copy_end here are actually size_t
> variables, not the pointers. Sorry for the confusion, and here's an
> updated version of the patch with this paragraph amended (the patch
> itself is identical):
Subtle. The world makes more sense now. T
On Wed, Sep 13, 2017 at 01:11:04PM -0400, Jeff King wrote:
> I scoured the code base for cases of this, but it turns out
> that these two in git_config_set_multivar_in_file_gently()
> are the only ones. This case is actually quite interesting:
> we don't have a size_t, but rather use the subtracti
On Wed, Sep 13, 2017 at 10:59:30AM -0700, Jonathan Nieder wrote:
> I can confidentally say the intent in C99 in that passage is to
> describe the type of the expression, not just the type of a variable
> that can hold it.
Doh. The problem is that I'm a moron. The copy_begin and copy_end values
ar
On Wed, Sep 13, 2017 at 10:53:57AM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > We ask to write 41 bytes and make sure that the return value
> > is at least 41. This is the same "dangerous" pattern that
> > was fixed in the prior commit (wherein a negative return
> > value is promoted t
Jeff King wrote:
> On Wed, Sep 13, 2017 at 10:47:28AM -0700, Jonathan Nieder wrote:
>> Jeff King wrote:
>>> I scoured the code base for cases of this, but it turns out
>>> that these two in git_config_set_multivar_in_file_gently()
>>> are the only ones. This case is actually quite interesting:
>>>
Jeff King wrote:
> We ask to write 41 bytes and make sure that the return value
> is at least 41. This is the same "dangerous" pattern that
> was fixed in the prior commit (wherein a negative return
> value is promoted to unsigned), though it is not dangerous
> here because our "41" is a constant,
On Wed, Sep 13, 2017 at 10:47:28AM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > I scoured the code base for cases of this, but it turns out
> > that these two in git_config_set_multivar_in_file_gently()
> > are the only ones. This case is actually quite interesting:
> > we don't have a
Hi,
Jeff King wrote:
> I scoured the code base for cases of this, but it turns out
> that these two in git_config_set_multivar_in_file_gently()
> are the only ones. This case is actually quite interesting:
> we don't have a size_t, but rather use the subtraction of
> two pointers. Which you might
The store_write_section() and store_write_pairs() functions
are basically high-level wrappers around write(). But their
return values are flipped from our usual convention, using
"1" for success and "0" for failure.
Let's flip them to follow the usual write() conventions and
update all callers. As
As with the previous two commits, we prefer to check
write_in_full()'s return value to see if it is negative,
rather than comparing it to the input length.
These cases actually flip the logic to check for success,
making conversion a little different than in other cases. We
could of course write:
We store the return value of write_in_full() in a long,
though the return is actually an ssize_t. This probably
doesn't matter much in practice (since the buffer size is
alredy an unsigned long), but it might if the size if
between what can be represented in "long" and "unsigned
long", and if your
We're about to stop storing packed refs in a `ref_cache`. That means
that the only way we have left to optimize `peel_ref()` is by checking
whether the reference being peeled is the one currently being iterated
over (in `current_ref_iter`), and if so, using `ref_iterator_peel()`.
But this can be do
It doesn't actually matter now, because the references are only
iterated over to fill the associated `ref_cache`, which itself puts
them in the correct order. But we want to get rid of the `ref_cache`,
so we want to be able to iterate directly over the `packed-refs`
buffer, and then the iteration w
Instead of copying data from the `packed-refs` file one line at time
and then processing it, process the data in place as much as possible.
Also, instead of processing one line per iteration of the main loop,
process a reference line plus its corresponding peeled line (if
present) together.
Note
Extract some helper functions for reporting errors. While we're at it,
prevent them from spewing unlimited output to the terminal. These
functions will soon have more callers.
These functions accept the problematic line as a `(ptr, len)` pair
rather than a NUL-terminated string, and `die_invalid_l
Add a new `mmapped_ref_iterator`, which can iterate over the
references in an mmapped `packed-refs` file directly. Use this
iterator from `read_packed_refs()` to fill the packed refs cache.
Note that we are not yet willing to promise that the new iterator
generates its output in order. That doesn'
Instead of reading the reference from the `ref_cache`, read it
directly from the mmapped buffer.
Signed-off-by: Michael Haggerty
---
refs/packed-backend.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/refs/packed-backend.c b/refs/packed-backend.c
index a018a6
Now that the `packed-refs` backend doesn't use `ref_cache`, there is
nobody left who might want to store peeled values of references in
`ref_cache`. So remove that feature.
Signed-off-by: Michael Haggerty
---
refs/packed-backend.c | 9 -
refs/ref-cache.c | 42 +-
Since `packed_ref_iterator` is now delegating to
`mmapped_ref_iterator` rather than `cache_ref_iterator` to do the
heavy lifting, there is no need to keep the two iterators separate. So
"inline" `mmapped_ref_iterator` into `packed_ref_iterator`. This
removes a bunch of boilerplate.
Signed-off-by:
Now that we have an efficient way to iterate, in order, over the
mmapped contents of the `packed-refs` file, we can use that directly
to implement reference iteration for the `packed_ref_store`, rather
than iterating over the `ref_cache`. This is the next step towards
getting rid of the `ref_cache`
Now that everything has been changed to read what it needs directly
out of the `packed-refs` file, `packed_ref_store` doesn't need to
maintain a `ref_cache` at all. So get rid of it.
First of all, this will save a lot of memory and lots of little
allocations. Instead of needing to store complicate
We've made huge changes to this file, and some of the old names and
comments are no longer very fitting. So rename a bunch of things:
* `struct packed_ref_cache` → `struct snapshot`
* `acquire_packed_ref_cache()` → `acquire_snapshot()`
* `release_packed_ref_buffer()` → `clear_snapshot_buffer()`
*
Rather than store the peeling state (i.e., the one defined by traits
in the `packed-refs` file header line) in a local variable in
`read_packed_refs()`, store it permanently in `packed_ref_cache`. This
will be needed when we stop reading all packed refs at once.
Signed-off-by: Michael Haggerty
--
As long as a `packed_ref_cache` object is in use, keep the
corresponding `packed-refs` file open and mmapped.
This is still pointless, because we only read the file immediately
after instantiating the `packed_ref_cache`. But that will soon change.
Signed-off-by: Michael Haggerty
---
refs/packed
It's still done in a pretty stupid way, involving more data copying
than necessary. That will improve in future commits.
Signed-off-by: Michael Haggerty
---
refs/packed-backend.c | 42 --
1 file changed, 32 insertions(+), 10 deletions(-)
diff --git a/refs
It will prove convenient in upcoming patches.
Signed-off-by: Michael Haggerty
---
refs/packed-backend.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/refs/packed-backend.c b/refs/packed-backend.c
index e411501871..a3d9210cb0 100644
--- a/refs/packed
The old code parsed the traits in the `packed-refs` header by looking
for the string " trait " (i.e., the name of the trait with a space on
either side) in the header line. This is fragile, because if any other
implementation of Git forgets to write the trailing space, the last
trait would silently
This tightens up the parsing a bit; previously, stray header-looking
lines would have been processed.
Signed-off-by: Michael Haggerty
---
refs/packed-backend.c | 35 ---
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/refs/packed-backend.c b/refs/p
The prior commit converted many sites to check the return
value of write_in_full() for negativity, rather than a
mismatch with the input length. This patch covers similar
cases, but where the return value is stored in an
intermediate variable. These should get the same treatment,
but they need to b
If a reference is broken, suppress its peeled value.
Signed-off-by: Michael Haggerty
---
refs/packed-backend.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/refs/packed-backend.c b/refs/packed-backend.c
index 312116a99d..724c88631d 100644
--- a/refs/packed-backen
References are iterated over in order by refname, but reflogs are not.
Some consumers of reference iteration care about the difference. Teach
each `ref_iterator` to keep track of whether its output is ordered.
`overlay_ref_iterator` is one of the picky consumers. Add a sanity
check in `overlay_ref
From: Jeff King
If the underlying iterator is ordered, then `prefix_ref_iterator` can
stop as soon as it sees a refname that comes after the prefix. This
will rarely make a big difference now, because `ref_cache_iterator`
only iterates over the directory containing the prefix (and usually
the pre
Previously, any time we wanted to read even a single reference from
the `packed-refs` file, we parsed the whole file and stored it in an
elaborate structure in memory called a `ref_cache`. Subsequent
reference lookups or iterations over some or all of the references
could be done by reading from th
The return value of write_in_full() is either "-1", or the
requested number of bytes[1]. If we make a partial write
before seeing an error, we still return -1, not a partial
value. This goes back to f6aa66cb95 (write_in_full: really
write in full or return error on disk full., 2007-01-11).
So chec
We ask to write 41 bytes and make sure that the return value
is at least 41. This is the same "dangerous" pattern that
was fixed in the prior commit (wherein a negative return
value is promoted to unsigned), though it is not dangerous
here because our "41" is a constant, not an unsigned
variable.
The return type of write_in_full() is a signed ssize_t,
because we may return "-1" on failure (even if we succeeded
in writing some bytes). But "len" itself may be an
unsigned type (the function takes a size_t, but of course we
may have something else in the calling function). So while
it seems lik
> From: Jacob Keller [mailto:jacob.kel...@gmail.com]
> Sent: Tuesday, September 12, 2017 7:39 PM
>
> On Tue, Sep 12, 2017 at 4:30 PM, Kevin Willford wrote:
> >
> > Sorry. It was not in the sparse-checkout file.
> > $ git config core.sparsecheckout true
> > $ echo /i > .git/info/sparse-checkout
>
On Wed, Sep 13, 2017 at 01:59:17PM +0200, demerphq wrote:
> After being away for a while I saw the following message in one of my git
> repos:
>
> $ git status
> On branch yves/xxx
> Your branch is based on 'origin/yves/xxx', but the upstream is gone.
> (use "git branch --unset-upstream" to fi
Hi Dscho,
Johannes Schindelin wrote:
> So even if the code to generate a bidirectional old <-> new hash mapping
> might be with us forever, it *definitely* should be optional ("optional"
> at least as in "config setting"), allowing developers who only work with
> new-hash repositories to save the
On 13 September 2017 at 17:22, Jeff King wrote:
> On Wed, Sep 13, 2017 at 05:18:56PM +0200, demerphq wrote:
>
>> > Hmph. That is very disturbing. But with that information I should be
>> > able to track down the culprit. Thanks for digging.
>>
>> FWIW, I see that git_config_set_multivar_in_file_ge
On Wed, Sep 13, 2017 at 05:18:56PM +0200, demerphq wrote:
> > Hmph. That is very disturbing. But with that information I should be
> > able to track down the culprit. Thanks for digging.
>
> FWIW, I see that git_config_set_multivar_in_file_gently() uses
> write_in_full() which in turn uses xwrite
On 13 September 2017 at 16:51, Jeff King wrote:
> On Wed, Sep 13, 2017 at 04:49:45PM +0200, demerphq wrote:
>
>> On 13 September 2017 at 16:17, Jeff King wrote:
>> > You're welcome to read over the function to double-check, but I just
>> > looked it over and couldn't find any unchecked writes.
>>
Dear Git,
git merge-base --fork-point "master" not working if master is already newer
then my current branch.
Very oddly it seems to work whenever you had the expected commit checked out
previously - what made it very tricky to detect this problem.
Example:
- Clone "https://github.com/jekelhar
Am 13.09.2017 um 14:53 schrieb Jeff King:
> On Wed, Sep 13, 2017 at 12:43:57AM +0200, René Scharfe wrote:
>> Yet another way is have a few levels of nested subdirectories (e.g.
>> d1/d2/d3/file1) and ignoring the entries at the leaved (e.g. file1).
>
> s/leaved/leaves/ ?
Indeed.
René
On Wed, Sep 13, 2017 at 04:49:45PM +0200, demerphq wrote:
> On 13 September 2017 at 16:17, Jeff King wrote:
> > You're welcome to read over the function to double-check, but I just
> > looked it over and couldn't find any unchecked writes.
>
> I can look, but I doubt I would notice something you
On 13 September 2017 at 16:17, Jeff King wrote:
> You're welcome to read over the function to double-check, but I just
> looked it over and couldn't find any unchecked writes.
I can look, but I doubt I would notice something you did not.
On the other hand the strace output does show that this is
On Wed, Sep 13, 2017 at 03:38:52PM +0200, demerphq wrote:
> I just double checked the terminal history and this is all i saw:
>
> $ git status
> On branch yves/xxx
> Your branch is based on 'origin/yves/xxx', but the upstream is gone.
> (use "git branch --unset-upstream" to fixup)
>
> nothing
On Wed, Sep 13, 2017 at 10:45:45AM +0200, Michael Haggerty wrote:
> First of all there is a superficial naming inconsistency. This method is
> called `init` in the vtable, but the functions implementing it are
> called `*_ref_store_create()`. It actually initializes the data
> structures for dealin
On 13 September 2017 at 14:05, Johannes Schindelin
wrote:
> For example, I am still in favor of SHA-256 over SHA3-256, after learning
> some background details from in-house cryptographers: it provides
> essentially the same level of security, according to my sources, while
> hardware support seem
On 13 September 2017 at 14:34, Jeff King wrote:
> On Wed, Sep 13, 2017 at 01:59:17PM +0200, demerphq wrote:
>
>> After being away for a while I saw the following message in one of my git
>> repos:
>>
>> $ git status
>> On branch yves/xxx
>> Your branch is based on 'origin/yves/xxx', but the upstr
Hi Michael,
On Wed, 13 Sep 2017, Michael J Gruber wrote:
> Could you please try and report on the following (cygwin, MinGW):
>
> ulimit -s
> ulimit -s 4096 # anything lower than the value from above
> ulimit -s
> bash -c "ulimit -s"
Git Bash (MINGW, well, not precisely [*1*]):
me@work
Changes in v2:
- Changed the message as suggested by Jeff
- Made the commit message to be even more clear
---
Kaartic
It's not good to use the phrase 'do not touch' to convey the information
that the cut-line should not be modified or removed as it could possibly
be mis-interpreted by a person who doesn't know that the word 'touch' has
the meaning of 'tamper with'. Further, it could make translations a little
diff
On Mon, Sep 11, 2017 at 02:27:38PM +1000, Sam Bobroff wrote:
> > - It is very much intended to allow The "(foo)" after the "Notes"
> >label to show which notes ref the note comes from, because there
> >can be more than one notes refs that annotate the same commit.
>
> Right, that makes p
On Mon, Sep 11, 2017 at 11:40:05PM +0200, René Scharfe wrote:
> > Yes, but I didn't want to touch each code site that creates a file,
> > which is a lot more invasive. I expect expanding to 4096 (or PATH_MAX)
> > would be sufficient in practice.
>
> Perhaps it is in most cases. Having certainty
On Wed, Sep 13, 2017 at 12:43:57AM +0200, René Scharfe wrote:
> -- >8 --
> Subject: [PATCH] archive: don't add empty directories to archives
>
> While git doesn't track empty directories, git archive can be tricked
> into putting some into archives. One way is to construct an empty tree
> object
On Wed, Sep 13, 2017 at 01:59:17PM +0200, demerphq wrote:
> After being away for a while I saw the following message in one of my git
> repos:
>
> $ git status
> On branch yves/xxx
> Your branch is based on 'origin/yves/xxx', but the upstream is gone.
> (use "git branch --unset-upstream" to fi
On Wednesday 13 September 2017 04:50 PM, Jeff King wrote:
I agree with both of your points. It is very clear to me as a native
speaker, but I can see how it might not be for everyone.
Interestingly, the change here:
- const char *explanation = _("Do not touch the line above.\nEverything
1 - 100 of 114 matches
Mail list logo