Re: [PATCH v7 0/7] convert: add support for different encodings

> On 27 Feb 2018, at 22:25, Jeff King wrote: > > On Tue, Feb 27, 2018 at 10:05:17PM +0100, Torsten Bögershausen wrote: > > Of the three solutions, I think the relative merits are something like > this: > > 1. baked-in textconv (my patch) > > - reuses an existing diff

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Sergey, On 28/02/2018 07:14, Sergey Organov wrote: > > > > Would additional step as suggested in [1] (using R1 and R2 to "catch" > > > interactive rebase additions/amendments/drops, on top of U1' and > > > U2'), make more sense (or provide an additional clue, at least)? > > > > > > [1] >

RE: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

On February 28, 2018 12:44 PM, Jonathan Nieder wrote: > Randall S. Becker wrote: > > > The problem is actually in git code in its test suite that uses perl > > inline, not in my test code itself. The difficulty I'm having is > > placing this appropriate so that the signal handler gets used > >

Re: [PATCH 00/11] Moving global state into the repository object (part 2)

Stefan Beller writes: > On Wed, Feb 28, 2018 at 9:59 AM, Junio C Hamano wrote: >> Duy Nguyen writes: >> >>> Looking at the full-series diff though, it makes me wonder if we >>> should keep prepare_packed_git() private (i.e. how we

RE: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

On February 28, 2018 1:52 PM, Jonathan Nieder wrote: > Randall S. Becker wrote: > > On February 28, 2018 12:44 PM, Jonathan Nieder wrote: > >> Randall S. Becker wrote: > > >>> The problem is actually in git code in its test suite that uses perl > >>> inline, not in my test code itself. > [...] >

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Sergey, On 28/02/2018 06:19, Sergey Organov wrote: > > > > (3) ---X1---o---o---o---o---o---X2 > > >|\ |\ > > >| A1---A2---A3---U1 | A1'--A2'--A3'--U1' > > >| \ | > > >| M | > > >|

Re: [PATCH v2] sha1_name: fix uninitialized memory errors

Derrick Stolee writes: >> I do not think they are wrong, but aren't the latter two somewhat >> redundant? "num" is p->num_objects, and we call (first+1)th element >> only after we see (first < num - 1), i.e. first+1 < num, and the >> access to (first-1)th is done only when

Re: [PATCH v2 0/5] roll back locks in various code paths

> I'll follow up with a patch to > address the confusing pattern which Peff mentioned and which fooled me > when I prepared v1. Here is such a patch on top of the others. I'm not particularly proud of the name SKIP_IF_UNCHANGED, but don't think it's any worse than, e.g., IGNORE_UNCHANGED or

Re: [PATCH v2] sha1_name: fix uninitialized memory errors

Derrick Stolee writes: > diff --git a/sha1_name.c b/sha1_name.c > index 611c7d24dd..a041d8d24f 100644 > --- a/sha1_name.c > +++ b/sha1_name.c > @@ -547,15 +547,15 @@ static void find_abbrev_len_for_pack(struct packed_git > *p, >*/ > mad->init_len = 0; >

I Hope You Get My Message This Time

-- -- This is the second time i am sending you this mail.I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally for more details. Regards. Friedrich Mayrhofer

Re: [PATCH] hooks/pre-auto-gc-battery: allow gc to run on non-laptops

Adam Borowski writes: > Desktops and servers tend to have no power sensor, thus on_ac_power returns > 255 ("unknown"). > > If that tool returns "unknown", there's no point in querying other sources > as it already queried them, and is smarter than us (can handle multiple >

Re: Reduce pack-objects memory footprint?

Duy Nguyen wrote: > which saves 12 bytes (or another 74 MB). 222 MB total is plenty of > space to keep some file cache from being evicted. Nice! I can definitely benefit from lower memory usage when packing. Fwiw, I use pahole with other projects to help find packing

Re: [PATCH 00/11] Moving global state into the repository object (part 2)

On Wed, Feb 28, 2018 at 9:59 AM, Junio C Hamano wrote: > Duy Nguyen writes: > >> Looking at the full-series diff though, it makes me wonder if we >> should keep prepare_packed_git() private (i.e. how we initialize the >> object store, packfile included, is a

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Sergey, On 28/02/2018 06:44, Sergey Organov wrote: > > > > Here`s our starting position: > > > > > > (0) ---X1---o---o---o---o---o---X2 (master) > > >|\ > > >| A1---A2---A3 > > >| \ > > >| M (topic) > > >| / > > >

Re: [PATCH 00/11] Moving global state into the repository object (part 2)

On Wed, Feb 28, 2018 at 9:57 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> This applies on top of origin/sb/object-store and is the continuation of >> that series, adding the repository as a context argument to functions. > > Wait a minute. Is

[PATCH v2 2/5] sequencer: always roll back lock in `do_recursive_merge()`

If we return early, we forget to roll back the lockfile. Do so. Signed-off-by: Martin Ågren --- sequencer.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sequencer.c b/sequencer.c index 90807c4559..e6bac4692a 100644 --- a/sequencer.c +++

[PATCH v2 0/5] roll back locks in various code paths

This is v2 of my series to always release locks. As before, there's a conflict with pu, where the correct resolution is to take my version of the conflicting hunk. The only difference to v1 is in patch 3. I'll follow up with a patch to address the confusing pattern which Peff mentioned and which

[PATCH v2 5/5] sequencer: do not roll back lockfile unnecessarily

If `commit_lock_file()` or `hold_lock_file_for_update()` fail, there is no need to call `rollback_lock_file()` on the lockfile. It doesn't hurt either, but it does make different callers in this file inconsistent, which might be confusing. While at it, remove a trailing '.' from a recurring error

[PATCH v2 1/5] sequencer: make lockfiles non-static

After 076aa2cbd (tempfile: auto-allocate tempfiles on heap, 2017-09-05), we can have lockfiles on the stack. One of these functions fails to always roll back the lock. That will be fixed in the next commit. Signed-off-by: Martin Ågren --- sequencer.c | 10 +- 1

Re: [PATCH v3 34/35] remote-curl: implement stateless-connect command

On 02/27, Jonathan Nieder wrote: > Hi, > > Brandon Williams wrote: > > > Teach remote-curl the 'stateless-connect' command which is used to > > establish a stateless connection with servers which support protocol > > version 2. This allows remote-curl to act as a proxy, allowing the git > >

Re: [PATCH v3 0/4] Delete ignore_env member in struct repository

On 02/28, Nguyễn Thái Ngọc Duy wrote: > v3 fixes comment style. Also since Brandon raised a question about > shared_root, it's obviously not a good name, so I renamed it to > commondir. Thanks, its a bit clearer and more consistent with the rest of the terminology we already have :) > > I still

Re: [PATCH 00/11] Moving global state into the repository object (part 2)

Junio C Hamano writes: > Stefan Beller writes: > >> This applies on top of origin/sb/object-store and is the continuation of >> that series, adding the repository as a context argument to functions. > > Wait a minute. Is that topic ever shown to work well

Re: [PATCH v2] sha1_name: fix uninitialized memory errors

On 2/28/2018 3:50 PM, Junio C Hamano wrote: Derrick Stolee writes: diff --git a/sha1_name.c b/sha1_name.c index 611c7d24dd..a041d8d24f 100644 --- a/sha1_name.c +++ b/sha1_name.c @@ -547,15 +547,15 @@ static void find_abbrev_len_for_pack(struct packed_git *p, */

Re: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

Randall S. Becker wrote: > On February 28, 2018 12:44 PM, Jonathan Nieder wrote: >> Randall S. Becker wrote: >>> The problem is actually in git code in its test suite that uses perl >>> inline, not in my test code itself. [...] >> Can you elaborate with an example? My understanding was that >>

Re: [PATCH 00/11] Moving global state into the repository object (part 2)

On Wed, Feb 28, 2018 at 11:02 AM, Junio C Hamano wrote: > OK, so I finally picked up the last round, which wasn't even in my > private build. I had the previous round but hadn't convinced myself > that my conflict resolution with other topics in flight that were > still mushy

Re: [PATCH v3 28/35] transport-helper: introduce stateless-connect

On 02/27, Jonathan Nieder wrote: > Brandon Williams wrote: > > > Introduce the transport-helper capability 'stateless-connect'. This > > capability indicates that the transport-helper can be requested to run > > the 'stateless-connect' command which should attempt to make a > > stateless

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Sergey, On 28/02/2018 06:21, Sergey Organov wrote: > > > > > > (3) ---X1---o---o---o---o---o---X2 > > > > >|\ |\ > > > > >| A1---A2---A3---U1 | A1'--A2'--A3'--U1' > > > > >| \ | > > > > >| M |

[PATCH v2 4/5] merge: always roll back lock in `checkout_fast_forward()`

This function originated in builtin/merge.c. It was moved to merge.c in commit db699a8a1f (Move try_merge_command and checkout_fast_forward to libgit.a, 2012-10-26), but was used from sequencer.c even before that. If a problem occurs, the function returns without rolling back the lockfile. Teach

[PATCH v2 3/5] merge-recursive: always roll back lock in `merge_recursive_generic()`

If we return early, or if `active_cache_changed` is false, we forget to roll back the lockfile. Signed-off-by: Martin Ågren --- merge-recursive.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/merge-recursive.c b/merge-recursive.c index

I wait for your prompt response.

Good day, I am Mr. Sam Azada from Burkina Faso a Minister confide on me to look for foreign partner who will assist him to invest the sum of Fifty Million Dollars ($50,000,000) in your country. He has investment interest in mining, exotic properties for commercial resident, development

Re: [PATCH 00/11] Moving global state into the repository object (part 2)

Hi, Stefan Beller wrote: > On Wed, Feb 28, 2018 at 9:57 AM, Junio C Hamano wrote: >> Wait a minute. Is that topic ever shown to work well together with >> other topics in flight and are now ready to be built upon? I had an >> impression that it is just starting to get

Re: [PATCH] protocol: treat unrecognized protocol.version setting as 0

Hi, Junio C Hamano wrote: > Jonathan Nieder writes: >> If I share my .gitconfig or .git/config file between multiple machines >> (or between multiple Git versions on a single machine) and set >> >> [protocol] >> version = 2 >> >> then running "git fetch"

Re: [PATCH v4 04/13] commit-graph: implement write_commit_graph()

Derrick Stolee writes: > diff --git a/commit-graph.h b/commit-graph.h > new file mode 100644 > index 000..dc8c73a > --- /dev/null > +++ b/commit-graph.h > @@ -0,0 +1,7 @@ > +#ifndef COMMIT_GRAPH_H > +#define COMMIT_GRAPH_H > + > +extern char *write_commit_graph(const char

Re: [GSoC][PATCH] userdiff: add built-in pattern for golang

On Wed, Feb 28, 2018 at 12:29 PM, Alban Gruin wrote: > This adds xfuncname and word_regex patterns for golang, a quite > popular programming language. It also includes test cases for the > xfuncname regex (t4018) and an updated documentation. s/an // > The xfuncname regex

Re: [PATCH v3 0/4] Delete ignore_env member in struct repository

Nguyễn Thái Ngọc Duy writes: > v3 fixes comment style. Also since Brandon raised a question about > shared_root, it's obviously not a good name, so I renamed it to > commondir. > > I still keep the delete patch 2/4, but I move the repo_setup_env() > deletion back to 1/4 so

Obsolete instruction in SubmittingPatches?

Hello, It seems to me that this part of Documentation/SubmittingPatches is not actual nowadays: After the list reached a consensus that it is a good idea to apply the patch, re-send it with "To:" set to the maintainer{1} and "cc:" the list{2} for inclusion. >From what I observe in the

Re: [GSoC][PATCH] userdiff: add built-in pattern for golang

>> diff --git a/userdiff.c b/userdiff.c >> @@ -38,6 +38,15 @@ IPATTERN("fortran", >> +PATTERNS("golang", >> +/* Functions */ >> +"^[ \t]*(func[ \t]*.*(\\{[ \t]*)?)\n" > > Why is the brace (and possible following whitespace) optional? > Considering that the language demands that

Re: [PATCH] hooks/pre-auto-gc-battery: allow gc to run on non-laptops

Adam Borowski writes: > 0 usually means a laptop on AC power, 255 is for a typical desktop. > The current code can't return 2 or any other unexpected value, but if it > ever does, an unknown error should probably be treated same as 255 unknown. > Thus, gc should be avoided

Re: [GSoC][PATCH] userdiff: add built-in pattern for golang

On Wed, Feb 28, 2018 at 5:17 PM, Alban Gruin wrote: > Yes, but I can split the line like that: > > % cat >baz.go<<\EOF > package baz > func baz(arg1 int64, > arg2 int64) { > } > EOF > % go build baz.go > > This complies to the standard

Re: [GSoC][PATCH] userdiff: add built-in pattern for golang

Le 28/02/2018 à 23:32, Junio C Hamano a écrit : > Eric Sunshine writes: > >> On Wed, Feb 28, 2018 at 5:17 PM, Alban Gruin wrote: >>> Yes, but I can split the line like that: >>> >>> % cat >baz.go<<\EOF >>> package baz >>> func baz(arg1

Re: Obsolete instruction in SubmittingPatches?

Andrei Rybak writes: > Is this part of guidelines obsolete, or am I not understanding this > correctly? I am merely being nice (but only on "time-permitting" basis).

Re: [GSoC][PATCH] userdiff: add built-in pattern for golang

Le 28/02/2018 à 23:00, Eric Sunshine a écrit : > On Wed, Feb 28, 2018 at 4:31 PM, Alban Gruin wrote: diff --git a/userdiff.c b/userdiff.c @@ -38,6 +38,15 @@ IPATTERN("fortran", +PATTERNS("golang", +/* Functions */ +"^[ \t]*(func[

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

On 28/02/2018 21:25, Igor Djordjevic wrote: > > But U1' and U2' are really to be expected to stay the same in > non-interactive rebase case only... Just to rephrase to "could be expected" here, meaning still not necessarily in this case, either - I`ve just witnessed non-interactive rebase

Re: [PATCH v2] hooks/pre-auto-gc-battery: allow gc to run on non-laptops

Adam Borowski writes: > Desktops and servers tend to have no power sensor, thus on_ac_power returns > 255 ("unknown"). Thus, let's take any answer other than 1 ("battery") as > no contraindication to run gc. > > If that tool returns "unknown", there's no point in querying

[PATCH v4 21/35] fetch-pack: perform a fetch using v2

When communicating with a v2 server, perform a fetch by requesting the 'fetch' command. Signed-off-by: Brandon Williams --- Documentation/technical/protocol-v2.txt | 68 +- builtin/fetch-pack.c| 2 +- fetch-pack.c| 270

[PATCH v4 33/35] http: eliminate "# service" line when using protocol v2

When an http info/refs request is made, requesting that protocol v2 be used, don't send a "# service" line since this line is not part of the v2 spec. Signed-off-by: Brandon Williams --- http-backend.c | 8 ++-- remote-curl.c | 3 +++ 2 files changed, 9 insertions(+), 2

[PATCH v4 34/35] remote-curl: implement stateless-connect command

Teach remote-curl the 'stateless-connect' command which is used to establish a stateless connection with servers which support protocol version 2. This allows remote-curl to act as a proxy, allowing the git client to communicate natively with a remote end, simply using remote-curl as a pass

[PATCH v4 31/35] http: allow providing extra headers for http requests

Add a way for callers to request that extra headers be included when making http requests. Signed-off-by: Brandon Williams --- http.c | 8 http.h | 7 +++ 2 files changed, 15 insertions(+) diff --git a/http.c b/http.c index 597771271..e1757d62b 100644 ---

[PATCH v4 20/35] upload-pack: introduce fetch server command

Introduce the 'fetch' server command. Signed-off-by: Brandon Williams --- Documentation/technical/protocol-v2.txt | 128 serve.c | 2 + t/t5701-git-serve.sh| 1 + upload-pack.c |

[PATCH v4 32/35] http: don't always add Git-Protocol header

Instead of always sending the Git-Protocol header with the configured version with every http request, explicitly send it when discovering refs and then only send it on subsequent http requests if the server understood the version requested. Signed-off-by: Brandon Williams ---

[PATCH v4 27/35] transport-helper: introduce stateless-connect

Introduce the transport-helper capability 'stateless-connect'. This capability indicates that the transport-helper can be requested to run the 'stateless-connect' command which should attempt to make a stateless connection with a remote end. Once established, the connection can be used by the

[PATCH v4 16/35] transport: convert transport_get_remote_refs to take a list of ref patterns

Convert 'transport_get_remote_refs()' to optionally take a list of ref patterns. Signed-off-by: Brandon Williams --- builtin/clone.c | 2 +- builtin/fetch.c | 4 ++-- builtin/ls-remote.c | 2 +- builtin/remote.c| 2 +- transport.c | 7 +--

[PATCH v4 17/35] ls-remote: pass ref patterns when requesting a remote's refs

Construct an argv_array of the ref patterns supplied via the command line and pass them to 'transport_get_remote_refs()' to be used when communicating protocol v2 so that the server can limit the ref advertisement based on the supplied patterns. Signed-off-by: Brandon Williams

[PATCH v4 24/35] connect: don't request v2 when pushing

In order to be able to ship protocol v2 with only supporting fetch, we need clients to not issue a request to use protocol v2 when pushing (since the client currently doesn't know how to push using protocol v2). This allows a client to have protocol v2 configured in `protocol.version` and take

[PATCH v4 28/35] pkt-line: add packet_buf_write_len function

Add the 'packet_buf_write_len()' function which allows for writing an arbitrary length buffer into a 'struct strbuf' and formatting it in packet-line format. Signed-off-by: Brandon Williams --- pkt-line.c | 16 pkt-line.h | 1 + 2 files changed, 17

[PATCH v4 30/35] remote-curl: store the protocol version the server responded with

Store the protocol version the server responded with when performing discovery. This will be used in a future patch to either change the 'Git-Protocol' header sent in subsequent requests or to determine if a client needs to fallback to using a different protocol version. Signed-off-by: Brandon

[PATCH v4 23/35] connect: refactor git_connect to only get the protocol version once

Instead of having each builtin transport asking for which protocol version the user has configured in 'protocol.version' by calling `get_protocol_version_config()` multiple times, factor this logic out so there is just a single call at the beginning of `git_connect()`. This will be helpful in the

[PATCH v4 22/35] fetch-pack: support shallow requests

Enable shallow clones and deepen requests using protocol version 2 if the server 'fetch' command supports the 'shallow' feature. Signed-off-by: Brandon Williams --- connect.c| 22 connect.h| 2 ++ fetch-pack.c | 71

[PATCH v4 25/35] transport-helper: remove name parameter

Commit 266f1fdfa (transport-helper: be quiet on read errors from helpers, 2013-06-21) removed a call to 'die()' which printed the name of the remote helper passed in to the 'recvline_fh()' function using the 'name' parameter. Once the call to 'die()' was removed the parameter was no longer

[PATCH v4 29/35] remote-curl: create copy of the service name

Make a copy of the service name being requested instead of relying on the buffer pointed to by the passed in 'const char *' to remain unchanged. Currently, all service names are string constants, but a subsequent patch will introduce service names from external sources. Signed-off-by: Brandon

[PATCH v4 35/35] remote-curl: don't request v2 when pushing

In order to be able to ship protocol v2 with only supporting fetch, we need clients to not issue a request to use protocol v2 when pushing (since the client currently doesn't know how to push using protocol v2). This allows a client to have protocol v2 configured in `protocol.version` and take

Re: [PATCH v2] commit: run git gc --auto just before the pre-commit hook

Ævar Arnfjörð Bjarmason writes: >> Ævar Arnfjörð Bjarmason writes: >> >>> Change the behavior of git-commit back to what it was back in >>> d4bb43ee27 ("Invoke "git gc --auto" from commit, merge, am and >>> rebase.", 2007-09-05) when it was git-commit.sh.

Re: [PATCH v8 5/7] convert: add 'working-tree-encoding' attribute

On Tue, Feb 27, 2018 at 6:16 AM, Lars Schneider wrote: >> On 25 Feb 2018, at 08:15, Eric Sunshine wrote: >> On Sat, Feb 24, 2018 at 11:27 AM, wrote: >> The above paragraph is giving an example of the scenario

Re: [PATCH] commit: run git gc --auto just before the pre-commit hook

Ævar Arnfjörð Bjarmason writes: > Change the behavior of git-commit back to what it was back in > d4bb43ee27 ("Invoke "git gc --auto" from commit, merge, am and > rebase.", 2007-09-05) when it was git-commit.sh. ... which was to run it just before post-commit. Do I retitle

[PATCH] commit: run git gc --auto just before the pre-commit hook

Change the behavior of git-commit back to what it was back in d4bb43ee27 ("Invoke "git gc --auto" from commit, merge, am and rebase.", 2007-09-05) when it was git-commit.sh. Shortly afterwards in f5bbc3225c ("Port git commit to C.", 2007-11-08) when it was ported to C the "git gc --auto"

Re: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

Randall S. Becker wrote: > The original thread below has details of what the original issue was and > why. It hit three tests specifically on this platform where die was invoked > (at least on one of them). Perl was invoked under the covers and the > completion code of 169 propagated back through

[PATCH v4 26/35] transport-helper: refactor process_connect_service

A future patch will need to take advantage of the logic which runs and processes the response of the connect command on a remote helper so factor out this logic from 'process_connect_service()' and place it into a helper function 'run_connect()'. Signed-off-by: Brandon Williams

[PATCH v4 18/35] fetch: pass ref patterns when fetching

Construct a list of ref patterns to be passed to 'transport_get_remote_refs()' from the refspec to be used during the fetch. This list of ref patterns will be used to allow the server to filter the ref advertisement when communicating using protocol v2. Signed-off-by: Brandon Williams

The case for two trees in a commit ("How to make rebase less modal")

$ git hash-object --stdin -w -t commit < 1519859216 -0800 committer Stefan Beller 1519859216 -0800 tree 5495266479afc9a4bd9560e9feac465ed43fa63a test commit EOF 19abfc3bf1c5d782045acf23abdf7eed81e16669 $ git fsck |grep 19abfc3bf1c5d782045acf23abdf7eed81e16669 $ So it is

Re: [PATCH v8 3/7] utf8: add function to detect prohibited UTF-16/32 BOM

> On 27 Feb 2018, at 06:17, Eric Sunshine wrote: > > On Sun, Feb 25, 2018 at 6:35 AM, Lars Schneider > wrote: >>> On 25 Feb 2018, at 04:41, Eric Sunshine wrote: >>> Is this interpretation correct? When I read [1], I

RE: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

On February 28, 2018 3:04 PM, Jonathan Nieder wrote: > On February 28, 2018 1:52 PM, Jonathan Nieder wrote: > > Randall S. Becker wrote: > > > On February 28, 2018 12:44 PM, Jonathan Nieder wrote: > > >> Randall S. Becker wrote: > > > > >>> The problem is actually in git code in its test suite

Re: [PATCH v2 0/5] roll back locks in various code paths

Martin Ågren writes: > A further upshot of this patch is that `active_cache_changed`, which is > defined as `the_index.cache_changed`, now only has a few users left. I am undecided if this is a *good* thing. In a few codepaths where we make a speculative update to the

[PATCH v2] hooks/pre-auto-gc-battery: allow gc to run on non-laptops

Desktops and servers tend to have no power sensor, thus on_ac_power returns 255 ("unknown"). Thus, let's take any answer other than 1 ("battery") as no contraindication to run gc. If that tool returns "unknown", there's no point in querying other sources as it already queried them, and is

Re: [GSoC][PATCH] userdiff: add built-in pattern for golang

Eric Sunshine writes: > On Wed, Feb 28, 2018 at 5:17 PM, Alban Gruin wrote: >> Yes, but I can split the line like that: >> >> % cat >baz.go<<\EOF >> package baz >> func baz(arg1 int64, >> arg2 int64) { >> } >> EOF >>

[PATCH v4 01/35] pkt-line: introduce packet_read_with_status

The current pkt-line API encodes the status of a pkt-line read in the length of the read content. An error is indicated with '-1', a flush with '0' (which can be confusing since a return value of '0' can also indicate an empty pkt-line), and a positive integer for the length of the read content

[PATCH v4 11/35] test-pkt-line: introduce a packet-line test helper

Introduce a packet-line test helper which can either pack or unpack an input stream into packet-lines and writes out the result to stdout. Signed-off-by: Brandon Williams --- Makefile | 1 + t/helper/test-pkt-line.c | 64

[PATCH v4 06/35] transport: use get_refs_via_connect to get refs

Remove code duplication and use the existing 'get_refs_via_connect()' function to retrieve a remote's heads in 'fetch_refs_via_pack()' and 'git_transport_push()'. Signed-off-by: Brandon Williams --- transport.c | 18 -- 1 file changed, 4 insertions(+), 14

[PATCH v4 05/35] upload-pack: factor out processing lines

Factor out the logic for processing shallow, deepen, deepen_since, and deepen_not lines into their own functions to simplify the 'receive_needs()' function in addition to making it easier to reuse some of this logic when implementing protocol_v2. Signed-off-by: Brandon Williams

[PATCH v4 03/35] pkt-line: add delim packet support

One of the design goals of protocol-v2 is to improve the semantics of flush packets. Currently in protocol-v1, flush packets are used both to indicate a break in a list of packet lines as well as an indication that one side has finished speaking. This makes it particularly difficult to implement

[PATCH v4 12/35] serve: introduce git-serve

Introduce git-serve, the base server for protocol version 2. Protocol version 2 is intended to be a replacement for Git's current wire protocol. The intention is that it will be a simpler, less wasteful protocol which can evolve over time. Protocol version 2 improves upon version 1 by

[PATCH v4 02/35] pkt-line: allow peeking a packet line without consuming it

Sometimes it is advantageous to be able to peek the next packet line without consuming it (e.g. to be able to determine the protocol version a server is speaking). In order to do that introduce 'struct packet_reader' which is an abstraction around the normal packet reading logic. This enables a

[PATCH v4 09/35] transport: store protocol version

Once protocol_v2 is introduced requesting a fetch or a push will need to be handled differently depending on the protocol version. Store the protocol version the server is speaking in 'struct git_transport_data' and use it to determine what to do in the case of a fetch or a push. Signed-off-by:

[PATCH v4 10/35] protocol: introduce enum protocol_version value protocol_v2

Introduce protocol_v2, a new value for 'enum protocol_version'. Subsequent patches will fill in the implementation of protocol_v2. Signed-off-by: Brandon Williams --- builtin/fetch-pack.c | 2 ++ builtin/receive-pack.c | 6 ++ builtin/send-pack.c| 3 +++

[PATCH v4 15/35] transport: convert get_refs_list to take a list of ref patterns

Convert the 'struct transport' virtual function 'get_refs_list()' to optionally take an argv_array of ref patterns. When communicating with a server using protocol v2 these ref patterns can be sent when requesting a listing of their refs allowing the server to filter the refs it sends based on

[PATCH v4 19/35] push: pass ref patterns when pushing

Construct a list of ref patterns to be passed to 'get_refs_list()' from the refspec to be used during the push. This list of ref patterns will be used to allow the server to filter the ref advertisement when communicating using protocol v2. Signed-off-by: Brandon Williams ---

[PATCH v4 13/35] ls-refs: introduce ls-refs server command

Introduce the ls-refs server command. In protocol v2, the ls-refs command is used to request the ref advertisement from the server. Since it is a command which can be requested (as opposed to mandatory in v1), a client can sent a number of parameters in its request to limit the ref advertisement

[PATCH v4 04/35] upload-pack: convert to a builtin

In order to allow for code sharing with the server-side of fetch in protocol-v2 convert upload-pack to be a builtin. Signed-off-by: Brandon Williams --- Makefile | 3 +- builtin.h | 1 + builtin/upload-pack.c | 67 ++

[PATCH v4 00/35] protocol version 2

Lots of changes since v3 (well more than between v2 and v3). Thanks for all of the reviews on the last round, the series is getting more polished. * Eliminated the "# service" line from the response from an HTTP server. This means that the response to a v2 request is exactly the same

[PATCH v4 07/35] connect: convert get_remote_heads to use struct packet_reader

In order to allow for better control flow when protocol_v2 is introduced convert 'get_remote_heads()' to use 'struct packet_reader' to read packet lines. This enables a client to be able to peek the first line of a server's response (without consuming it) in order to determine the protocol

[PATCH v4 14/35] connect: request remote refs using v2

Teach the client to be able to request a remote's refs using protocol v2. This is done by having a client issue a 'ls-refs' request to a v2 server. Signed-off-by: Brandon Williams --- builtin/upload-pack.c | 10 +-- connect.c | 138

[PATCH v4 08/35] connect: discover protocol version outside of get_remote_heads

In order to prepare for the addition of protocol_v2 push the protocol version discovery outside of 'get_remote_heads()'. This will allow for keeping the logic for processing the reference advertisement for protocol_v1 and protocol_v0 separate from the logic for protocol_v2. Signed-off-by:

Re: [PATCH v1] dir.c: don't flag the index as dirty for changes to the untracked cache

Jeff King writes: > A minor nit, but please use something like: > > if (git_env_bool("GIT_TEST_UNTRACKED_CACHE", 0) && ... > > so that: > > GIT_TEST_UNTRACKED_CACHE=false > > does what one might expect, and not the opposite. > > Two other thoughts: > > - it may be worth

Re: [PATCH] hooks/pre-auto-gc-battery: allow gc to run on non-laptops

On Wed, Feb 28, 2018 at 10:16:21AM -0800, Junio C Hamano wrote: > Adam Borowski writes: > > > Desktops and servers tend to have no power sensor, thus on_ac_power returns > > 255 ("unknown"). > > > > If that tool returns "unknown", there's no point in querying other sources >

Re: [GSoC][PATCH] userdiff: add built-in pattern for golang

On Wed, Feb 28, 2018 at 4:31 PM, Alban Gruin wrote: >>> diff --git a/userdiff.c b/userdiff.c >>> @@ -38,6 +38,15 @@ IPATTERN("fortran", >>> +PATTERNS("golang", >>> +/* Functions */ >>> +"^[ \t]*(func[ \t]*.*(\\{[ \t]*)?)\n" >> >> Why is the brace (and

[PATCH v2] commit: run git gc --auto just before the pre-commit hook

Change the behavior of git-commit back to what it was back in d4bb43ee27 ("Invoke "git gc --auto" from commit, merge, am and rebase.", 2007-09-05) when it was git-commit.sh. Shortly afterwards in f5bbc3225c ("Port git commit to C.", 2007-11-08) when it was ported to C, the "git gc --auto"

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Igor Djordjevic writes: [...] >> > Hmm, still rushing it, but what about adding an additional step, >> > something like this: >> >> I think it's unneeded, as it should work fine without it, see another >> reply. > > Unfortunately, I have a broken test case saying

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Igor, Igor Djordjevic writes: > Hi Sergey, > > On 28/02/2018 06:19, Sergey Organov wrote: >> >> > > (3) ---X1---o---o---o---o---o---X2 >> > >|\ |\ >> > >| A1---A2---A3---U1 | A1'--A2'--A3'--U1' >> > >|

Re: The case for two trees in a commit ("How to make rebase less modal")

On 28/02/18 23:30, Stefan Beller wrote: > $ git hash-object --stdin -w -t commit < tree c70b4a33a0089f15eb3b38092832388d75293e86 > parent 105d5b91138ced892765a84e771a061ede8d63b8 > author Stefan Beller 1519859216 -0800 > committer Stefan Beller

Re: [PATCH v2 0/5] roll back locks in various code paths

On 1 March 2018 at 00:20, Junio C Hamano wrote: > Martin Ågren writes: > >> A further upshot of this patch is that `active_cache_changed`, which is >> defined as `the_index.cache_changed`, now only has a few users left. > > I am undecided if this is a

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Igor, Igor Djordjevic writes: > On 28/02/2018 21:25, Igor Djordjevic wrote: >> >> But U1' and U2' are really to be expected to stay the same in >> non-interactive rebase case only... > > Just to rephrase to "could be expected" here, meaning still not >

  1   2   >