Re: [RFC 0/7] transitioning to protocol v2

Brandon Williams writes: > The best way to preserve functionality with old servers and clients would be > to > communicate using the same end point but have the client send a bit of extra > information with its initial request. This extra information would need to be > sent

Agent In (USA/Canada) Needed

-- Shougang Group 45 Huagong Road Xinji City, Hebei Province China. webpage: www.shougang.com.cn This is an official request for Professional/consultants who will stand as our regional representative to run logistics on behalf of Shougang Group. We are only looking for individual or company

[RFC 4/7] t: fix ssh tests to cope with using '-o SendEnv=GIT_PROTOCOL'

Update some of our tests to cope with ssh being launched with the option to send the protocol version. Signed-off-by: Brandon Williams --- t/lib-proto-disable.sh | 1 + t/t5601-clone.sh | 10 +- t/t5602-clone-remote-exec.sh | 4 ++-- 3 files

[RFC 5/7] http: send Git-Protocol-Version header

Tell a serve that protocol v2 can be used by sending an http header indicating this. Signed-off-by: Brandon Williams --- http.c | 7 +++ t/t5551-http-fetch-smart.sh | 2 ++ 2 files changed, 9 insertions(+) diff --git a/http.c b/http.c index

[RFC 2/7] pkt-line: add strbuf_packet_read

Add function which can be used to read the contents of a single pkt-line into a strbuf. Signed-off-by: Brandon Williams --- pkt-line.c | 21 + pkt-line.h | 1 + 2 files changed, 22 insertions(+) diff --git a/pkt-line.c b/pkt-line.c index

[RFC 6/7] transport: teach client to recognize v2 server response

Teach a client to recognize that a server understand protocol v2 by looking at the first pkt-line the server sends in response. This is done by looking for the response "version 2" sent by upload-pack. Signed-off-by: Brandon Williams --- builtin/fetch-pack.c | 4 +-

[RFC 1/7] 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 strbuf before writing the packet. Signed-off-by: Brandon Williams --- pkt-line.c | 6 ++ pkt-line.h | 1 + 2 files changed, 7 insertions(+) diff --git

[RFC 7/7] upload-pack: ack version 2

