* Re: [PATCH v3 4/4] connect: Add the envvar GIT_SSH_VARIANT and ssh.variant config
From: Johannes Schindelin @ 2017-02-01 23:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Segev Finer, Jeff King
In-Reply-To: <xmqqvastmt09.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Wed, 1 Feb 2017, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> 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 lot of
> >> duplicated code (so much for maintainability as an important goal... ;-))
> >> and I will have to think about it. My immediate thinking is to *not*
> >> duplicate code,...
> >
> > You need to realize that the namespaces of the configuration and the
> > command names are distinct. There is no code duplication.
>
> To explain this a bit, there is no reason why allowed values for
> SSH_VARIANT must be "putty" and "tortoiseplink". An alternative
> design could be "port_option=-p,needs_batch=yes" and it may be more
> logical and futureproof if a variant of tortoiseplink decides to use
> "-p" instead of "-P" and still require "-batch".
>
> Prematurely attempting to share code, only because the current
> vocabularies for two distinct concepts happen to overlap, is not
> de-duplicating the code for maintainability. It is adding
> unnecessary work other people need to do in the future when they
> want to extend the system.
Except, of course, that your hypothetical port_option and needs_batch
settings would be handled at a different point altogether.
I sense very strongly that this discussion has taken a very emotional
turn, which is detrimental to the quality. So let's take a break here.
Ciao,
Johannes
^ permalink raw reply
* [PATCH 1/2] doc: add doc for git-push --recurse-submodules=only
From: cornelius.weig @ 2017-02-01 23:07 UTC (permalink / raw)
To: git; +Cc: bmwill, sbeller, Cornelius Weig
From: Cornelius Weig <cornelius.weig@tngtech.com>
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 <cornelius.weig@tngtech.com>
---
Notes:
This feature is already in 'next' but was undocumented. Unless somebody reads
the release notes, there is no way of knowing about it.
Documentation/git-push.txt | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 8eefabd..1624a35 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -272,7 +272,7 @@ origin +master` to force a push to the `master` branch). See the
standard error stream is not directed to a terminal.
--no-recurse-submodules::
---recurse-submodules=check|on-demand|no::
+--recurse-submodules=check|on-demand|only|no::
May be used to make sure all submodule commits used by the
revisions to be pushed are available on a remote-tracking branch.
If 'check' is used Git will verify that all submodule commits that
@@ -280,11 +280,12 @@ origin +master` to force a push to the `master` branch). See the
remote of the submodule. If any commits are missing the push will
be aborted and exit with non-zero status. If 'on-demand' is used
all submodules that changed in the revisions to be pushed will be
- pushed. If on-demand was not able to push all necessary revisions
- it will also be aborted and exit with non-zero status. A value of
- 'no' or using `--no-recurse-submodules` can be used to override the
- push.recurseSubmodules configuration variable when no submodule
- recursion is required.
+ pushed. If on-demand was not able to push all necessary revisions it will
+ also be aborted and exit with non-zero status. If 'only' is used all
+ submodules will be recursively pushed while the superproject is left
+ unpushed. A value of 'no' or using `--no-recurse-submodules` can be used
+ to override the push.recurseSubmodules configuration variable when no
+ submodule recursion is required.
--[no-]verify::
Toggle the pre-push hook (see linkgit:githooks[5]). The
--
2.10.2
^ permalink raw reply related
* [PATCH 2/2] completion: add completion for --recurse-submodules=only
From: cornelius.weig @ 2017-02-01 23:07 UTC (permalink / raw)
To: git; +Cc: bmwill, sbeller, Cornelius Weig
In-Reply-To: <20170201230753.19462-1-cornelius.weig@tngtech.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
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: Cornelius Weig <cornelius.weig@tngtech.com>
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index ff7072a..fe3b0f8 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1675,7 +1675,7 @@ _git_pull ()
__git_complete_remote_or_refspec
}
-__git_push_recurse_submodules="check on-demand"
+__git_push_recurse_submodules="check on-demand only"
__git_complete_force_with_lease ()
{
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] doc: add note about ignoring --no-create-reflog
From: Junio C Hamano @ 2017-02-01 23:11 UTC (permalink / raw)
To: Jeff King; +Cc: cornelius.weig, git
In-Reply-To: <20170201223520.b4er3av67ev5m3ls@sigill.intra.peff.net>
Jeff King <peff@peff.net> 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 this as an amend?
-- >8 --
From: Cornelius Weig <cornelius.weig@tngtech.com>
Date: Wed, 1 Feb 2017 23:07:27 +0100
Subject: [PATCH] doc: add note about ignoring '--no-create-reflog'
The commands git-branch and git-tag accept the '--create-reflog'
option, and create reflog even when core.logallrefupdates
configuration is explicitly set not to.
On the other hand, the negated form '--no-create-reflog' is accepted
as a valid option but has no effect (other than overriding an
earlier '--create-reflog' on the command line). This silent noop may
puzzle users. To communicate that this is a known limitation, add a
short note in the manuals for git-branch and git-tag.
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-branch.txt | 3 +++
Documentation/git-tag.txt | 3 +++
2 files changed, 6 insertions(+)
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 expressions such as "<branchname>@\{yesterday}".
Note that in non-bare repositories, reflogs are usually
enabled by default by the `core.logallrefupdates` config option.
+ The negated form `--no-create-reflog` does not override the
+ default, even though it overrides `--create-reflog` that appears
+ earlier on the command line.
-f::
--force::
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 2ac25a9bb3..fd7eeae075 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -152,6 +152,9 @@ This option is only applicable when listing tags without annotation lines.
--create-reflog::
Create a reflog for the tag. To globally enable reflogs for tags, see
`core.logAllRefUpdates` in linkgit:git-config[1].
+ The negated form `--no-create-reflog` does not override the
+ default, even though it overrides `--create-reflog` that appears
+ earlier on the command line.
<tagname>::
The name of the tag to create, delete, or describe.
--
2.11.0-800-g4bf73cb6b2
^ permalink raw reply related
* Re: [PATCH 1/2] doc: add doc for git-push --recurse-submodules=only
From: Junio C Hamano @ 2017-02-01 23:16 UTC (permalink / raw)
To: cornelius.weig; +Cc: git, bmwill, sbeller
In-Reply-To: <20170201230753.19462-1-cornelius.weig@tngtech.com>
cornelius.weig@tngtech.com writes:
> From: Cornelius Weig <cornelius.weig@tngtech.com>
>
> 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 <cornelius.weig@tngtech.com>
> ---
>
> Notes:
> This feature is already in 'next' but was undocumented. Unless somebody reads
> the release notes, there is no way of knowing about it.
Good eyes; the topic bw/push-submodule-only is already in 'master'.
Looks good to me; Brandon?
>
> Documentation/git-push.txt | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index 8eefabd..1624a35 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -272,7 +272,7 @@ origin +master` to force a push to the `master` branch). See the
> standard error stream is not directed to a terminal.
>
> --no-recurse-submodules::
> ---recurse-submodules=check|on-demand|no::
> +--recurse-submodules=check|on-demand|only|no::
> May be used to make sure all submodule commits used by the
> revisions to be pushed are available on a remote-tracking branch.
> If 'check' is used Git will verify that all submodule commits that
> @@ -280,11 +280,12 @@ origin +master` to force a push to the `master` branch). See the
> remote of the submodule. If any commits are missing the push will
> be aborted and exit with non-zero status. If 'on-demand' is used
> all submodules that changed in the revisions to be pushed will be
> - pushed. If on-demand was not able to push all necessary revisions
> - it will also be aborted and exit with non-zero status. A value of
> - 'no' or using `--no-recurse-submodules` can be used to override the
> - push.recurseSubmodules configuration variable when no submodule
> - recursion is required.
> + pushed. If on-demand was not able to push all necessary revisions it will
> + also be aborted and exit with non-zero status. If 'only' is used all
> + submodules will be recursively pushed while the superproject is left
> + unpushed. A value of 'no' or using `--no-recurse-submodules` can be used
> + to override the push.recurseSubmodules configuration variable when no
> + submodule recursion is required.
>
> --[no-]verify::
> Toggle the pre-push hook (see linkgit:githooks[5]). The
^ permalink raw reply
* Re: [PATCH] doc: add note about ignoring --no-create-reflog
From: Cornelius Weig @ 2017-02-01 23:19 UTC (permalink / raw)
To: Junio C Hamano, Jeff King; +Cc: git
In-Reply-To: <xmqqmve5mrpe.fsf@gitster.mtv.corp.google.com>
On 02/02/2017 12:11 AM, Junio C Hamano wrote:
> Jeff King <peff@peff.net> 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.
This corner case is quite important. Glad you thought about it!
> -- >8 --
> From: Cornelius Weig <cornelius.weig@tngtech.com>
> Date: Wed, 1 Feb 2017 23:07:27 +0100
> Subject: [PATCH] doc: add note about ignoring '--no-create-reflog'
>
> The commands git-branch and git-tag accept the '--create-reflog'
> option, and create reflog even when core.logallrefupdates
> configuration is explicitly set not to.
>
> On the other hand, the negated form '--no-create-reflog' is accepted
> as a valid option but has no effect (other than overriding an
> earlier '--create-reflog' on the command line). This silent noop may
> puzzle users. To communicate that this is a known limitation, add a
> short note in the manuals for git-branch and git-tag.
>
> Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> Documentation/git-branch.txt | 3 +++
> Documentation/git-tag.txt | 3 +++
> 2 files changed, 6 insertions(+)
>
> 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 expressions such as "<branchname>@\{yesterday}".
> Note that in non-bare repositories, reflogs are usually
> enabled by default by the `core.logallrefupdates` config option.
> + The negated form `--no-create-reflog` does not override the
> + default, even though it overrides `--create-reflog` that appears
> + earlier on the command line.
>
> -f::
> --force::
> diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
> index 2ac25a9bb3..fd7eeae075 100644
> --- a/Documentation/git-tag.txt
> +++ b/Documentation/git-tag.txt
> @@ -152,6 +152,9 @@ This option is only applicable when listing tags without annotation lines.
> --create-reflog::
> Create a reflog for the tag. To globally enable reflogs for tags, see
> `core.logAllRefUpdates` in linkgit:git-config[1].
> + The negated form `--no-create-reflog` does not override the
> + default, even though it overrides `--create-reflog` that appears
> + earlier on the command line.
>
> <tagname>::
> The name of the tag to create, delete, or describe.
>
Your amended version is quite concise and says everything there is to
say. Thanks
^ permalink raw reply
* Re: [PATCH] doc: add note about ignoring --no-create-reflog
From: Jeff King @ 2017-02-01 23:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: cornelius.weig, git
In-Reply-To: <xmqqmve5mrpe.fsf@gitster.mtv.corp.google.com>
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 expressions such as "<branchname>@\{yesterday}".
> Note that in non-bare repositories, reflogs are usually
> enabled by default by the `core.logallrefupdates` config option.
> + The negated form `--no-create-reflog` does not override the
> + default, even though it overrides `--create-reflog` that appears
> + earlier on the command line.
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?
I'd also probably say it a little shorter, like:
The negated form `--no-create-reflog` only overrides an earlier
`--create-reflog`, but currently does not negate the setting of
`core.logallrefupdates`.
I guess that really isn't much shorter (I wondered if you could cut out
the "overrides --create-reflog" part, since that is the normal and
expected behavior, but I had trouble wording it to do so).
-Peff
^ permalink raw reply
* Re: [PATCH] doc: add note about ignoring --no-create-reflog
From: Cornelius Weig @ 2017-02-01 23:23 UTC (permalink / raw)
To: Jeff King, Junio C Hamano; +Cc: git
In-Reply-To: <20170201231939.hxhhujpzyb2cqq7a@sigill.intra.peff.net>
> 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.
^ permalink raw reply
* Re: [PATCH] merge-recursive: make "CONFLICT (rename/delete)" message show both paths
From: Matt McCutchen @ 2017-02-01 23:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqh94dockc.fsf@gitster.mtv.corp.google.com>
On Wed, 2017-02-01 at 12:56 -0800, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Matt McCutchen <matt@mattmccutchen.net> 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 doing a bit too many things at once from that
> > point of view. I need to reserve a solid quiet 20-minutes without
> > distraction to check it, which I am hoping to do tonight.
>
> Let me make sure if I understood your changes correctly:
>
> * conflict_rename_delete() knew which one is renamed and which one
> is deleted (even though the deleted one was called "other"), but
> because in the original code handle_change_delete() wants to
> always see tree A first and then tree B in its parameter list,
> the original code swapped a/b before calling it. In the original
> code, handle_change_delete() needed to figure out which one is
> the deleted one by looking at a_oid or b_oid.
>
> * In the updated code, the knowledge of which branch survives and
> which branch is deleted is passed from the caller to
> handle_change_delete(), which no longer needs to figure out by
> looking at a_oid/b_oid. The updated API only passes the oid for
> surviving branch (as deleted one would have been 0{40} anyway).
>
> * In the updated code, handle_change_delete() is told the names of
> both branches (the one that survives and the other that was
> deleted). It no longer has to switch between o->branch[12]
> depending on the NULLness of a_oid/b_oid; it knows both names and
> which one is which.
>
> * handle_modify_delete() also calls handle_change_delete(). Unlike
> conflict_rename_delete(), it is not told by its caller which
> branch keeps the path and which branch deletes the path, and
> instead relies on handle_change_delete() to figure it out.
> Because of the above change to the API, now it needs to sort it
> out before calling handle_change_delete().
>
> It all makes sense to me.
>
> The single call to update_file() that appears near the end of
> handle_change_delete() in the updated code corresponds to calls to
> the same function in 3 among 4 codepaths in the function in the
> original code. It is a bit tricky to reason about, though.
>
> In the original code, update_file() was omitted when we didn't have
> to come up with a unique alternate filename and the one that is left
> is a_oid (i.e. our side). The way to tell if we did not come up
> with a unique alternate filename used to be to see the "renamed"
> variable but now it is the NULL-ness of "alt_path".
"alt_path" is the same variable that used to be "renamed". I just
renamed it to be less confusing.
> And the way to
> tell if the side that is left is ours, we check to see o->branch1
> is the change_branch, not delete_branch.
>
> So the condition to guard the call to update_file() also looks
> correct to me.
All of the above matches my understanding. Would it have saved you
time if I had included some of this explanation in the patch "cover
letter"?
Matt
^ permalink raw reply
* Re: [PATCH] doc: add note about ignoring --no-create-reflog
From: Junio C Hamano @ 2017-02-01 23:27 UTC (permalink / raw)
To: Jeff King; +Cc: cornelius.weig, git
In-Reply-To: <20170201231939.hxhhujpzyb2cqq7a@sigill.intra.peff.net>
Jeff King <peff@peff.net> 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:
>
> The negated form `--no-create-reflog` only overrides an earlier
> `--create-reflog`, but currently does not negate the setting of
> `core.logallrefupdates`.
>
> I guess that really isn't much shorter (I wondered if you could cut out
> the "overrides --create-reflog" part, since that is the normal and
> expected behavior, but I had trouble wording it to do so).
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 compiled-in default and that is also not overriden.
IOW, "does not negate the setting of core.logallrefupdates" will
open us to reports "I do not have the configuration set, but I still
get reflog even when --no-create-reflog is given".
The negated form `--no-create-reflog` currently does not negate
the default; it overrides an earlier `--create-reflog`, though.
perhaps?
^ permalink raw reply
* Re: [PATCH] merge-recursive: make "CONFLICT (rename/delete)" message show both paths
From: Junio C Hamano @ 2017-02-01 23:28 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1485991441.28767.2.camel@mattmccutchen.net>
Matt McCutchen <matt@mattmccutchen.net> 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 understanding. Would it have saved you
> time if I had included some of this explanation in the patch "cover
> letter"?
The fact that I arrived at the same understanding by reading the
change without peeking at such a cheat-sheet gives me more peace of
mind ;-)
Thanks.
^ permalink raw reply
* Re: [PATCH] doc: add note about ignoring --no-create-reflog
From: Jeff King @ 2017-02-01 23:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: cornelius.weig, git
In-Reply-To: <xmqqefzhmr02.fsf@gitster.mtv.corp.google.com>
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 compiled-in default and that is also not overriden.
>
> IOW, "does not negate the setting of core.logallrefupdates" will
> open us to reports "I do not have the configuration set, but I still
> get reflog even when --no-create-reflog is given".
>
> The negated form `--no-create-reflog` currently does not negate
> the default; it overrides an earlier `--create-reflog`, though.
>
> perhaps?
True. I thought the default was "off", and that we merely set the config
when initializing a repo. But looking again, it really is checking
is_bare_repository() at runtime.
I still think it is OK to mention, as the description of
core.logallrefupdates is where we document the behavior and the
defaults. So even with "I do not have it set", that is still the key to
find more information.
I do not care that strongly either way, though. This is a minor issue,
and I suspect just about any note would be helpful.
-Peff
^ permalink raw reply
* Re: git commit results in many lstat()s
From: Junio C Hamano @ 2017-02-01 23:50 UTC (permalink / raw)
To: Gumbel, Matthew K; +Cc: git@vger.kernel.org
In-Reply-To: <DA0A42D68346B1469147552440A645039A9C57D6@ORSMSX115.amr.corp.intel.com>
"Gumbel, Matthew K" <matthew.k.gumbel@intel.com> writes:
> "Junio C Hamano" <jch2355@gmail.com> 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 any downside or negative side-effects?
There may be other fallouts, but one that immediately comes to mind
is that it may break pre-commit hook.
When we get "--only", we prepare an temporary index to create the
commit out of, and give it to the pre-commit hook. The hook expects
that the cached stat information is up-to-date, iow, it does not
have to do 'update-index --refresh' before using plumbing commands
like "diff-index" to do its own inspection of the working tree.
^ permalink raw reply
* Re: [PATCH] doc: add note about ignoring --no-create-reflog
From: Junio C Hamano @ 2017-02-01 23:54 UTC (permalink / raw)
To: Jeff King; +Cc: cornelius.weig, git
In-Reply-To: <20170201233202.p462dggidiiyx6s6@sigill.intra.peff.net>
Jeff King <peff@peff.net> 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 logallrefupdates
>> will get the compiled-in default and that is also not overriden.
>>
>> IOW, "does not negate the setting of core.logallrefupdates" will
>> open us to reports "I do not have the configuration set, but I still
>> get reflog even when --no-create-reflog is given".
>>
>> The negated form `--no-create-reflog` currently does not negate
>> the default; it overrides an earlier `--create-reflog`, though.
>>
>> perhaps?
>
> True. I thought the default was "off", and that we merely set the config
> when initializing a repo. But looking again, it really is checking
> is_bare_repository() at runtime.
>
> I still think it is OK to mention, as the description of
> core.logallrefupdates is where we document the behavior and the
> defaults. So even with "I do not have it set", that is still the key to
> find more information.
OK, let's take yours as the final and merge it down to 'next'
soonish.
^ permalink raw reply
* RE: git commit results in many lstat()s
From: Gumbel, Matthew K @ 2017-02-02 0:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org
In-Reply-To: <xmqq60ktmpwl.fsf@gitster.mtv.corp.google.com>
"Junio C Hamano <mailto:jch2355@gmail.com> writes:
"Gumbel, Matthew K" <matthew.k.gumbel@intel.com> 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 with that. Do you see any downside or negative side-effects?
> There may be other fallouts, but one that immediately comes to mind
> is that it may break pre-commit hook.
If pre-commit hook exists, we can fall-back to original behavior and call
refresh_cache(). Many repos will not have pre-commit hook and can
benefit from the speedup.
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?
Thanks,
Matt
^ permalink raw reply
* Re: git commit results in many lstat()s
From: brian m. carlson @ 2017-02-02 0:25 UTC (permalink / raw)
To: Gumbel, Matthew K; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <DA0A42D68346B1469147552440A645039A9C5929@ORSMSX115.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 631 bytes --]
On Thu, Feb 02, 2017 at 12:14:30AM +0000, 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 && (cd t && GIT_PROVE_OPTS=-j3 make prove)
This, of course, requires that you have Perl's prove installed, which
has been part of core Perl since 5.10.1.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
^ permalink raw reply
* Re: [PATCH 2/7] completion: add subcommand completion for rerere
From: SZEDER Gábor @ 2017-02-02 0:57 UTC (permalink / raw)
To: Cornelius Weig
Cc: SZEDER Gábor, bitte.keine.werbung.einwerfen, thomas.braun,
john, git
In-Reply-To: <20170122225724.19360-3-cornelius.weig@tngtech.com>
> 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 a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index c54a557..8329f09 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -2401,6 +2401,17 @@ _git_replace ()
> __gitcomp_nl "$(__git_refs)"
> }
>
> +_git_rerere ()
> +{
> + local subcommands="clear forget diff remaining status gc"
> + local subcommand="$(__git_find_on_cmdline "$subcommands")"
> + if test -z "$subcommand"
> + then
> + __gitcomp "$subcommands"
> + return
> + fi
> +}
> +
> _git_reset ()
> {
> __git_has_doubledash && return
> --
> 2.10.2
You didn't add 'rerere' to the list of porcelain commands, i.e. it
won't be listed after 'git <TAB><TAB>'. I'm not saying it should be
listed there, because I can't decide whether 'rerere' is considered
porcelain or plumbing... Just wanted to make sure that this omission
was intentional.
^ permalink raw reply
* Re: [PATCH 6/7] completion: teach remote subcommands option completion
From: SZEDER Gábor @ 2017-02-02 1:37 UTC (permalink / raw)
To: Cornelius Weig
Cc: SZEDER Gábor, bitte.keine.werbung.einwerfen, thomas.braun,
john, git
In-Reply-To: <20170122225724.19360-7-cornelius.weig@tngtech.com>
> 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 manpage or in 'git
remote -h', I could only find them after looking at the source code...
Good eyes :)
> - set-url: --push --add --delete
> - get-url: --push --all
> - prune: --dry-run
> ---
> contrib/completion/git-completion.bash | 36 +++++++++++++++++++++++++++-------
> 1 file changed, 29 insertions(+), 7 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index e76cbd7..0e09519 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -2384,24 +2384,46 @@ _git_config ()
>
> _git_remote ()
> {
> - local subcommands="add rename remove set-head set-branches set-url show prune update"
> + local subcommands="
> + add rename remove set-head set-branches
> + get-url set-url show prune update
> + "
> local subcommand="$(__git_find_on_cmdline "$subcommands")"
> if [ -z "$subcommand" ]; then
> - __gitcomp "$subcommands"
> + case "$cur" in
> + --*)
> + __gitcomp "--verbose"
> + ;;
> + *)
> + __gitcomp "$subcommands"
> + ;;
> + esac
> return
> fi
>
> - case "$subcommand" in
> - rename|remove|set-url|show|prune)
> - __gitcomp_nl "$(__git_remotes)"
> + case "$subcommand,$cur" in
> + add,--*)
> + __gitcomp "--track --master --fetch --tags --no-tags --mirror="
> ;;
> - set-head|set-branches)
> + add,*)
> + ;;
> + set-head,*|set-branches,*)
The 'set-head' subcommand has '--auto' and '--delete' options, and
'set-branches' has '--add'.
> __git_complete_remote_or_refspec
> ;;
> - update)
> + update,*)
The 'update' subcommand has a '--prune' option.
Otherwise it all looks good.
> __gitcomp "$(__git_get_config_variables "remotes")"
> ;;
> + set-url,--*)
> + __gitcomp "--push --add --delete"
> + ;;
> + get-url,--*)
> + __gitcomp "--push --all"
> + ;;
> + prune,--*)
> + __gitcomp "--dry-run"
> + ;;
> *)
> + __gitcomp_nl "$(__git_remotes)"
> ;;
> esac
> }
> --
> 2.10.2
^ permalink raw reply
* Re: [PATCH 4/7] completion: teach ls-remote to complete options
From: SZEDER Gábor @ 2017-02-02 1:40 UTC (permalink / raw)
To: Cornelius Weig
Cc: SZEDER Gábor, bitte.keine.werbung.einwerfen, thomas.braun,
john, git
In-Reply-To: <20170122225724.19360-5-cornelius.weig@tngtech.com>
> 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 total here, so there is really no chance
for cluttered terminals, and all eight are mentioned in the synopsis.
> ---
> contrib/completion/git-completion.bash | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 652c7e2..36fe439 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1449,6 +1449,12 @@ _git_ls_files ()
>
> _git_ls_remote ()
> {
> + case "$cur" in
> + --*)
> + __gitcomp "--heads --tags --refs --get-url"
> + return
> + ;;
> + esac
> __gitcomp_nl "$(__git_remotes)"
> }
>
> --
> 2.10.2
^ permalink raw reply
* Re: [PATCH v2 7/7] completion: recognize more long-options
From: SZEDER Gábor @ 2017-02-02 2:00 UTC (permalink / raw)
To: Cornelius Weig; +Cc: j6t, Shawn Pearce, git
In-Reply-To: <2841d2de-32ad-eae8-6039-9251a40bb00e@tngtech.com>
On Wed, Feb 1, 2017 at 5:49 PM, Cornelius Weig
<cornelius.weig@tngtech.com> 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, <cornelius.weig@tngtech.com> wrote:
>>> From: Cornelius Weig <cornelius.weig@tngtech.com>
>>>
>>> Recognize several new long-options for bash completion in the following
>>> commands:
>>
>> Adding more long options that git commands learn along the way is
>> always an improvement. However, seeing "_several_ new long options"
>> (or "some long options" in one of the other patches in the series)
>> makes the reader wonder: are these the only new long options missing
>> or are there more? If there are more, why only these are added? If
>> there aren't any more missing long options left, then please say so,
>> e.g. "Add all missing long options, except the potentially
>> desctructive ones, for the following commands: ...."
>
> Personally, I agree with you that
>> Adding more long options that git commands learn along the way is
>> always an improvement.
> However, people may start complaining that their terminal becomes too
> cluttered when doing a double-Tab. In my cover letter, I go to length
> about this. My assumption was that all options that are mentioned in the
> introduction of the command man-page should be important enough to have
> them in the completion list.
But that doesn't mean that the ones not mentioned in the synopsis
section are not worth completing.
The list of options listed by the completion script for several of
these commands fits on a single line. The command with the most
options among these is 'git pull', and even its options don't fill
more than half of a 80x25 screen. I see no danger of people coming
complaining.
> I'll change my commit message accordingly.
>
>>> - rm: --force
>>
>> '--force' is a potentially destructive option, too.
>
> Thanks for spotting this.
>
> Btw, I haven't found that non-destructive options should not be eligible
> for completion. To avoid confusion about this in the future, I suggest
> to also change the documentation:
>
> index 933bb6e..96f1c7f 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -13,7 +13,7 @@
> # *) git email aliases for git-send-email
> # *) tree paths within 'ref:path/to/file' expressions
> # *) file paths within current working directory and index
> -# *) common --long-options
> +# *) common non-destructive --long-options
I don't mind such a change, but I don't think that list was ever meant
to be comprehensive or decisive. It is definitely not the former, as
it's missing several things that the completion script does support.
OTOH, it talks about .git/remotes, which has been considered legacy
for quite some years (though it's right, because the completion script
still supports it).
> I take it you have also looked at the code itself? Then I would gladly
> mention you as reviewer in my sign-off.
Yeah, most of the changes was rather straightforward, except the
completion of 'git remote's subcommands' options, but that looks
good, too.
Gábor
^ permalink raw reply
* Git trademark status and policy
From: Jeff King @ 2017-02-02 2:26 UTC (permalink / raw)
To: git
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 text below, which will generally mean the Git
Project Leadership Committee (PLC). I.e., the people who represent the
Git project as part of Conservancy -- me, Junio Hamano, and Shawn
Pearce.
We approached Conservancy in Feb 2013 about getting a trademark on Git
to ensure that anything calling itself "Git" remained interoperable with
Git. Conservancy's lawyer drafted the USPTO application and submitted it
that summer. The trademark was granted in late 2014 (more on that delay
in a moment).
Concurrently, we developed a written trademark policy, which you can
find here:
https://git-scm.com/trademark
This was started from a template that Conservancy uses and customized by
Conservancy and the Git PLC.
While the original idea was to prevent people from forking the
software, breaking compatibility, and still calling it Git, the policy
covers several other cases.
One is that you can't imply successorship. So you also can't fork the
software, call it "Git++", and then tell everybody your implementation
is the next big thing.
Another is that you can't use the mark in a way that implies association
with or endorsement by the Git project. To some degree this is necessary
to prevent dilution of the mark for other uses, but there are also cases
we directly want to prevent.
For example, imagine a software project which is only tangentially
related to Git. It might use Git as a side effect, or might just be
"Git-like" in the sense of being a distributed system with chained
hashes. Let's say as an example that it does backups. We'd prefer it
not call itself GitBackups. We don't endorse it, and it's just using the
name to imply association that isn't there. You can come up with similar
hypotheticals: GitMail that stores mailing list archives in Git, or
GitWiki that uses Git as a backing store.
Those are all fictitious examples (actually, there _are_ real projects
that do each of those things, but they gave themselves much more unique
names). But they're indicative of some of the cases we've seen. I'm
intentionally not giving the real names here, because my point isn't to
shame any particular projects, but to discuss general policy.
Careful readers among you may now be wondering about GitHub, GitLab,
Gitolite, etc. And now we get back to why it took over a year to get the
trademark granted.
The USPTO initially rejected our application as confusingly similar to
the existing trademark on GitHub, which was filed in 2008. While one
might imagine where the "Git" in GitHub comes from, by the time we
applied to the USPTO, both marks had been widely used in parallel for
years. So we worked out an agreement with GitHub which basically says
"we are mutually OK with the other trademark existing".
(There was another delay caused by a competing application from a
proprietary version control company that wanted to re-brand portions of
their system as "GitFocused" (not the real name, but similar in spirit).
We argued our right to the name and refused to settle; they eventually
withdrew their application).
So GitHub is essentially outside the scope of the trademark policy, due
to the history. We also decided to explicitly grandfather some major
projects that were using similar portmanteaus, but which had generally
been good citizens of the Git ecosystem (building on Git in a useful
way, not breaking compatibility). Those include GitLab, JGit, libgit2,
and some others. The reasoning was generally that it would be a big pain
for those projects, which have established their own brands, to have to
switch names. It's hard to hold them responsible for picking a name that
violated a policy that didn't yet exist.
If the "libgit2" project were starting from scratch today, we'd probably
ask it to use a different name (because the name may imply that it's an
official successor). However, we effectively granted permission for this
use and it would be unfair to disrupt that.
There's one other policy point that has come up: the written policy
disallows the use of "Git" or the logo on merchandise. This is something
people have asked about it (e.g., somebody made some Git stress balls,
and another person was printing keycaps with a Git logo). We have always
granted it, but wanted to reserve the right in case there was some use
that we hadn't anticipated that would be confusing or unsavory.
Enforcement of the policy is done as cases are brought to the attention
of Conservancy and the Git PLC. Sometimes people mail Conservancy
directly, and sometimes a use is noticed by the Git PLC, which mails
Conservancy. In either case, Conservancy's lawyer pings the Git PLC,
and we decide what to do about it, with advice from the lawyer. The end
result is usually a letter from the lawyer politely asking them to stop
using the trademark.
So how does the Git PLC make decisions? We generally try to follow the
policy in an equitable way, but there are a lot of corner cases. Here
are some rules of thumb we've worked out:
- Things that are only tangentially related to Git are out of policy
(e.g., if you had a service which rewards bitcoin for people's
commits, we'd prefer it not be branded GitRewards).
- Anything that claims to be Git but does not interoperate is out.
We haven't had to use that one yet.
- Portmanteaus ("GitFoo" or "FooGit") are out. Most of the cases run
into this rule. For instance, we asked GitHub to not to use "DGit"
to refer to their replicated Git solution, and they[1] rebranded.
We also asked "GitTorrent" not to use that name based on this rule.
- Commands like "git-foo" (so you run "git foo") are generally OK.
This is Git's well-known extension mechanism, so it doesn't really
imply endorsement (on the other hand, you do not get to complain if
you choose too generic a name and conflict with somebody else's use
of the same git-foo name).
- When "git-foo" exists, we've approved "Git Foo" as a matching
project name, but we haven't decided on a general rule to cover this
case. The only example here is "Git LFS".
So that's more or less where we're at now. In my opinion, a few open
questions are:
1. Is the portmanteau clause a good idea? GitTorrent is a possibly
interesting case there. It's an open source project trying to
make a torrent-like protocol for Git. That's something we'd like to
have happen. But does the name imply more endorsement than we're
willing to give (especially at an early stage)?
2. Is it a problem that the grandfathering of some names may create a
branding advantage? Under the policy today, we wouldn't grant
"GitHub" or "GitLab". Does that give an unfair advantage to the
incumbents?
I think the answer is "yes", but the Git PLC is also not sure that
there is a good solution. If we'd thought about trademark issues
much earlier, we would have been in different circumstances and
probably would have made different decisions. But we didn't, so we
have to live with how things developed in the meantime.
Loosening now would be a mistake as it would cause a lot of
confusion around the trademark and make it harder for us to stop
the uses that we really care about stopping now.
3. Was granting "Git LFS" the right call? I think the project is a good
one and has worked well with the greater Git community. But I think
the name has implied some level of "officialness". We obviously
need to allow "git-lfs" as a name. But should the policy have said
"you can call this LFS, and the command is git-lfs, but don't say
'Git LFS'". I'm not sure.
One option would have been to ask "git-foo" to prefer "Foo for Git"
instead of "Git Foo" in their branding (it's too late now for "Git
LFS", so this is a hypothetical question for future requests now).
4. I think the merchandise clause has worked fine, and in general the
plan is to grant it in most cases. I have trouble thinking of an
item I _wouldn't_ want the Git logo on, and I'd rather err on the
side of permissiveness than be the arbiter of taste. And having the
Git logo on merchandise generally raises awareness of Git.
But perhaps people have stronger opinions (either about the type of
item, or perhaps the practices of the manufacturer producing it).
It's hard to predict how a particular item would impact how people
see the Git brand.
-Peff
[1] I used "they" to refer to GitHub, but as many of you know, I am also
employed by GitHub. If you are wondering how that works, I generally
abstain from any decisions regarding GitHub (and that includes the
"Git LFS" decision, which was a project started by GitHub). That
leaves two voting PLC members for those decisions; Conservancy gets
a tie-breaking vote, but it has never come up.
^ permalink raw reply
* git-scm.com status report
From: Jeff King @ 2017-02-02 2:33 UTC (permalink / raw)
To: git
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 domains git-scm.com and git-scm.org (the latter we've had
for a while). They both point to the same website, which has general
information about Git, including:
- a general overview of Git
- links to the latest releases (both source and some binary
installers)
- HTML-rendered copies of the manpages (both for the current version
and historical versions)
- an HTML rendering of the contents of the Pro Git book, along with
translations. The book content is licensed cc-by-nc-sa and developed
openly.
- various external links to books, tutorials, GUI tools, etc
## How is it developed and hosted
The site is a Ruby on Rails app. The git repository is
https://github.com/git/git-scm.com. Modifications are generally done by
pull requests there. I have admin access on the repository.
The deployed site is hosted on Heroku. It's part of GitHub's
meta-account, and they pay the bills. I have access to it, and am the
only person who deploys updates. Other technical staff at GitHub have
access, too, because of the account setup, but don't generally
participate in maintenance.
It uses three 1GB Heroku dynos for scaling, which is $150/mo. It also
uses some Heroku addons which add up to another $80/mo.
## Who's the maintainer
These days, it's pretty much me, with a lot of help from Jean-Noël Avila
on issues with the Pro Git import and formatting code.
Long ago, the site content and code was done by Scott Chacon, with
graphic design help from Jason Long. Scott maintained the site with
help from Bryan Turner for many years. But over time, they both seemed
to get less active, and I haven't seen a peep from either on the site's
GitHub repo in the past year. I've started trying to respond to issues
and pull requests to keep things healthy.
The site is mostly in maintenance mode, but things do need addressing.
People show up with new additions, fixes for typos, broken links and
other formatting problems, etc. There are a lot of long-standing
Asciidoc formatting problems both for the manpages and the imported Pro
Git content.
## What next
We can probably continue in maintenance mode like this for a while.
We've fixed a lot of of the long-standing formatting issues over the
past year, so maintaining seems to have subsided in the past few months
to mostly just merging or rejecting the occasional PR.
Still, if anybody is interested in helping with this work, I'd love to
have more eyes on it. I can give people access to the GitHub repo.
Unfortunately, I can't do so for the Heroku deploy, and part of the
maintenance burden is that the site is finicky and often needs manual
intervention (e.g., a fix to formatting requires rebuilding the
manpages, which needs a job run manually on Heroku).
It's possible that the content or visual design of the site could be
improved in various ways. I don't have any strong desires myself, but
maybe others do. If people start doing larger work, though, we have a
real lack of reviewers, and I have very little expertise with Rails or
with visual design. So anybody who wants to do this should be prepared to
take maintenance ownership.
At some point, GitHub may boot us off of the shared Heroku account,
because my impression is that it's somewhat of an administrative
headache. I don't think the Git project could afford the $230/mo hosting
fees; that's basically all the money we make. On the other hand, we
haven't actively solicited funds to any great degree, and it's possible
we could get GitHub or some other entity to just sponsor us with site
fees (I've heard zero complaints from GitHub about the money; it's
mostly just that the site is an oddball among their other assets).
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.
The site does see a lot of hits, but most of the content is a few basic
web pages, and copies of other static content that is updated
only occasionally (manpage content, lists of downloads, etc). The biggest
dynamic component is the site search, I think.
I do wonder if there's room for improvement either:
- by measuring and optimizing the Heroku deploy. I have no idea about
scaling Rails or Heroku apps. Do we really need three expensive
dynos, or a $50/mo database plan? I'm not even sure what to measure,
or how. There are some analytics on the site, but I don't have
access to them (I could probably dig around for access if there was
somebody who actually knew how to do something productive with
them).
- by moving to a simpler model. I wonder if we could build the site
once and then deploy a more static variant of it to a cheaper
hosting platform. I'm not really sure what our options would be, how
much work it would take to do the conversion, and if we'd lose any
functionality.
If anybody is interested in tackling a project like this, let me know,
and I can try to provide access to whatever parts are needed.
-Peff
^ permalink raw reply
* Git / Software Freedom Conservancy status report
From: Jeff King @ 2017-02-02 2:45 UTC (permalink / raw)
To: git
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 session to the list.
# Background
Git is a member project of the Software Freedom Conservancy. We joined
in 2010 so that Conservancy could help us manage our money and other
assets, and represent us for legal stuff like trademarks. Conservancy
doesn't hold any copyright on Git code, and our status as a member
project is totally disconnected from the development of the code.
A "Project Leadership Committee" (PLC) represents Git in Conservancy.
The PLC consists of me, Shawn Pearce, and Junio Hamano.
# Financials
In short, we have about $21K (USD) in our account. Here's the breakdown
of money in versus out (these are sums of double-entry transactions, so
negative is good here):
$-27,468.01 Income:Git
$6,207.50 Expenses:Git
--------------------
$-21,260.51
You can see we don't actually spend that much. Here's the same report
just since 2016-01-01:
$-4,468.64 Income:Git
$2,102.32 Expenses:Git
--------------------
$-2,366.32
Those reports come from running "ledger" on the file given to us by
Conservancy. I can run other reports if there are things people want to
know.
I _think_ there are some outstanding transactions that actually bump
that closer to $3K (e.g., money invoiced for GSoC that gets collected by
Conservancy and then eventually dumped into a bank account).
Here's the same report over the last three years:
$-12,990.84 Income:Git
$2,772.78 Expenses:Git
--------------------
$-10,218.06
So we seem to average about $3K/year ahead of our expenses.
## Where does the income come from?
We get money from the mentor stipends for GSoC. We get about $1K/year in
donations (you can donate to Conservancy and earmark for Git, or there's
a "donate" button on git-scm.com, though it's not particularly
prominent).
Links from git-scm.com to buy the paper copy of the Pro Git book are
Amazon affiliate links. If people buy stuff (either the book, or other
things after clicking around the site), we get some money. This accounts
for ~$800 this year.
Packt Publishing has several technical books related to Git, and they
send some of the royalties to the project. That was ~$400 this year.
## Where do expenses go?
Most of the money goes to travel. Note that this accounts for some of
the income, too. if we send a mentor to the GSoC mentor summit, for
example, we invoice Google for the money, which shows up as income. And
then it leaves us to reimburse the mentor, which is an expense. So it's
net-zero for the project, but inflates the numbers.
We also spent ~$900 on legal filing fees for the trademark (not this
year, but that's part of the total income/expenses history I showed
earlier).
# Activity Summary for 2016
This is a summary of interesting things related to the project that
happened in the past year.
## Mentoring
We had one GSoC student, Pranit Bauva (who passed). The actual coding
project has little to do with our Conservancy status, but the Git
project did get the stipend money, and handled the financial logistics
for Christian Couder to go to the mentor summit (the money ultimately
comes from Google for that).
We were a potential Outreachy project last Spring for the first time,
but we didn't end up picking an intern. As a reminder, the Outreachy
program is somewhat similar to GSoC, but with a focus on getting
under-represented groups involved in programming (but not necessarily
college students). The projects themselves have to cover the stipend for
the intern (or get funding elsewhere to do so). Last year GitHub offered
to fund one intern for us, but we didn't end up selecting anyone.
## Travel Money
We paid for travel for one developer to Git Merge last year, and we are
covering one this year, too.
Each year I ask if financial circumstances are preventing anyone from
coming, and if the project can help. Each year I have gotten only one
response. The Git PLC discusses each case, and we decide whether and how
much money to provide; Conservancy handles the logistics. That tries to
balance privacy for individuals who need financial support with some
accountability for the project.
## git-scm.com DNS
We now own the git-scm.com domain, which is held for us in a Conservancy
account (this is mostly for convenience; they hold a ton of domains, and
can just auto-renew out of our money). We also have owned git-scm.org
for a while.
There has never really been an "official" Git website, but git-scm.com
has been the de facto one for a while. I think us actually controlling
the domain makes it more so. The actual governance of the site content
is up in the air. I'll send a separate email about that[1].
## Trademark
We hold a trademark on "Git" and the diamond-shaped logo, and have to
deal with various questions for that. I'll send out a separate, much
more detailed mail about that[2].
That's about it. I'd be happy to try to answer any questions about this
year's activities, how Git's membership in Conservancy works, etc.
-Peff
[1] http://public-inbox.org/git/20170202023349.7fopb3a6pc6dkcmd@sigill.intra.peff.net/
[2] http://public-inbox.org/git/20170202022655.2jwvudhvo4hmueaw@sigill.intra.peff.net/
^ permalink raw reply
* init --separate-git-dir does not set core.worktree
From: Kyle Meyer @ 2017-02-02 3:55 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
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 understand things well enough to attempt a patch.
Thanks.
[1] https://public-inbox.org/git/CALqjkKZO_y0DNcRJjooyZ7Eso7yBMGhvZ6fE92oO4Su7JeCeng@mail.gmail.com/T/#u
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index b8fc588b1..444e75865 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -309,6 +309,7 @@ test_expect_success 'init with separate gitdir' '
git init --separate-git-dir realgitdir newdir &&
echo "gitdir: $(pwd)/realgitdir" >expected &&
test_cmp expected newdir/.git &&
+ check_config realgitdir false "$(pwd)/newdir" &&
test_path_is_dir realgitdir/refs
'
^ permalink raw reply related
* Re: git-scm.com status report
From: Eric Wong @ 2017-02-02 4:36 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20170202023349.7fopb3a6pc6dkcmd@sigill.intra.peff.net>
Jeff King <peff@peff.net> 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
(~1GB git objects + ~3GB Xapian index).
> The site does see a lot of hits, but most of the content is a few basic
> web pages, and copies of other static content that is updated
> only occasionally (manpage content, lists of downloads, etc). The biggest
> dynamic component is the site search, I think.
Maybe optimize search if that's slowest, first. public-inbox
uses per-host Xapian indexes so there's no extra network latency
and it seems to work well. But maybe you don't get FS write
access without full VPS access on Heroku...
nginx handles static content easily, and since it looks like you
guys use unicorn[*] for running the Ruby part. I really hope
nginx is in front of unicorn, since (AFAIK) Heroku doesn't put
nginx in front of it by default.
[*] I wrote and maintain unicorn; and have not yet recommended
any reverse proxy besides nginx to buffer for it.
However, having varnish or any other caching layer in
between nginx and unicorn is great, too. I dunno how Heroku
(or any proprietary deployment systems) handle it, though.
> I do wonder if there's room for improvement either:
>
> - by measuring and optimizing the Heroku deploy. I have no idea about
> scaling Rails or Heroku apps. Do we really need three expensive
> dynos, or a $50/mo database plan? I'm not even sure what to measure,
> or how. There are some analytics on the site, but I don't have
> access to them (I could probably dig around for access if there was
> somebody who actually knew how to do something productive with
> them).
I track down the most expensive requests in per-request timing
logs and work on profiling + optimizations from there...
Nothing fancy and no relying on proprietary tools like NewRelic.
I also watch for queueing in listen socket backlog (with
raindrops <https://raindrops-demo.bogomips.org/> or ss(8) to
notice overloading. Again, I don't know how much visibility
you have with Heroku.
> - by moving to a simpler model. I wonder if we could build the site
> once and then deploy a more static variant of it to a cheaper
> hosting platform. I'm not really sure what our options would be, how
> much work it would take to do the conversion, and if we'd lose any
> functionality.
*shrug* That'd be more work, at least. I'd figure out what's
slow, first.
Fwiw, Varnish definitely helps public-inbox when slammed by
HN/Reddit traffic. It's great as long as you don't have
per-user data to invalidate, which seems to be the case for
git-scm.
> If anybody is interested in tackling a project like this, let me know,
> and I can try to provide access to whatever parts are needed.
While I'm not up-to-date with modern Rails or deployment stuff,
I'm available via email if you have any lower-level
Ruby/unicorn/nginx-related questions. I'm sure GitHub/GitLab
also has folks familiar with nginx+unicorn deployment on
bare metal or VPS who could also help.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox