[PATCH 1/5] check-ref-format: Refactor out check_one_ref_format

We are going to want to reuse this. No functional change right now. It currently has a hidden memory leak if --normalize is used. Signed-off-by: Ian Jackson --- builtin/check-ref-format.c | 26 ++ 1 file changed, 14 insertions(+), 12

[PATCH 4/5] check-ref-format: New --report-errors option

Signed-off-by: Ian Jackson --- Documentation/git-check-ref-format.txt | 8 ++-- builtin/check-ref-format.c | 10 -- 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/Documentation/git-check-ref-format.txt

[PATCH 0/5] git check-ref-format --stdin --report-errors

I wanted to be able to syntax check lots of proposed refs quickly (please don't ask why - it's complicated!) So I added a --stdin option to git-check-ref-format. Also it has --report-errors now too so you can get some kind of useful error message if it complains. It's still not really a good

[PATCH 5/5] check-ref-format: New --stdin option

Signed-off-by: Ian Jackson --- Documentation/git-check-ref-format.txt | 10 -- builtin/check-ref-format.c | 34 +++--- 2 files changed, 39 insertions(+), 5 deletions(-) diff --git

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 04, 2016 at 12:19:55PM -0700, Jacob Keller wrote: > I agree with your assessment here. The main difficulty in implementing > gitrefs is to ensure that they actually do get picked up by > reachability checks to prevent dropping commits. I'm not sure how easy > this is, but I would much

[PATCH 3/5] check-ref-format: Abolish leak of collapsed refname

collapse_slashes always returns a value from xmallocz. Right now this leak is not very interesting, since we only call check_one_ref_format once. Signed-off-by: Ian Jackson --- builtin/check-ref-format.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)

[PATCH v3] transport: add protocol policy config option

Previously the `GIT_ALLOW_PROTOCOL` environment variable was used to specify a whitelist of protocols to be used in clone/fetch/pull commands. This patch introduces new configuration options for more fine-grained control for allowing/disallowing protocols. This also has the added benefit of

[PATCH 2/5] check-ref-format: Refactor to make --branch code more common

We are going to want to permit other options with --branch. So, replace the special case with just an entry for --branch in the parser for ordinary options, and check for option compatibility at the end. No overall functional change. Signed-off-by: Ian Jackson

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 4, 2016 at 10:57 AM, Junio C Hamano wrote: > I think this is backwards. The root cause of the issue you have > with "gitk" is because you added something that is *NOT* a parent to > your commit. We shouldn't have to add a mechanism to filter > something that

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 4, 2016 at 6:57 PM, Junio C Hamano wrote: > > Imagine we invent a new tree entry type, "gitref", that is similar > to "gitlink" in that it can record a commit object name in a tree, > but unlike "gitlink" it does imply reachability. And you do not add > phony

Re: [PATCH v3] transport: add protocol policy config option

On 11/04, Brandon Williams wrote: > Signed-off-by: Brandon Williams Is there an acceptable way to give credit to Jeff for helping with this patch? -- Brandon Williams

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 04, 2016 at 10:57:09AM -0700, Junio C Hamano wrote: > After your talk at LPC2016, I was thinking about your proposal to > give an option to hide certain parents from "git log" traversal. > > While I do not think we would terribly mind a new feature in the > core to support third-party

Re: gitk: avoid obscene memory consumption

On Fri, Nov 4, 2016 at 12:49 PM, Markus Hitter wrote: > > Hello all, +cc Paul Mackeras, who maintains gitk. > > after Gitk brought my shabby development machine (Core2Duo, 4 GB RAM, Ubuntu > 16.10, no swap to save the SSD) to its knees once more than I'm comfortable > with,

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 4, 2016 at 10:19 PM, Josh Triplett wrote: > On Fri, Nov 04, 2016 at 09:47:41PM +0100, Christian Couder wrote: >> On Fri, Nov 4, 2016 at 6:57 PM, Junio C Hamano wrote: >> > >> > Imagine we invent a new tree entry type, "gitref", that is

Re: [PATCH v3] transport: add protocol policy config option

On Fri, Nov 04, 2016 at 02:35:57PM -0700, Stefan Beller wrote: > On Fri, Nov 4, 2016 at 1:58 PM, Brandon Williams wrote: > > On 11/04, Brandon Williams wrote: > >> Signed-off-by: Brandon Williams > > > > Is there an acceptable way to give credit to Jeff for

[PATCH] doc: fill in omitted word

Signed-off-by: Kristoffer Haugsbakk --- Documentation/gitcore-tutorial.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index 4546fa0..9860517 100644 ---

Re: [PATCH v3] transport: add protocol policy config option

On Fri, Nov 4, 2016 at 1:55 PM, Brandon Williams wrote: > Previously the `GIT_ALLOW_PROTOCOL` environment variable was used to > specify a whitelist of protocols to be used in clone/fetch/pull > commands. This patch introduces new configuration options for more > fine-grained

