Re: RFC v3: Another proposed hash function transition plan

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

Re: RFC v3: Another proposed hash function transition plan

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

Re: [PATCH v2] config: avoid "write_in_full(fd, buf, len) < len" pattern

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

Re: RFC v3: Another proposed hash function transition plan

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

Investment

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

Re: [PATCH 20/20] packed-backend.c: rename a bunch of things and update comments

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` > *

Re: RFC v3: Another proposed hash function transition plan

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 >>

Re: [PATCH v2] config: avoid "write_in_full(fd, buf, len) < len" pattern

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

Re: [PATCH 3/8] daemon: recognize hidden request arguments

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)

Re: RFC v3: Another proposed hash function transition plan

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: [PATCH 2/8] protocol: introduce protocol extention mechanisms

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

Re: RFC v3: Another proposed hash function transition plan

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

Re: [PATCH 1/1] reset: fix reset when using the sparse-checkout feature.

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

Re: RFC v3: Another proposed hash function transition plan

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

Re: RFC v3: Another proposed hash function transition plan

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

[PATCH 8/8] i5700: add interop test for protocol transition

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

[PATCH 7/8] http: tell server that the client understands v1

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

[PATCH 6/8] connect: tell server that the client understands v1

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:

[PATCH 1/8] pkt-line: add packet_write function

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 ---

[PATCH 5/8] connect: teach client to recognize v1 server response

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

[PATCH 4/8] upload-pack, receive-pack: introduce protocol version 1

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

[PATCH 0/8] protocol transition

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

[PATCH 3/8] daemon: recognize hidden request arguments

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

[PATCH 2/8] protocol: introduce protocol extention mechanisms

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.

Re: RFC v3: Another proposed hash function transition plan

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

Re: [PATCH 00/20] Read `packed-refs` using mmap()

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

Re: [PATCH v2] config: avoid "write_in_full(fd, buf, len) < len" pattern

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

Re: [PATCH 7/7] config: flip return value of store_write_*()

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()

Re: [PATCH 6/7] notes-merge: use ssize_t for write_in_full() return value

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

Re: [PATCH 5/7] pkt-line: check write_in_full() errors against "< 0"

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

Re: [PATCH 4/7] convert less-trivial versions of "write_in_full() != len"

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

Re: [PATCH 3/7] avoid "write_in_full(fd, buf, len) != len" pattern

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

Re: [PATCH 2/7] get-tar-commit-id: check write_in_full() return against 0

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

Re: [PATCH v2] config: avoid "write_in_full(fd, buf, len) < len" pattern

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

Re: [PATCH] test-lib: don't use ulimit in test prerequisites on cygwin

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

Re: [PATCH v2] config: avoid "write_in_full(fd, buf, len) < len" pattern

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

Re: [PATCH 8/7] read_pack_header: handle signed/unsigned comparison in read result

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 >

[PATCH] test-lib: don't use ulimit in test prerequisites on cygwin

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

Re: [PATCH v2] config: avoid "write_in_full(fd, buf, len) < len" pattern

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. >

BUSINESS PROPOSAL

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

Re: [PATCH 2/7] get-tar-commit-id: check write_in_full() return against 0

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

Re: [PATCH v2] config: avoid "write_in_full(fd, buf, len) < len" pattern

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.

[PATCH v2] config: avoid "write_in_full(fd, buf, len) < len" pattern

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

Re: [PATCH 1/7] config: avoid "write_in_full(fd, buf, len) < len" pattern

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

Re: [PATCH 2/7] get-tar-commit-id: check write_in_full() return against 0

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

Re: [PATCH 1/7] config: avoid "write_in_full(fd, buf, len) < len" pattern

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:

Re: [PATCH 2/7] get-tar-commit-id: check write_in_full() return against 0

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

Re: [PATCH 1/7] config: avoid "write_in_full(fd, buf, len) < len" pattern

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

Re: [PATCH 1/7] config: avoid "write_in_full(fd, buf, len) < len" pattern

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

[PATCH 7/7] config: flip return value of store_write_*()

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.

[PATCH 5/7] pkt-line: check write_in_full() errors against "< 0"

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:

[PATCH 6/7] notes-merge: use ssize_t for write_in_full() return value

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

[PATCH 16/20] ref_store: implement `refs_peel_ref()` generically

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

[PATCH 13/20] read_packed_refs(): ensure that references are ordered when read

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

[PATCH 08/20] read_packed_refs(): read references with minimal copying

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

[PATCH 04/20] die_unterminated_line(), die_invalid_line(): new functions

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

[PATCH 10/20] mmapped_ref_iterator: add iterator over a packed-refs file

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

[PATCH 15/20] packed_read_raw_ref(): read the reference from the mmapped buffer

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

[PATCH 18/20] ref_cache: remove support for storing peeled values

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

[PATCH 19/20] mmapped_ref_iterator: inline into `packed_ref_iterator`

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:

[PATCH 14/20] packed_ref_iterator_begin(): iterate using `mmapped_ref_iterator`

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

[PATCH 17/20] packed_ref_store: get rid of the `ref_cache` entirely

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

[PATCH 20/20] packed-backend.c: rename a bunch of things and update comments

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()` *

[PATCH 09/20] packed_ref_cache: remember the file-wide peeling state

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

[PATCH 12/20] packed_ref_cache: keep the `packed-refs` file open and mmapped

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

[PATCH 05/20] read_packed_refs(): use mmap to read the `packed-refs` file

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

[PATCH 03/20] packed_ref_cache: add a backlink to the associated `packed_ref_store`

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

[PATCH 07/20] read_packed_refs(): make parsing of the header line more robust

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

[PATCH 06/20] read_packed_refs(): only check for a header at the top of the file

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

[PATCH 4/7] convert less-trivial versions of "write_in_full() != len"

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

[PATCH 11/20] mmapped_ref_iterator_advance(): no peeled value for broken refs

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

[PATCH 01/20] ref_iterator: keep track of whether the iterator output is ordered

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

[PATCH 02/20] prefix_ref_iterator: break when we leave the prefix

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

[PATCH 00/20] Read `packed-refs` using mmap()

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

[PATCH 3/7] avoid "write_in_full(fd, buf, len) != len" pattern

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

[PATCH 2/7] get-tar-commit-id: check write_in_full() return against 0

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.

[PATCH 1/7] config: avoid "write_in_full(fd, buf, len) < len" pattern

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

RE: [PATCH 1/1] reset: fix reset when using the sparse-checkout feature.

> 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 >

[PATCH 0/7] config.c may fail to notice some write() failures

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

Re: RFC v3: Another proposed hash function transition plan

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

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

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

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

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

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

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

RE: merge-base not working as expected when base is ahead

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

Re: [PATCH 4/4] archive: queue directories for all types of pathspecs

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é

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

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

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

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

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

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

Re: [PATCH 4/4] packed refs: pass .git dir instead of packed-refs path to init_fn

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

Re: RFC v3: Another proposed hash function transition plan

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,

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

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

Re: Unexpected pass for t6120-describe.sh on cygwin

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

[PATCH v2] commit-template: change a message to be more intuitive

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

[PATCH v2] commit-template: change a message to be more intuitive

Changes in v2: - Changed the message as suggested by Jeff - Made the commit message to be even more clear --- Kaartic

Re: [PATCH] format-patch: use raw format for notes

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

Re: [PATCH 06/34] clone: release strbuf after use in remove_junk()

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

Re: [PATCH 4/4] archive: queue directories for all types of pathspecs

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 >

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

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

Re: [PATCH] commit-template: change a message to be more intuitive

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

Re: [PATCH] commit-template: change a message to be more intuitive

On Wednesday 13 September 2017 03:59 PM, Kevin Daudt wrote: Touching something can also mean to disturb or change something, which is the meaning being used here, so it is not an incorrect use of the word. I do get your point but I should have been clearer in my commit message about the fact

  1   2   >