Re: git-scm.com status report

In theory, you could also dump the build artifacts to a GH Pages repo and host it from there, although I don't know if you would run up against any of the usage limits[0]. The immediate problem I see with that approach, though, is that I have no idea how any of the dynamic stuff (e.g. search)

Re: git-scm.com status report

Jeff King wrote: > With the caveat that I know very little about web hosting, $230/mo > sounds like an awful lot for what is essentially a static web site. Yes, that's a lot. Fwiw, that covers a year of low-end VPS hosting for the main public-inbox.org/git machine + mail host

init --separate-git-dir does not set core.worktree

Hello, As of 6311cfaf9 (init: do not set unnecessary core.worktree, 2016-09-25), "git init --separate-git-dir" no longer sets core.worktree (test below). Based on the commit message and the corresponding thread [1], I don't think this change in behavior was intentional, but I wasn't able to

Git / Software Freedom Conservancy status report

Since it's been about a year since the last one, I'd like to give a brief overview of the activities of Git as a member project of the Software Freedom Conservancy. I plan to have a discussion session at the Git Merge Contributor Summit tomorrow; I'll try to relay any interesting points from that

git-scm.com status report

We (the Git project) got control of the git-scm.com domain this year. We have never really had an "official" website, but I think a lot of people consider this to be one. This is an overview of the current state, as well as some possible issues and future work. ## What's on the site We have the

Git trademark status and policy

As many of you already know, the Git project (as a member of Software Freedom Conservancy) holds a trademark on "Git". This email will try to lay out a bit of the history and procedure around the enforcement of that trademark, along with some open questions about policy. I'll use "we" in the

Re: [PATCH v2 7/7] completion: recognize more long-options

On Wed, Feb 1, 2017 at 5:49 PM, Cornelius Weig wrote: > Hi Gabor, > > thanks for taking a look at these commits. > > On 01/31/2017 11:17 PM, SZEDER Gábor wrote: >> On Fri, Jan 27, 2017 at 10:17 PM, wrote: >>> From: Cornelius Weig

Re: [PATCH 4/7] completion: teach ls-remote to complete options

> ls-remote needs to complete remote names and its own options. And refnames, too. > In > addition to the existing remote name completions, do also complete > the options --heads, --tags, --refs, and --get-url. Why only these four options and not the other four? There are eight options in

Re: [PATCH 6/7] completion: teach remote subcommands option completion

> Git-remote needs to complete remote names, its subcommands, and options > thereof. In addition to the existing subcommand and remote name > completion, do also complete the options > > - add: --track --master --fetch --tags --no-tags --mirror= Oh, '--track' and '--master' are not even in the

Re: [PATCH 2/7] completion: add subcommand completion for rerere

> Managing recorded resolutions requires command-line usage of git-rerere. > Added subcommand completion for rerere and path completion for its > subcommand forget. > --- > contrib/completion/git-completion.bash | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git

Re: git commit results in many lstat()s

On Thu, Feb 02, 2017 at 12:14:30AM +, Gumbel, Matthew K wrote: > I'm testing such a change locally. Git test suite seems to be running for > quite > a while. Do you know any way to run it in parallel or otherwise speed it > up? I usually do something like the following: make -j3 all &&

RE: git commit results in many lstat()s

"Junio C Hamano writes: "Gumbel, Matthew K" writes: >> Yes, I think that when the user passes --only flag to git-commit, then git >> does not >> need to call refresh_cache() in prepare_index() in builtin/commit.c. >> >> I may experiment

Re: [PATCH] doc: add note about ignoring --no-create-reflog

Jeff King writes: > On Wed, Feb 01, 2017 at 03:27:09PM -0800, Junio C Hamano wrote: > >> I had the same trouble wording. Another thing I noticed was that I >> deliberately left it vague what "default" this does not override, >> because it appears to me that those who do not set

Re: git commit results in many lstat()s

"Gumbel, Matthew K" writes: > "Junio C Hamano" writes: >> There probably are other things that can be optimized. > > Yes, I think that when the user passes --only flag to git-commit, then git > does not > need to call refresh_cache() in

Re: [PATCH] doc: add note about ignoring --no-create-reflog