gitk: avoid obscene memory consumption

Hello all, after Gitk brought my shabby development machine (Core2Duo, 4 GB RAM, Ubuntu 16.10, no swap to save the SSD) to its knees once more than I'm comfortable with, I decided to investigate this issue. Result of this investigation is, my Git repo has a commit with a diff of some 365'000

Re: [PATCH v3] transport: add protocol policy config option

On Fri, Nov 04, 2016 at 01:55:33PM -0700, Brandon Williams wrote: > Previously the `GIT_ALLOW_PROTOCOL` environment variable was used to > specify a whitelist of protocols to be used in clone/fetch/pull > commands. This patch introduces new configuration options for more > fine-grained control

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 4, 2016 at 12:49 PM, Jeff King wrote: > I think the main complication is that the reachability rules are used > during object transfer. So you'd probably want to introduce some > protocol extension to say "I understand gitrefs", so that when one side > says "I have sha1

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 4, 2016 at 2:55 PM, Josh Triplett wrote: > That said, I'd *love* to have gitrefs available, for a wide variety of > applications, and I can see an argument for introducing them and waiting > a few years for them to become universally available, similar to the >

Re: [PATCH v3] transport: add protocol policy config option

On 11/04, Jeff King wrote: > On Fri, Nov 04, 2016 at 02:35:57PM -0700, Stefan Beller wrote: > > > On Fri, Nov 4, 2016 at 1:58 PM, Brandon Williams wrote: > > > On 11/04, Brandon Williams wrote: > > >> Signed-off-by: Brandon Williams > > > > > > Is there an

Re: [PATCH v1 09/19] config: add git_config_get_max_percent_split_change()

On Tue, Nov 1, 2016 at 8:13 PM, Junio C Hamano wrote: > >>> + return -1; > > Perhaps do the usual > > return error(_("...")); > > here? Ok, it will be in the next version.

Re: [PATCH v1 12/19] Documentation/config: add splitIndex.maxPercentChange

