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"
> +#include "submodule.
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 originates from inside
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 hav
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.
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 p
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 sure how easy
>>
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
>> > initial fetch). But I
On 10/31/2016 03:38 PM, Brandon Williams wrote:
+ struct strbuf buf = STRBUF_INIT;
+ char *submodule_url = NULL;
+
+ strbuf_addf(&buf, "submodule.%s.url", module->name);
+ ret = !git_config_get_string(buf.buf, &submodule_url);
+
+
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
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 to the
>> + whole number of entries in both t
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.
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 acceptable way to give credit to Jeff f
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 few years for them to b
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
> process gitlinks went th
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 X and its reach
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 helping with this
> > patch?
>
> Wha
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 fo
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 similar
>> > to "gitlink" in that it can record a
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, I decided to invest
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 control for allowing
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
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 prevent
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
--- a/Documentation/gitcore-tutorial.txt
+++ b/Docu
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
>
> --
> Brandon Williams
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 unlike "gitlink" it do
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
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
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 allow
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
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 parents to your commit ob
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 a/Documentation/git-check-ref-format.txt
b/Documentation/git-check-
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
b/Documentation/git-check-ref-format.txt
index 8611a
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 bat
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
---
builtin/check-ref-format.c |
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 deletions(-)
diff --git a/builtin/c
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(-)
diff --git a/builtin/check-ref-fo
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 shouldn't have been added
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 m
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 parameter and adju
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 and adjust the c
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 unu
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
>
>
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 as part of our unit test
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 func
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
---
branch
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 Te
Bug.private.program.
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 -
diffcore-delta.c | 1 -
dif
48 matches
Mail list logo