Signed-off-by: Brandon Williams --- upload-pack.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/upload-pack.c b/upload-pack.c index 7efff2fbf..0f853152f 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -1032,9 +1032,15 @@ static int upload_pack_config(const

[RFC 3/7] protocol: tell server that the client understands v2

Teach the connection logic to tell a serve that it understands protocol v2. 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:

[RFC 0/7] transitioning to protocol v2

Another version of Git's wire protocol is a topic that has been discussed and attempted by many in the community over the years. The biggest challenge, as far as I understand, has been coming up with a transition plan to using the new server without breaking existing clients and servers. As such

Re: [PATCH v4 08/16] revision.c: use refs_for_each*() instead of for_each_*_submodule()

Nguyễn Thái Ngọc Duy writes: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- So... the idea is that the caller gives a ref-store and tells these functions to iterate over refs in it, and the existing submodule related callers can prepare a ref-store for the

Re: [PATCH v4 07/16] refs: add refs_head_ref()

Nguyễn Thái Ngọc Duy writes: ... which does what? Unlike refs_for_each_ref() and friends, this does not iterate. It just uses the same function signature to make a single call of fn on the "HEAD" ref. Did I capture what it does right? Thanks.

Re: [RFC 0/3] imap-send curl tunnelling support

On Thu, 24 Aug 2017, Jeff King wrote: Oh good. While I have you here, have you given any thought to a curl handle that has two half-duplex file descriptors, rather than a single full-duplex socket? That would let us tunnel over pipes rather than worrying about the portability of socketpair().

Re: [RFC PATCH 1/2] send-email: fix garbage removal after address

Matthieu Moy writes: > This is a followup over 9d33439 (send-email: only allow one address > per body tag, 2017-02-20). The first iteration did allow writting > > Cc: # garbage > > but did so by matching the regex ([^>]*>?), i.e. stop after the first >

Re: [Patch size_t V3 11/19] Use size_t for config parsing

Am 16.08.2017 um 22:16 schrieb Martin Koegler: > +int git_parse_size_t(const char *value, size_t *ret) > +{ > + uintmax_t tmp; > + if (!git_parse_unsigned(value, , > maximum_signed_value_of_type(size_t))) > + return 0; > + *ret = tmp; > + return 1; > +} > + I think

Re: [PATCH v2/RFC] commit: change the meaning of an empty commit message

Kaartic Sivaraam writes: > As has been noted by Junio, > > "It would be a backward incompatible tightening of the established > rule, but it may not be a bad change." > > The "It" above refers to this change. Expecting comments from people to >

Re: [PATCH 0/1] Add stash entry count summary to short status output

Sonny Michaud writes: > diff --git a/wt-status.c b/wt-status.c > > index 77c27c511..651bb01f0 100644 > > --- a/wt-status.c

RE: TREAT URGENT !

Hello. I am Dr. Mallon Liam, an Engineer with ExxonMobil in United Kingdom http://www.exxonmobil.co.uk). I got your contact address from an associate working with the British Export Promotion Council. Before I continue, let me stress that I am NOT contacting you for financial assistance. I am

[GSoC][PATCH v3 4/4] submodule: port submodule subcommand 'status' from shell to C

This aims to make git-submodule 'status' a built-in. Hence, the function cmd_status() is ported from shell to C. This is done by introducing three functions: module_status(), submodule_status() and print_status(). The function module_status() acts as the front-end of the subcommand. It parses

[GSoC][PATCH v3 2/4] submodule--helper: introduce for_each_listed_submodule()

Introduce function for_each_listed_submodule() and replace a loop in module_init() with a call to it. The new function will also be used in other parts of the system in later patches. Mentored-by: Christian Couder Mentored-by: Stefan Beller

[GSoC][PATCH v3 3/4] submodule: port set_name_rev() from shell to C

Function set_name_rev() is ported from git-submodule to the submodule--helper builtin. The function compute_rev_name() generates the value of the revision name as required. The function get_rev_name() calls compute_rev_name() and receives the revision name, and later handles its formating and

[GSoC][PATCH v3 1/4] submodule--helper: introduce get_submodule_displaypath()

Introduce function get_submodule_displaypath() to replace the code occurring in submodule_init() for generating displaypath of the submodule with a call to it. This new function will also be used in other parts of the system in later patches. Mentored-by: Christian Couder

[GSoC][PATCH v3 0/4] Incremental rewrite of git-submodules

Changes in v3: * The name of the iterator function for_each_submodule() was changed to the for_each_listed_submodule(), as the function fits the naming pattern for_each_Y_X(), as here we iterate over group of listed submodules (X) which are listed (Y) by the function module_list_compute() *

Re: [PATCH v1] convert: display progress for filtered objects that have been delayed

Lars Schneider writes: > In 2841e8f ("convert: add "status=delayed" to filter process protocol", > 2017-06-30) we taught the filter process protocol to delayed responses. > These responses are processed after the "Checking out files" phase. > If the processing takes

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

Lars Schneider writes: > On 22 Aug 2017, at 21:56, Junio C Hamano wrote: > >> Here are the topics that have been cooking. Commits prefixed with >> '-' are only in 'pu' (proposed updates) while commits prefixed with >> '+' are in 'next'. The ones

Re: [PATCH 0/1] Add stash entry count summary to short status output

Sonny Michaud writes: > On 08/22/2017 11:25 AM, Sonny Michaud wrote: >> I am just bumping this thread; I presume there is something amiss >> with my submissions, so if someone can let me know how to fix any >> issues, I will gladly re-submit the patch. >> >> Thanks! >>

Re: [PATCH v2 3/4] strbuf_setlen: don't write to strbuf_slopbuf

On 24 August 2017 at 20:29, Brandon Casey wrote: > On Thu, Aug 24, 2017 at 9:52 AM, Junio C Hamano wrote: >> Brandon Casey writes: >> >>> Ah, you probably meant something like this: >>> >>>const char strbuf_slopbuf = '\0'; >>> >>>

Re: [PATCH] Doc: clarify that pack-objects makes packs, plural

Jeff King writes: > On Thu, Aug 24, 2017 at 12:27:52AM -0700, Jacob Keller wrote: > >> > For the sneaker-net case, you are much better off generating a single >> > pack and then using "split" and "cat" to reconstruct it on the other end >> > Not that I think we should go into such

Re: [PATCH] Fix branch renaming not updating HEADs correctly

On 24.08.2017 [17:41:24 +0700], Nguyễn Thái Ngọc Duy wrote: > There are two bugs that sort of work together and cause problems. Let's > start with one in replace_each_worktree_head_symref. > Correct add_head_info(), remove RESOLVE_REF_READING flag. With the flag > gone, we should always return

Re: [PATCH/RFC] push: anonymize URL in error output

On 23/08/17 18:58, Jeff King wrote: > On Wed, Aug 23, 2017 at 12:49:29PM +0300, Ivan Vyshnevskyi wrote: > >> Commits 47abd85 (fetch: Strip usernames from url's before storing them, >> 2009-04-17) and later 882d49c (push: anonymize URL in status output, >> 2016-07-14) made fetch and push strip the

Re: [PATCH/RFC] push: anonymize URL in error output

On 23/08/17 13:57, Lars Schneider wrote: > >> On 23 Aug 2017, at 11:49, Ivan Vyshnevskyi wrote: >> >> Commits 47abd85 (fetch: Strip usernames from url's before storing them, >> 2009-04-17) and later 882d49c (push: anonymize URL in status output, >> 2016-07-14) made fetch and

Re: [PATCH v3 2/4] imap-send: add wrapper to get server credentials if needed

Nicolas Morey-Chaisemartin writes: > Le 23/08/2017 à 22:13, Junio C Hamano a écrit : >> Nicolas Morey-Chaisemartin writes: >> >>> Signed-off-by: Nicolas Morey-Chaisemartin >>> --- >>> imap-send.c |

What's cooking in git.git (Aug 2017, #06; Thu, 24)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. As I am preparing to go offline

Re: [PATCH v2 3/4] strbuf_setlen: don't write to strbuf_slopbuf

On Thu, Aug 24, 2017 at 9:52 AM, Junio C Hamano wrote: > Brandon Casey writes: > >> Ah, you probably meant something like this: >> >>const char strbuf_slopbuf = '\0'; >> >> which gcc will apparently place in the read-only segment. I did not know >>

Re: [PATCH v2 3/4] strbuf_setlen: don't write to strbuf_slopbuf

Brandon Casey writes: > Ah, you probably meant something like this: > >const char strbuf_slopbuf = '\0'; > > which gcc will apparently place in the read-only segment. I did not know > that. Yes but I highly suspect that it would be very compiler dependent and not

Re: [RFC PATCH 0/5] Add option to autostage changes when continuing a rebase

Phillip Wood writes: > It could be expensive to check that the local modifications will not > interfere with the rebase - wouldn't it have to look at all the files > touched by each commit before starting? What do cherry-pick and am do > here when picking several

Re: What does 'git blame --before -- ' supposed to mean?

Kevin Daudt writes: > Git blame takes options that are fed to git rev-list, to limit the > commits being taken into account for blaming. > > The man page shows "[--since=]", which is one such option, but > before is valid as well. > > git blame -h shows: > > are documented

Re: [RFC PATCH 0/7] Implement ref namespaces as a ref storage backend

On Sun, Aug 13, 2017 at 9:36 PM, Richard Maw wrote: > Forewarning: I don't consider this work complete > and am unlikely to find time to finish it any time soon. > I've mostly sent this because it may include valuable feedback > on how well the ref storage backends works >

Re: [PATCH 0/1] Add stash entry count summary to short status output

On 08/22/2017 11:25 AM, Sonny Michaud wrote: I am just bumping this thread; I presume there is something amiss with my submissions, so if someone can let me know how to fix any issues, I will gladly re-submit the patch. Thanks! - Sonny Bumping again for visibility.

Re: [PATCH] Retry acquiring reference locks for 100ms

On Mon, Aug 21, 2017 at 01:51:34PM +0200, Michael Haggerty wrote: > The philosophy of reference locking has been, "if another process is > changing a reference, then whatever I'm trying to do to it will > probably fail anyway because my old-SHA-1 value is probably no longer > current". But this

Re: [RFC 0/3] imap-send curl tunnelling support

On Thu, Aug 24, 2017 at 04:02:19PM +0200, Daniel Stenberg wrote: > On Thu, 24 Aug 2017, Jeff King wrote: > > > > I opened a bug upstream and they already fixed this. > > > https://github.com/curl/curl/pull/1820 > > > > Cool! That's much faster than I had expected. :) > > Your wish is our

Re: [RFC 0/3] imap-send curl tunnelling support

On Thu, Aug 24, 2017 at 04:15:04PM +0200, Nicolas Morey-Chaisemartin wrote: > >> 1) There does not seem to be an easy/clean workaround for the lack of > >> socketpair on windows. > >> Fidling with a loopback AF_UNIX?AF_LOCAL socket should work but it > >> means creating a socket file somewhere

Re: splitting off shell test framework

On Thu, Aug 24, 2017 at 12:23:05AM +0100, Adam Spiers wrote: > > [1] I actually keep a local archive and convert public-inbox URLs into > > local requests that I view in mutt. > > Sounds like a neat trick - any scripts / config worth sharing? It's probably too specific to my setup, but here

Re: [RFC 0/3] imap-send curl tunnelling support

Le 24/08/2017 à 15:53, Jeff King a écrit : > On Thu, Aug 24, 2017 at 10:00:47AM +0200, Nicolas Morey-Chaisemartin wrote: > >>> Yes, I agree. I was hoping when we started this discussion that we were >>> more ready to switch to curl-by-default. But sadly, that isn't close to >>> being the case.

Re: [PATCH v4 12/16] files-backend: make reflog iterator go through per-worktree reflog

On Wed, Aug 23, 2017 at 07:37:00PM +0700, Nguyễn Thái Ngọc Duy wrote: > refs/bisect is unfortunately per-worktree, so we need to look in > per-worktree logs/refs/bisect in addition to per-repo logs/refs. The > current iterator only goes through per-repo logs/refs. > > Use merge iterator to walk

Re: [RFC 0/3] imap-send curl tunnelling support

On Thu, 24 Aug 2017, Jeff King wrote: I opened a bug upstream and they already fixed this. https://github.com/curl/curl/pull/1820 Cool! That's much faster than I had expected. :) Your wish is our command! =) -- / daniel.haxx.se (who landed the IMAP PREAUTH fix in curl)

Re: [RFC 0/3] imap-send curl tunnelling support

On Thu, Aug 24, 2017 at 10:00:47AM +0200, Nicolas Morey-Chaisemartin wrote: > > Yes, I agree. I was hoping when we started this discussion that we were > > more ready to switch to curl-by-default. But sadly, that isn't close to > > being the case. But hopefully we can at least end up with logic

Re: [PATCH] Doc: clarify that pack-objects makes packs, plural

On Thu, Aug 24, 2017 at 12:27:52AM -0700, Jacob Keller wrote: > > For the sneaker-net case, you are much better off generating a single > > pack and then using "split" and "cat" to reconstruct it on the other end > > Not that I think we should go into such detail in the manpage, but I > > have to

Re: [BUG] rebase -i with only empty commits

On 23/08/17 15:40, Johannes Schindelin wrote: > > These days, I reflexively type `rebase -ki` instead of `rebase -i`. Maybe > you want to do that, too? > > Ciao, > Dscho > This is slightly off topic but when I was preparing the patches for [1] I noticed a couple of potential bugs with rebase

Re: [RFC PATCH 0/5] Add option to autostage changes when continuing a rebase

On 22/08/17 16:54, Junio C Hamano wrote: > Phillip Wood writes: > >>> In other words, instead of >>> >>> git add -u && git rebase --continue >>> >>> you would want a quicker way to say >>> >>> git rebase --continue $something_here >> >> Exactly >> ... >>

[PATCH] Fix branch renaming not updating HEADs correctly

There are two bugs that sort of work together and cause problems. Let's start with one in replace_each_worktree_head_symref. Before fa099d2322 (worktree.c: kill parse_ref() in favor of refs_resolve_ref_unsafe() - 2017-04-24), this code looks like this: if (strcmp(oldref,

Re: [RFC PATCH 0/7] Implement ref namespaces as a ref storage backend

On Tue, Aug 15, 2017 at 10:13:22AM -0700, Junio C Hamano wrote: > Richard Maw writes: > > > This is not my first attempt to improve the git namespace handling in git. > > I tried last year, but it took me so long that all the ref handling code > > changed > > and I would

Re: sequencer status

Le 24/08/2017 à 11:43, Matthieu Moy a écrit : > Christian Couder writes: > >> It is displaying the steps that have already been performed, right? >> I wonder if people might want more about the current step (but maybe >> that belongs to `git status`) or perhaps the

Re: sequencer status

Christian Couder writes: > It is displaying the steps that have already been performed, right? > I wonder if people might want more about the current step (but maybe > that belongs to `git status`) or perhaps the not yet performed states > (and maybe even a way to

Re: [PATCH 2/2] treewide: correct several "up-to-date" to "up to date"

On 24 August 2017 at 05:51, STEVEN WHITE wrote: > On Wed, Aug 23, 2017 at 10:49 AM, Martin Ågren wrote: >> Follow the Oxford style, which says to use "up-to-date" before the noun, >> but "up to date" after it. Don't change plumbing

Problems in Default merge message

Hi! I'd like to report an old-time bug in git, regarding the default message visible for a "git merge --no-commit" (at the later commit, of course): * When merging a branch, the first name is put in single quotes, while the second is not. * There is no blank line after the first one * there

Re: Undocumented change in `git branch -M` behavior

On Thu, Aug 24, 2017 at 3:13 AM, Nish Aravamudan wrote: > Hello, > > Hopefully, I've got this right -- I noticed a change in behavior in git > with Ubuntu 17.10, which recently got 2.14.1. Specifically, that when in > an orphaned branch, -M ends up moving HEAD to

Re: sequencer status

Le 23/08/2017 à 19:57, Junio C Hamano a écrit : > Nicolas Morey-Chaisemartin writes: > >> Two questions: >> - Could this be a candidate for contrib/ ? >> - Would it be interesting to add the relevant code to sequencer.c >> so that all sequencer based commands

Re: [git-for-windows] Re: Revision resolution for remote-helpers?

On Tue, Aug 22, 2017 at 10:15:20PM +0200, Johannes Schindelin wrote: > Hi, > > On Fri, 18 Aug 2017, Jonathan Nieder wrote: > > > Mike Hommey wrote[1]: > > > On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote: > > >> Mike Hommey wrote: > > > > >>> The reason for the :: prefix is

Re: sequencer status

Le 23/08/2017 à 18:40, Christian Couder a écrit : > Hi, > > On Wed, Aug 23, 2017 at 10:10 AM, Nicolas Morey-Chaisemartin > wrote: >> Hi, >> >> I've created a small tool to display the current sequencer status. >> It mimics what Magit does to display what was done

Re: What does 'git blame --before -- ' supposed to mean?

On Mon, Aug 21, 2017 at 12:15:59AM +0530, Kaartic Sivaraam wrote: > Hello all, > > I tried to do a 'git blame' on a file and wanted to see the blame > before a particular revision of that file. I initially didn't know that > you could achieve that with, > > $ git blame > > I thought I

[RFC 0/3] imap-send curl tunnelling support

Le 23/08/2017 à 23:43, Jeff King a écrit : > On Mon, Aug 21, 2017 at 09:34:19AM +0200, Nicolas Morey-Chaisemartin wrote: > It appears curl do not support the PREAUTH tag. >>> Too bad. IMHO preauth is the main reason to use a tunnel in the first >>> place. >> It shouldn't be too hard to add

Re: [PATCH] Doc: clarify that pack-objects makes packs, plural

On Wed, Aug 23, 2017 at 2:22 PM, Jeff King wrote: > On Tue, Aug 22, 2017 at 12:56:25PM -0700, Junio C Hamano wrote: > >> - There should be an update to say max-pack-size is not something >>normal users would ever want. > > Agreed. > >> diff --git

Re: [PATCH v3 4/4] imap-send: use curl by default

Le 23/08/2017 à 22:28, Junio C Hamano a écrit : > Nicolas Morey-Chaisemartin writes: > >> Now that curl is enable by default, > s/enable//; > > But it is unclear what the above really means. You certainly do not > mean that [PATCH 1-3/4] somewhere tweaked our

Re: [PATCH v3 1/4] imap-send: return with error if curl failed

Le 23/08/2017 à 22:12, Junio C Hamano a écrit : > Nicolas Morey-Chaisemartin writes: > >> curl_append_msgs_to_imap always returned 0, whether curl failed or not. >> Return a proper status so git imap-send will exit with an error code >> if womething wrong

Re: [PATCH] Retry acquiring reference locks for 100ms

On Wed, Aug 23, 2017 at 11:55 PM, Junio C Hamano wrote: > Michael Haggerty writes: > >> The philosophy of reference locking has been, "if another process is >> changing a reference, then whatever I'm trying to do to it will >> probably fail anyway because

Re: [PATCH v3 2/4] imap-send: add wrapper to get server credentials if needed

Le 23/08/2017 à 22:13, Junio C Hamano a écrit : > Nicolas Morey-Chaisemartin writes: > >> Signed-off-by: Nicolas Morey-Chaisemartin >> --- >> imap-send.c | 34 -- >> 1 file changed, 20