On Tue, Nov 1, 2016 at 8:19 PM, Junio C Hamano wrote: > Christian Couder writes: > >> +splitIndex.maxPercentChange:: >> + When the split index feature is used, this specifies the >> + percent of entries the split index can contain compared

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 04, 2016 at 04:34:34PM -0700, Jacob Keller wrote: > > You might also want fallback rules for storing gitrefs on "old" servers > > (e.g., backfilling gitrefs you need if the server didn't them in the > > initial fetch). But I guess storing any gitrefs on such a server is > > inherently

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 04, 2016 at 04:37:34PM -0700, Jacob Keller wrote: > On Fri, Nov 4, 2016 at 2:55 PM, Josh Triplett wrote: > > That said, I'd *love* to have gitrefs available, for a wide variety of > > applications, and I can see an argument for introducing them and waiting > > a

Re: [PATCH v3] transport: add protocol policy config option

On Fri, Nov 4, 2016 at 1:58 PM, Brandon Williams wrote: > On 11/04, Brandon Williams wrote: >> Signed-off-by: Brandon Williams > > Is there an acceptable way to give credit to Jeff for helping with this patch? What about: Helped-by: Jeff King

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 04, 2016 at 03:49:07PM -0400, Jeff King wrote: > On Fri, Nov 04, 2016 at 12:19:55PM -0700, Jacob Keller wrote: > > > I agree with your assessment here. The main difficulty in implementing > > gitrefs is to ensure that they actually do get picked up by > > reachability checks to

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 04, 2016 at 09:47:41PM +0100, Christian Couder wrote: > On Fri, Nov 4, 2016 at 6:57 PM, Junio C Hamano wrote: > > > > Imagine we invent a new tree entry type, "gitref", that is similar > > to "gitlink" in that it can record a commit object name in a tree, > > but

Re: Regarding "git log" on "git series" metadata

On November 4, 2016 7:48:17 PM MDT, Jeff King wrote: >On Fri, Nov 04, 2016 at 04:34:34PM -0700, Jacob Keller wrote: > >> > You might also want fallback rules for storing gitrefs on "old" >servers >> > (e.g., backfilling gitrefs you need if the server didn't them in >the >> >

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 04, 2016 at 09:41:06PM -0700, Junio C Hamano wrote: > > I think the main complication is that the reachability rules are used > > during object transfer. So you'd probably want to introduce some > > protocol extension to say "I understand gitrefs", so that when one side > > says "I

Re: Regarding "git log" on "git series" metadata

Junio C Hamano writes: >> I think the main complication is that the reachability rules are used >> during object transfer. One should not type after spending 20+ waking hours on plane and airport. I missed it when I wrote my first response, but yes, the reachability that

Re: [PATCH 4/5] grep: optionally recurse into submodules

On Thu, Oct 27, 2016 at 3:38 PM, Brandon Williams wrote: > diff --git a/builtin/grep.c b/builtin/grep.c > index 8887b6add..f34f16df9 100644 > --- a/builtin/grep.c > +++ b/builtin/grep.c > @@ -18,12 +18,20 @@ > #include "quote.h" > #include "dir.h" > #include "pathspec.h" >

Re: [PATCH v2 1/6] submodules: add helper functions to determine presence of submodules

On 10/31/2016 03:38 PM, Brandon Williams wrote: + struct strbuf buf = STRBUF_INIT; + char *submodule_url = NULL; + + strbuf_addf(, "submodule.%s.url", module->name); + ret = !git_config_get_string(buf.buf, _url); + +

Re: Regarding "git log" on "git series" metadata

Jeff King writes: > On Fri, Nov 04, 2016 at 12:19:55PM -0700, Jacob Keller wrote: > >> I agree with your assessment here. The main difficulty in implementing >> gitrefs is to ensure that they actually do get picked up by >> reachability checks to prevent dropping commits. I'm not

Re: Regarding "git log" on "git series" metadata

Christian Couder writes: > Couldn't a RefTree be used to store refs that point to the base > commit, I think it is the other way around. With the new "gitref" thing that is a pointer to an in-repository commit, RefTree can be naturally implemented.

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 04, 2016 at 09:55:23PM -0600, Josh Triplett wrote: > >> Is it possible currently for a protocol extension to result in "oh > >the > >> server doesn't support this so I'm going to stop pushing"? > > > >Yes, it would be easy for the client to abort if the server fails to > >advertise a

[PATCH] diffcore-delta: remove unused parameter to diffcore_count_changes()

The delta_limit parameter to diffcore_count_changes() has been unused since commit c06c79667c95 ("diffcore-rename: somewhat optimized."). Remove the parameter and adjust all callers. Signed-off-by: Tobias Klauser --- diff.c| 2 +- diffcore-break.c | 1 -

git -C has unexpected behaviour

Hi guys, I ran into some really weird git behaviour today. My git --version is: git version 2.8.1.windows.1 We have a git repository with a submodule called TestData. The data in there is modified and reset as part of our unit tests. The submodule is a sub-folder of the git repository called

[no subject]

Bug.private.program.

[PATCH] branch: remove unused parameter to create_branch()

The name parameter to create_branch() has been unused since commit 55c4a673070f ("Prevent force-updating of the current branch"). Remove the parameter and adjust the callers accordingly. Also remove the parameter from the function's documentation comment. Signed-off-by: Tobias Klauser

Re: git -C has unexpected behaviour

Hi Felix, On Fri, 4 Nov 2016, Felix Nairz wrote: > Now, to the unexpected part, which I think is a bug: > > If the TestData folder is there, but empty (I deleted all the files), > then running > > git -C .\TestData reset --hard > > will NOT throw me an error but run > > git reset --hard > >

Re: git -C has unexpected behaviour

On Fri, Nov 4, 2016 at 7:28 AM, Felix Nairz wrote: > Hi guys, > > I ran into some really weird git behaviour today. > > My git --version is: git version 2.8.1.windows.1 > > We have a git repository with a submodule called TestData. The data in > there is modified and reset

Re: [PATCH] branch: remove unused parameter to create_branch()

On Fri, Nov 04, 2016 at 04:19:49PM +0100, Tobias Klauser wrote: > The name parameter to create_branch() has been unused since commit > 55c4a673070f ("Prevent force-updating of the current branch"). Remove > the parameter and adjust the callers accordingly. Also remove the > parameter from the

Re: [PATCH] diffcore-delta: remove unused parameter to diffcore_count_changes()

On Fri, Nov 04, 2016 at 11:24:36AM +0100, Tobias Klauser wrote: > The delta_limit parameter to diffcore_count_changes() has been unused > since commit c06c79667c95 ("diffcore-rename: somewhat optimized."). > Remove the parameter and adjust all callers. Sounds like a good idea to get rid of an

Re: [PATCH] branch: remove unused parameter to create_branch()

On 2016-11-04 at 17:30:12 +0100, Jeff King wrote: > On Fri, Nov 04, 2016 at 04:19:49PM +0100, Tobias Klauser wrote: > > > The name parameter to create_branch() has been unused since commit > > 55c4a673070f ("Prevent force-updating of the current branch"). Remove > > the parameter

Re: [PATCH] diffcore-delta: remove unused parameter to diffcore_count_changes()

On 2016-11-04 at 17:37:14 +0100, Jeff King wrote: > On Fri, Nov 04, 2016 at 11:24:36AM +0100, Tobias Klauser wrote: > > > The delta_limit parameter to diffcore_count_changes() has been unused > > since commit c06c79667c95 ("diffcore-rename: somewhat optimized."). > > Remove the

Regarding "git log" on "git series" metadata

After your talk at LPC2016, I was thinking about your proposal to give an option to hide certain parents from "git log" traversal. While I do not think we would terribly mind a new feature in the core to support third-party additions like "git series" better, I think this particular one is a big