On Wed, Feb 01, 2017 at 03:27:09PM -0800, Junio C Hamano wrote: > I had the same trouble wording. Another thing I noticed was that I > deliberately left it vague what "default" this does not override, > because it appears to me that those who do not set logallrefupdates > will get the

Re: [PATCH] merge-recursive: make "CONFLICT (rename/delete)" message show both paths

Matt McCutchen writes: > On Wed, 2017-02-01 at 12:56 -0800, Junio C Hamano wrote: > >> Let me make sure if I understood your changes correctly: >> ... >> So the condition to guard the call to update_file() also looks >> correct to me. > > All of the above matches my

Re: [PATCH] doc: add note about ignoring --no-create-reflog

Jeff King writes: > Should this perhaps say "currently" or "this may change in the future", > so that people (including those who might want to fix it later) know > that it's a limitation and not intentional? Good point. > I'd also probably say it a little shorter, like: > >

Re: [PATCH] merge-recursive: make "CONFLICT (rename/delete)" message show both paths

On Wed, 2017-02-01 at 12:56 -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > > Matt McCutchen writes: > > ... > > > Please check that my refactoring is indeed correct!  All the > > > existing tests pass > > > for me, but the existing test

Re: [PATCH] doc: add note about ignoring --no-create-reflog

> The negated form `--no-create-reflog` only overrides an earlier > `--create-reflog`, but currently does not negate the setting of > `core.logallrefupdates`. Even better than Junio's version. I especially like that it mentions where the default setting comes from.

Re: [PATCH] doc: add note about ignoring --no-create-reflog

On 02/02/2017 12:11 AM, Junio C Hamano wrote: > Jeff King writes: > >> This might be nitpicking, but it's _not_ ignored. It still negates an >> earlier "--create-reflog". It is only that it does not override the >> decision to create a reflog caused by the setting of >>

Re: [PATCH] doc: add note about ignoring --no-create-reflog

On Wed, Feb 01, 2017 at 03:11:57PM -0800, Junio C Hamano wrote: > diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt > index 5516a47b54..102e426fd8 100644 > --- a/Documentation/git-branch.txt > +++ b/Documentation/git-branch.txt > @@ -91,6 +91,9 @@ OPTIONS > based sha1

Re: [PATCH 1/2] doc: add doc for git-push --recurse-submodules=only

cornelius.w...@tngtech.com writes: > From: Cornelius Weig > > Add documentation for the `--recurse-submodules=only` option of > git-push. The feature was added in commit 225e8bf (add option to > push only submodules). > > Signed-off-by: Cornelius Weig

Re: [PATCH] doc: add note about ignoring --no-create-reflog

Jeff King writes: > This might be nitpicking, but it's _not_ ignored. It still negates an > earlier "--create-reflog". It is only that it does not override the > decision to create a reflog caused by the setting of > core.logallrefupdates. OK, rolling them all into one, how about

[PATCH 1/2] doc: add doc for git-push --recurse-submodules=only

From: Cornelius Weig Add documentation for the `--recurse-submodules=only` option of git-push. The feature was added in commit 225e8bf (add option to push only submodules). Signed-off-by: Cornelius Weig --- Notes: This feature is

[PATCH 2/2] completion: add completion for --recurse-submodules=only

From: Cornelius Weig Command completion for 'git-push --recurse-submodules' already knows to complete some modes. However, the recently added mode 'only' is missing. Adding 'only' to the recognized modes completes the list of non-trivial modes. Signed-off-by:

Re: [PATCH v3 4/4] connect: Add the envvar GIT_SSH_VARIANT and ssh.variant config

Hi Junio, On Wed, 1 Feb 2017, Junio C Hamano wrote: > Junio C Hamano writes: > > > Johannes Schindelin writes: > > > >> That leaves the "putty" case in handle_ssh_variant(), does it not? Was it > >> not your specific objection that that is the

Re: [PATCH v3 0/4] Handle PuTTY (plink/tortoiseplink) even in GIT_SSH_COMMAND

Johannes Schindelin writes: >> Compared to the correctness issue, these are much harder to spot by >> the submitter alone, who focused so intensely to get his code >> "correct". The review process is of greater value to spot these >> issues. > > We will never agree

Re: [PATCH v3 4/4] connect: Add the envvar GIT_SSH_VARIANT and ssh.variant config

Junio C Hamano writes: > Johannes Schindelin writes: > >> That leaves the "putty" case in handle_ssh_variant(), does it not? Was it >> not your specific objection that that is the case? > > Yup, you can remove that while you reroll. > >> No

Re: [PATCH v3 4/4] connect: Add the envvar GIT_SSH_VARIANT and ssh.variant config

Hi Junio, On Wed, 1 Feb 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > That leaves the "putty" case in handle_ssh_variant(), does it not? Was it > > not your specific objection that that is the case? > > Yup, you can remove that while you reroll. >

Re: [PATCH] doc: add note about ignoring --no-create-reflog

cornelius.w...@tngtech.com writes: > From: Cornelius Weig > > The commands git-branch and git-tag accept a `--create-reflog` argument. For the purpose of contrasting the above with "--no-create-reflog", I find it a bit too weak to just say "accept". How about

Re: [PATCH v3 4/4] connect: Add the envvar GIT_SSH_VARIANT and ssh.variant config

Johannes Schindelin writes: > That leaves the "putty" case in handle_ssh_variant(), does it not? Was it > not your specific objection that that is the case? Yup, you can remove that while you reroll. > No worries, I will let this simmer for a while. Your fixup has a

Re: [PATCH] doc: add note about ignoring --no-create-reflog

On Wed, Feb 01, 2017 at 02:30:38PM -0800, Junio C Hamano wrote: > > Notes: > > In a previous discussion > > () it > > was found that git-branch and git-tag accept a "--no-create-reflog" > > argument, > > but it has no effect, does not

RE: git commit results in many lstat()s

"Junio C Hamano" writes: > There probably are other things that can be optimized. Yes, I think that when the user passes --only flag to git-commit, then git does not need to call refresh_cache() in prepare_index() in builtin/commit.c. I may experiment with that. Do you see

Re: [PATCH v3 4/4] connect: Add the envvar GIT_SSH_VARIANT and ssh.variant config

Hi Junio, On Wed, 1 Feb 2017, Junio C Hamano wrote: > Junio C Hamano writes: > > > I think restructuring along the line of 3/4 of this round is very > > sensible in the longer term (if anything, handle_ssh_variant() now > > really handles ssh variants in all cases, which

Re: [PATCH v3 0/4] Handle PuTTY (plink/tortoiseplink) even in GIT_SSH_COMMAND

Hi Junio, On Wed, 1 Feb 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > It is quite preposterous to call this an "iteration" of the patch > > series, because the code is so different now. I say this because I want > > to caution that this code has

Re: git commit results in many lstat()s

"Gumbel, Matthew K" writes: > I do not understand why git commit must call lstat() on every file > in the repository, even when I specify the name of the file I want > to commit on the command line. Assuming the "COPYING" and "README.md" files are already tracked:

[PATCH] doc: add note about ignoring --no-create-reflog

From: Cornelius Weig The commands git-branch and git-tag accept a `--create-reflog` argument. On the other hand, the negated form `--no-create-reflog` is accepted as a valid option but has no effect. This silent noop may puzzle users. To communicate that this

git commit results in many lstat()s

Hello, My high level problem is to speed up git commit on a large repository stored on NFS filesystem. I see via strace that it is slow because it makes a large number (~50,000) of lstat() calls in serial. Every call is a round-trip to the NFS server. I do not understand why git commit must

Re: [ANNOUNCE] Git Merge Contributor Summit topic planning

Jeff King writes: > For instance, if the server knew that XYZ meant > > - send bytes m through n of packfile p, then... > > - send the object at position i of packfile p, as a delta against the > object at position j of packfile q > > - ...and so on > > Then you could

Re: [ANNOUNCE] Git Merge Contributor Summit topic planning

On Wed, Feb 01, 2017 at 10:06:15AM -0800, Junio C Hamano wrote: > > If you _can_ do that latter part, and you take "I only care about > > resumability" to the simplest extreme, you'd probably end up with a > > protocol more like: > > > > Client: I need a packfile with this want/have > >

Re: [PATCH] merge-recursive: make "CONFLICT (rename/delete)" message show both paths

Junio C Hamano writes: > Matt McCutchen writes: > ... >> Please check that my refactoring is indeed correct! All the existing tests >> pass >> for me, but the existing test coverage of these conflict messages looks poor. > > This unfortunately is

Re: [ANNOUNCE] Git Merge Contributor Summit topic planning

On Mon, Jan 30, 2017 at 4:48 PM, Jeff King wrote: > The Contributor Summit is only a few days away; I'd like to work out a > few bits of logistics ahead of time. > > We're up to 26 attendees. The room layout will probably be three big > round-tables, with a central projector. We

Re: [PATCH v3 0/4] Handle PuTTY (plink/tortoiseplink) even in GIT_SSH_COMMAND

Johannes Schindelin writes: > It is quite preposterous to call this an "iteration" of the patch > series, because the code is so different now. I say this because I want > to caution that this code has not been tested as thoroughly, by far, as > the first iteration. >

Re: [PATCH v3 4/4] connect: Add the envvar GIT_SSH_VARIANT and ssh.variant config

Junio C Hamano writes: > I think restructuring along the line of 3/4 of this round is very > sensible in the longer term (if anything, handle_ssh_variant() now > really handles ssh variants in all cases, which makes it worthy of > its name, as opposed to the one in the

Re: [ANNOUNCE] Git Merge Contributor Summit topic planning

On Tue, Jan 31, 2017 at 1:59 AM, Jeff King wrote: > On Tue, Jan 31, 2017 at 01:48:05AM +0100, Jeff King wrote: > >> The list of topics is totally open. If you're coming and have something >> you'd like to present or discuss, then propose it here. If you're _not_ >> coming, you may

Re: [PATCH v3 4/4] connect: Add the envvar GIT_SSH_VARIANT and ssh.variant config

Johannes Schindelin writes: > index 2734b9a1ca..7f1f802396 100644 > --- a/connect.c > +++ b/connect.c > @@ -694,10 +694,14 @@ static const char *get_ssh_command(void) > static int handle_ssh_variant(const char *ssh_command, int is_cmdline, >

Re: What's cooking in git.git (Jan 2017, #06; Tue, 31)

Patrick Steinhardt writes: > I just tried to write additional tests to exercise this in our > config-tests by using `git config --get-urlmatch` with multiple > `http.extraheader`s set. I've been stumped that it still didn't > work correctly with my patch, only the last value was

Re: [PATCH 1/5] add SWAP macro

René Scharfe writes: > Size checks could be added to SIMPLE_SWAP as well. Between SWAP() and SIMPLE_SWAP() I am undecided. If the compiler can infer the type and the size of the two "locations" given to the macro, there is no technical reason to require the caller to specify the

Re: [PATCH 1/5] add SWAP macro

Am 01.02.2017 um 12:47 schrieb Jeff King: I'm not altogether convinced that SWAP() is an improvement in readability. I really like that it's shorter than the code it replaces, but there is a danger with introducing opaque constructs. It's one more thing for somebody familiar with C but new to

Re: [ANNOUNCE] Git Merge Contributor Summit topic planning

Jeff King writes: > If you _can_ do that latter part, and you take "I only care about > resumability" to the simplest extreme, you'd probably end up with a > protocol more like: > > Client: I need a packfile with this want/have > Server: OK, here it is; its opaque id is XYZ. >

Re: [PATCH v2 3/3] connect: Add the envvar GIT_SSH_VARIANT and ssh.variant config

Johannes Schindelin writes: > On Fri, 27 Jan 2017, Junio C Hamano wrote: > >> IOW, I think it is acceptable to always split GIT_SSH_COMMAND into >> tokens before we realize that the user used the escape hatch and the >> splitting was a wasted effort. This is exactly

Re: [PATCH v2 7/7] completion: recognize more long-options

Hi Gabor, thanks for taking a look at these commits. On 01/31/2017 11:17 PM, SZEDER Gábor wrote: > On Fri, Jan 27, 2017 at 10:17 PM, wrote: >> From: Cornelius Weig >> >> Recognize several new long-options for bash completion in the

Re: [ANNOUNCE] Git Merge Contributor Summit topic planning

On Wed, Feb 01, 2017 at 10:32:12AM +0100, Erik van Zijst wrote: > Clients performing a full clone get redirected to a CDN where they seed > their new local repo from a pre-built bundle file, and then pull/fetch > any remaining changes. Mercurial has had native, built-in support for > this for a

[PATCH v3 3/4] git_connect(): factor out SSH variant handling

We handle plink and tortoiseplink as OpenSSH replacements, by passing the correct command-line options when detecting that they are used. To let users override that auto-detection (in case Git gets it wrong), we need to introduce new code to that end. In preparation for this code, let's factor

Re: [PATCH v2 3/3] connect: Add the envvar GIT_SSH_VARIANT and ssh.variant config

Hi Junio, On Fri, 27 Jan 2017, Junio C Hamano wrote: > IOW, I think it is acceptable to always split GIT_SSH_COMMAND into > tokens before we realize that the user used the escape hatch and the > splitting was a wasted effort. This is exactly because this thing > is an escape hatch that is

[PATCH v3 4/4] connect: Add the envvar GIT_SSH_VARIANT and ssh.variant config

From: Segev Finer This environment variable and configuration value allow to override the autodetection of plink/tortoiseplink in case that Git gets it wrong. [jes: wrapped overly-long lines, factored out and changed get_ssh_variant() to handle_ssh_variant() to accomodate

[PATCH v3 1/4] connect: handle putty/plink also in GIT_SSH_COMMAND

From: Segev Finer Git for Windows has special support for the popular SSH client PuTTY: when using PuTTY's non-interactive version ("plink.exe"), we use the -P option to specify the port rather than OpenSSH's -p option. TortoiseGit ships with its own, forked version of

[PATCH v3 2/4] connect: rename tortoiseplink and putty variables

From: Junio C Hamano One of these two may have originally been named after "what exact SSH implementation do we have" so that we can tweak the command line options, but these days "putty=1" no longer means "We are using the plink SSH implementation that comes with PuTTY". It

[PATCH v3 0/4] Handle PuTTY (plink/tortoiseplink) even in GIT_SSH_COMMAND

We already handle PuTTY's plink and TortoiseGit's tortoiseplink in GIT_SSH by automatically using the -P option to specify ports, and in tortoiseplink's case by passing the --batch option. For users who need to pass additional command-line options to plink, this poses a problem: the only way to

Re: [PATCH 1/5] add SWAP macro

On Wed, Feb 01, 2017 at 12:28:13PM +0100, Johannes Schindelin wrote: > > One funny thing is that your macro takes address-of itself, behind the > > scenes. I wonder if it would be more natural for it to take > > pointers-to-objects, making it look more like a real function (i.e., > > SWAP(, )

Re: [PATCH 1/5] add SWAP macro

Hi René, On Tue, 31 Jan 2017, René Scharfe wrote: > Am 31.01.2017 um 13:13 schrieb Johannes Schindelin: > > > #define SIMPLE_SWAP(T, a, b) do { T tmp_ = a; a = b; b = tmp_; } while (0) > > ... > > uint32_t large; > > char nybble; > > > > ... > > > > if (!(large & ~0xf)) { > >

Re: [PATCH 1/5] add SWAP macro

Hi Peff, On Tue, 31 Jan 2017, Jeff King wrote: > On Tue, Jan 31, 2017 at 10:03:01PM +0100, René Scharfe wrote: > > > > Perhaps we could disallow a side-effect operator in the macro. By > > > disallow I mean place a comment at the definition to the macro and > > > hopefully catch something like

Re: What's cooking in git.git (Jan 2017, #06; Tue, 31)

On Tue, Jan 31, 2017 at 02:45:40PM -0800, Junio C Hamano wrote: > * ps/urlmatch-wildcard (2017-01-31) 5 commits > . urlmatch: allow globbing for the URL host part > . urlmatch: include host in urlmatch ranking > . urlmatch: split host and port fields in `struct url_info` > . urlmatch: enable

Re: [ANNOUNCE] Git Merge Contributor Summit topic planning

On Tue, Jan 31, 2017 at 01:48:05AM +0100, Jeff King wrote: > The list of topics is totally open. If you're coming and have something > you'd like to present or discuss, then propose it here. If you're _not_ > coming, you may still chime in with input on topics, but please don't > suggest a topic