Hi,
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Marc Branchaud wrote:
>>> The new workdir is empty before the checkout, so attempts to recurse into
>>> a non-existent submodule directory fail.
>>>
>>> Signed-off-by: Marc Branchaud
>>
Hi,
Junio C Hamano wrote:
> Patterns with slash is anchored at
> one directory, and that directory is the one that has per-directory
> .gitignore file. Patterns without slash (including a pattern that
> ends with but otherwise has no other slash) are supposed to
Hi,
Marc Branchaud wrote:
> The new workdir is empty before the checkout, so attempts to recurse into
> a non-existent submodule directory fail.
>
> Signed-off-by: Marc Branchaud
> ---
Thanks for reporting. Can you describe the error message when it fails
here?
> Until the worktree command su
Robin Shen wrote:
> Yes it is using JGit for most operations. JGit API is very well
> designed and is a joy to use. The performance is very good, except
> for long operations such as full clone. So for pull/push I am
> calling native git, but for other operations which may need to be
> executed se
Hi Petko,
Petko Yanev wrote:
> I'm writing to you because git-scm.com is a great project and I want to help
> out.
>
> I'd love to contribute with a donation or in another manner you consider
> acceptable.
>
> In exchange, all I expect is a do-follow backlink to one of our sites.
>
> Do let me kn
+us...@cvs2svn.tigris.org
paduarte wrote:
Hi,
> How did the complete command work?
>
> cvs2git --encoding=ascii --encoding=utf8 --encoding=utf16 --encoding=latin
>
> or
>
> cvs2git --encoding=ascii --encoding=utf8 --encoding=utf16 --encoding=latin
> *+ parameters of git*
>
> ?
Cc-ing the cvs2gi
+jgit-dev
Hi Robin,
Robin Shen wrote:
> Dear git users,
>
> OneDev is an open source git server with interesting features such
> as language aware code search/navigation, issue workflow
> customization, free source/diff comment and discussion, etc.
>
> It is using MIT license and hope it can be u
etitle this further. I'd use something like this.
>
> Subject: config.mak.dev: add -Wall to help autoconf users
With that change, it would still be
Reviewed-by: Jonathan Nieder
:)
Thanks.
Hi,
brian m. carlson wrote:
> In some shells, such as bash and zsh, it's possible to use a command
> substitution to provide the output of a command as a file argument to
> another process, like so:
>
> diff -u <(printf "a\nb\n") <(printf "a\nc\n")
>
> However, this syntax does not produce usef
versions of gcc (gcc 8.2.1 in this particular case) warn about the
> lack of "-Wformat" and thus compilation fails only with this option
> set.
>
> We could fix it by adding "-Wformat", but in general we do want all
> checks included in "-Wall", so let
Hi,
H. Peter Anvin wrote:
> [merge "version"]
> name = Version file merge driver
> driver = sort -V -r %O %A %B | head -1 > %A.tmp.1 && mv -f %A.tmp.1 %A
[...]
> However, I can't even put this in .gitattributes, because doing so would break
> any user who *doesn't* have the previo
+cc: Masaya Suzuki
In October, Thomas Gummerer wrote:
> On 10/12, Jonathan Nieder wrote:
>> Jeff King wrote:
>>> On Fri, Oct 12, 2018 at 07:40:37PM +0100, Thomas Gummerer wrote:
>>>> 801fa63a90 ("config.mak.dev: add -Wformat-security", 2018-09-08) added
>
Hi,
Ævar Arnfjörð Bjarmason wrote:
> On Wed, Dec 26 2018, Junio C Hamano wrote:
>> Hmph. The other overzealous thing you could do is to strenthen A
>> and "fix" the security issue in v2? Which letter comes before A in
>> the alphabet? ;-)
Yes, agreed. This is what I was hinting at in [1] with
Jeff King wrote:
> On Wed, Dec 19, 2018 at 10:39:27AM -0800, Jonathan Nieder wrote:
>> Is there some rule about how long the hex string has to be for this to
>> work?
>
> In both cases, it has to be 7 characters.
Thanks.
[...]
>> The issue with this is that it is a
ar, (2) it's very concrete
(e.g. "first 12 characters", (3) it goes in a trailer, where other
bits intended for machine consumption already go.
Should we adopt it? In other words, how about something like the
following?
If it seems like a good idea, I can add a commit message.
Signed
Hi,
William Hubbs wrote:
> this is my first patch for git, so please be gentle. ;-)
Thanks for contributing!
> I am in a situation where I need to use different authorship information
> for some repositories I commit to.
>
> Git already supports setting different authorship and committer
> info
Hi,
Jeff King wrote:
> - web interfaces like GitHub won't linkify this type of reference
> (whereas they will for something that looks like a hex object id)
>
> - my terminal makes it easy to select hex strings, but doesn't
> understand this git-describe output :)
>
> These tools _cou
Hi John,
John Passaro wrote:
> https://public-inbox.org/git/878t55qga6@evledraar.gmail.com/
>
> The struggle is that Mac's package manager Homebrew has opted,
> apparently with some finality, to no longer support linking to a user
> perl at build time. PERL_PATH is hard-coded to link to the s
Hi,
Jonathan Tan wrote:
> When setup_alternate_shallow() is invoked a second time in the same
> process, it fails with the error "shallow file has changed since we read
> it". One way of reproducing this is to fetch using protocol v2 in such a
> way that backfill_tags() is required, and that the
Ævar Arnfjörð Bjarmason wrote:
> On Mon, Dec 17 2018, Jonathan Nieder wrote:
>> This would make per-branch ACLs (as implemented both by Gerrit and
>> gitolite) an essentially useless feature, so please no.
>
> Doesn't Gerrit always use JGit?
>
> The discussion upt
Hi,
Jeff King wrote:
> On Fri, Dec 14, 2018 at 11:55:30AM +0100, Ævar Arnfjörð Bjarmason wrote:
>> More importantly this bypasses the security guarantee we've had with the
>> default of uploadpack.allowAnySHA1InWant=false.
>
> IMHO those security guarantees there are overrated (due to delta
> gue
-comments
Signed-off-by: Jonathan Nieder
---
builtin/stripspace.c | 3 ++-
t/t0030-stripspace.sh | 12 +---
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/builtin/stripspace.c b/builtin/stripspace.c
index bdf0328869..be33eb83c1 100644
--- a/builtin/stripspace.c
+++ b/builtin
Hi,
Farhan Khan wrote:
>> Farhan Khan wrote:
>>> I am having trouble figuring out the boundary between two objects in
>>> the pack file.
[...]
> I think the issue is, the compressed object has a fixed
> size and git inflates it, then moves on to the next object. I am
> trying to figu
ct.
For comparison, with javascript-actions disabled, clicking on line
numbers loads the previous version of the line.
Addresses https://bugs.debian.org/741883.
Signed-off-by: Jonathan Nieder
---
Hi Robert,
Years ago, you sent this obviously correct patch to the link mentioned
above, but it got
Hi,
Farhan Khan wrote:
> I am trying to write an implementation of "git index-pack" and having
> a bit of trouble with understanding the ".pack" format. Specifically,
> I am having trouble figuring out the boundary between two objects in
> the pack file.
Have you seen Documentation/technical/pac
Jeff King wrote:
> On Fri, Dec 14, 2018 at 12:36:21AM -0800, Jonathan Nieder wrote:
>> Jeff King wrote:
>>> In protocol v2, instead of just running "upload-pack", we have a generic
>>> "serve" loop which runs command requests from the client. Wha
Hi,
Jeff King wrote:
> In protocol v2, instead of just running "upload-pack", we have a generic
> "serve" loop which runs command requests from the client. What used to
> be "upload-pack" is now generally split into two operations: "ls-refs"
> and "fetch". The latter knows it must respect uploadp
William Hubbs wrote:
> Is the git team on an irc channel somewhere,
Some like to use #git-devel on freenode.
> or should I start sending
> patches that I know are incomplete to the list?
Yeah, that's fine. Include [WIP/PATCH] in the subject line to
Hi,
Frank Dana wrote:
> The documentation for the feature 'snapshot' claimed
> "This feature can be configured on a per-repository basis via
> repository's `gitweb.blame` configuration variable"
>
> Fixed to specify `gitweb.snapshot` as the variable name.
> ---
> Documentation/gitweb.conf.txt |
Hi,
Jonathan Tan wrote:
> (The implementation in this commit reads the commit message twice even
> if there is no commit-msg hook. I think that this is fine, since this is
> for interactive use - an alternative would be to plumb information about
> the absence of the hook from run_hook_ve() upwar
William Hubbs wrote:
> On Thu, Dec 06, 2018 at 11:20:07PM +0100, Johannes Schindelin wrote:
>> There *is* a way to get what you want that is super easy and will
>> definitely work: if you sit down and do it ;-)
>>
>> Please let us know if you need any additional information before you can
>> start
Ævar Arnfjörð Bjarmason wrote:
> On Fri, Dec 07 2018, Jonathan Nieder wrote:
>> The patch-id appears to only care about the diff text, so it should be
>> able to handle this. So if we have a better heuristic for where the
>> diff starts, it would be good to use it.
>
&g
Hi,
Stefan Beller wrote:
> What would be more of interest is why we'd be interested in this patch
> as there is no commit/patch sent by Brandon with this email in gits history.
I think there's an implicit assumption in this question that isn't
spelled out. Do I understand correctly that you're
Hi,
Konstantin Ryabitsev wrote:
> Every now and again I come across a patch sent to LKML without a leading
> "diff a/foo b/foo" -- usually produced by quilt. E.g.:
>
> https://lore.kernel.org/lkml/20181125185004.151077...@linutronix.de/
>
> I am guessing quilt does not bother including the leadin
Brandon Williams wrote:
> Signed-off-by: Brandon Williams
> ---
> .mailmap | 1 +
> 1 file changed, 1 insertion(+)
I can confirm that this is indeed the same person.
Reviewed-by: Jonathan Nieder
Welcome back!
Martin Mares wrote[1]:
> After upgrade to Stretch, gitweb no longer finds the configuration file
> "gitweb_config.perl" in the current directory. However, "man gitweb" still
> mentions this as one of the possible locations of the config file (and
> indeed a useful one when using multiple instances
Stefan Beller wrote:
> On Mon, Dec 3, 2018 at 3:23 PM Jonathan Nieder wrote:
>> I was curious about what versions of Gerrit this is designed to
>> support (or in other words whether it's a bug fix or a feature).
>> Looking at examples like [1], it seems that Gerrit h
Jonathan Nieder wrote:
> Stefan Beller wrote:
>> /*
>> * Match case insensitively, so we colorize output from existing
>> @@ -95,7 +95,8 @@ static void maybe_colorize_sideband(struct strbuf *dest,
>> const char *src, int n)
>>
grep "hint:" decoded &&
> grep "success:" decoded &&
> + grep "SUCCESS" decoded &&
> grep "warning:" decoded
> '
Nice tests.
The "hinting: not highlighted" example shows that we aren't
introducing false positives here, so the coverage seems sufficient.
It might be nice to include a line
echo ERROR:
as well to match another idiom that Gerrit sometimes uses.
Reviewed-by: Jonathan Nieder
Thanks again for a pleasant read.
Hi,
Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason writes:
>>> Given that we're still finding regressions bugs in the rebase-in-C
>>> version should we be considering reverting 5541bd5b8f ("rebase: default
>>> to using the builtin rebase", 2018-08-08)?
>>>
>>> I love the feature, but fear that
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> I don't *think* you intend to say "sure, you got user reports, but
>> (those users are wrong | those users are not real | you are not
>> interpreting those users correctly)", but that is what I am hearing.
&g
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Now, a meta point. Throughout this discussion, I have been hoping for
>> some acknowledgement of the problem --- e.g. an "I am sympathetic to
>> what you are trying to do, but ". I wasn't able to fi
Stefan Xenos wrote:
> Jonathan Nieder wrote:
>> putting it in the commit message is a way to
>> experiment with the workflow without changing the object format
>
> As long as we're talking about a temporary state of affairs for users
> that have opted in, and we
Junio C Hamano wrote:
> This series has a strong smell of pushing back by the
> toolsmiths who refuse to promptly upgrade to help their users, and
> that is why I do not feel entirely happy with this series.
Last reply, I promise. :)
This sentence might have the key to the misunders
onathan Nieder wrote:
> Junio C Hamano wrote:
>> I am still puzzled by the insistence of 3/5 and this step that wants
>> to kill the coalmine canary. But I am even more puzzled by the
>> first two steps that want to disable the two optional extensions.
[...]
> I acknowledge your puzzlement. I'm
Hi,
Junio C Hamano wrote:
> I am still puzzled by the insistence of 3/5 and this step that wants
> to kill the coalmine canary. But I am even more puzzled by the
> first two steps that want to disable the two optional extensions.
>
> What's so different this time with the new optional extensions
Stefan Xenos wrote:
> On Tue, Nov 20, 2018 at 1:43 AM Ævar Arnfjörð Bjarmason
> wrote:
>> I think it sounds better to just make it, in the header:
>>
>> x-evolve-pt content
>> x-evolve-pt obsolete
>> x-evolve-pt origin
>>
>> Where "pt = parent-type", we could of course spell that out
Hi,
Sven Strickroth wrote:
> Subject: .mailmap: record canonical email address for Sven Strickroth
>
> Signed-off-by: Sven Strickroth
> ---
> .mailmap | 2 ++
> 1 file changed, 2 insertions(+)
Thanks for taking care of it.
[...]
> --- a/.mailmap
> +++ b/.mailmap
> @@ -235,6 +235,8 @@ Steven G
Helped-by: Junio C Hamano
Signed-off-by: Jonathan Nieder
---
New, based on Junio's hints about the message removed in patch 3/5.
That's the end of the series. Thanks for reading, and thanks again
for your help so far.
advice.c | 2 ++
advice.h | 1 +
read-cache.c | 11
s.
Helped-by: Ben Peart
Signed-off-by: Jonathan Nieder
---
New, based on Ben Peart's feedback. Turned out simpler than I feared
--- thanks, Ben, for pushing for this.
Documentation/config/index.txt | 6 --
config.c | 17 ++---
config.h
index] recordOffsetTable' configuration variable to
control whether the new index extension is written.
Signed-off-by: Jonathan Nieder
---
As with patch 1/5, no change from v1 other than rebasing.
Documentation/config/index.txt | 7 +++
read-cache.c | 11 ++-
2 files c
) we can turn on new optional extensions right
away without alarming people.
Signed-off-by: Jonathan Nieder
---
Unchanged.
read-cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/read-cache.c b/read-cache.c
index f3d5638d9e..83d24357a6 100644
--- a/read-cache.c
+++ b/rea
users are using such a version, we can flip the
default to writing it by default.
Introduce a '[index] recordEndOfIndexEntries' configuration variable
to allow interested users to benefit from this index extension early.
Signed-off-by: Jonathan Nieder
---
Rebased. No other change f
kinds
welcome, as always.
Sincerely,
Jonathan Nieder (5):
eoie: default to not writing EOIE section
ieot: default to not writing IEOT section
index: do not warn about unrecognized extensions
index: make index.threads=true enable ieot and eoie
index: offer advice for unknown index extensions
Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 15 2018, sxe...@google.com wrote:
>> +Parent-type
>> +---
>> +The “parent-type” field in the commit header identifies a commit as a
>> +meta-commit and indicates the meaning for each of its parents. It is never
>> +present for normal commits.
[.
Hi,
Stefan Xenos wrote:
> But since several comments have focused on the commands, let's brainstorm!
>
> Here's some options that occur to me:
>
> 1. Three commands: evolve + change + obslog as top-level commands (the
> current proposal). Change gets a bunch of subcommands for manipulating
> the
Hi,
Xenos wrote:
> Lets explore the "when" question. I think there's a compelling reason
> to add them as soon as possible - namely, gerrit. If and when we come
> to some sort of agreement on this proposal, gerrit could start adding
> tooling to understand change graphs as an alternative to chang
Ævar Arnfjörð Bjarmason wrote:
> On Mon, Nov 19 2018, Derrick Stolee wrote:
>> [...]
>> builtin/rebase.c
>> 62c23938fa 55) return env;
>> [...]
>> Ævar Arnfjörð Bjarmason 62c23938f: tests: add a special setup
>> where rebase.useBuiltin is off
>
> This one would be covered with
> GIT_TEST_REBASE_US
Hi!
yanke131...@gmail.com wrote:
> From: out0fmemory
>
> ---
> INSTALL | 7 +++
> 1 file changed, 7 insertions(+)
Thanks for writing. A few bits of administrivia, from
https://www.kernel.org/pub/software/scm/git/docs/SubmittingPatches.html:
Can we forge your sign-off? See the section "
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> 1. Using multiple versions of Git on a single machine. For example,
>> some IDEs bundle a particular version of Git, which can be a
>> different version from the system copy, or on a Mac, /usr/bin/git
>>
Hi,
Ben Peart wrote:
> There is no way to get multi-threaded reads and NOT get the scary message
> with older versions of git. Multi-threaded reads require the IEOT extension
> to be written into the index and the existence of the IEOT extension in the
> index will always generate the scary warn
+git@vger.kernel.org, git-secur...@googlegroups.com -> bcc
Paul J Sanchez wrote:
> On Nov 13, 2018, at 2:25 PM, Stefan Beller wrote:
>> The link seems to be https://aurees.com/ ?
>>
>> They seem to have
>> https://aurees.com/legal/license-agreement
>> which is a hilarious read:
>>
>> You agree th
Elijah Newren wrote:
> Actually, no, it actually needs to be inconsistent.
>
> Different Input Choices (neither backslashed, both backslashed, then just
> one):
> master~9 and master~10
> master\~9 and master\~10
> master\~9 and master~10
>
> What the outputs look like:
> master9 and mast
+cc: git@vger.kernel.org, git-secur...@googlegroups.com -> bcc
Hi!
Paul J Sanchez wrote:
> Over the weekend I saw a link to a Mac git client I had not seen
> before: Aurees. When I went to the linked site to download a copy,
> my antivirus software (Sophos) warned me that it contains malware.
>
Hi again,
Ben Peart wrote:
> On 11/13/2018 1:18 PM, Jonathan Nieder wrote:
>> Ben Peart wrote:
>>> Why introduce a new setting to disable writing the IEOT extension instead of
>>> just using the existing index.threads setting? If index.threads=1 then the
>>>
Hi,
Ben Peart wrote:
> While I can understand the user confusion the warning about ignoring an
> extension could cause I guess I'm a little surprised that people would see
> it that often. To see the warning means they are running a new version of
> git in the same repo as they are running an ol
Hi,
Ben Peart wrote:
> On 11/12/2018 7:39 PM, Jonathan Nieder wrote:
>> As with EOIE, popular versions of Git do not support the new IEOT
>> extension yet. When accessing a Git repository written by a more
>> modern version of Git, they correctly ignore the unrecognized s
Hi again,
Junio C Hamano wrote:
> Then removing the message is throwing it with bathwater. First
> think about which part of the message is confusiong and then make it
> less confusing.
>
> How about
>
> hint: ignoring an optional IEOT extension
>
> to make it clear that it is totally harm
Junio C Hamano wrote:
> How about
>
> hint: ignoring an optional IEOT extension
>
> to make it clear that it is totally harmless?
>
> With that, we can add advise.unknownIndexExtension=false to turn all
> of them off with a single switch.
I like it. Expect a patch soon (tonight or tomorrow
) we can turn on new optional extensions right
away without alarming people.
Signed-off-by: Jonathan Nieder
---
Thanks for reading. Thoughts?
Sincerely,
Jonathan
read-cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/read-cache.c b/read-cache.c
index 290bd54708..655
index] recordOffsetTable' configuration variable to
control whether the new index extension is written.
Signed-off-by: Jonathan Nieder
---
Documentation/config.txt | 7 +++
read-cache.c | 11 ++-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/Documentation/co
users are using such a version, we can flip the
default to writing it by default.
Introduce a '[index] recordEndOfIndexEntries' configuration variable
to allow interested users to benefit from this index extension early.
Signed-off-by: Jonathan Nieder
---
Documentation/config.txt | 7 +
Offset Table (IEOT) extension
> read-cache: load cache entries on worker threads
I love this, but when deploying it I ran into a problem.
How about these patches?
Thanks,
Jonathan Nieder (3):
eoie: default to not writing EOIE section
ieot: default to not writing IEOT section
index: do not wa
Hi Fredi,
Fredi Fowler wrote:
> Is there any way to create pull request to git man (https://git-scm.com/docs)?
>
> I found there some inconsistencies. For example, almost in all pages
> are using [no-], but at https://git-scm.com/docs/git-merge each
> command (with [no-] or without) write separat
Hi,
Duy Nguyen wrote:
> On Mon, Nov 5, 2018 at 2:02 AM brian m. carlson
> wrote:
>> There are basically two approaches I can take. The first is to provide
>> each command that needs to learn about this with its own --hash
>> argument. So we'd have:
>>
>> git init --hash=sha256
>> git show-
Hi,
Ævar Arnfjörð Bjarmason wrote:
>> On Mon, Oct 29, 2018 at 3:09 PM Junio C Hamano wrote:
>>> SZEDER Gábor writes:
Nguyễn Thái Ngọc Duy wrote:
> -fprintf(stderr, "%s in %s %s: %s\n",
> -msg_type, printable_type(obj), describe_object(obj), err);
> +fprintf_
Stefan Beller wrote:
> Maybe for now we can do with just an update of the documentation/bugs
> section and say we cannot move files in and out of submodules?
I think we have some existing logic to prevent "git add"-ing a file
within a submodule to the superproject, for example.
So "git mv" shoul
Junio C Hamano wrote:
> Jonathan Tan writes:
>> Jonathan Nieder wrote:
>>> [object]
>>> missingObjectRemote = local-cache-remote
>>> missingObjectRemote = origin
>>
>> In the presence of missingObjectRemote, old vers
to
make coverage-test
make coverage-report
would be useful to readers finding this commit later.
> To be applied on (or squashed into the tip of)
> sb/submodule-update-in-c
Looks like that's already in "master", so not a candidate for
squashing.
Reviewed-by: Jonathan Nieder
Hi,
Christian Hesse wrote:
> --- a/contrib/subtree/Makefile
> +++ b/contrib/subtree/Makefile
> @@ -69,11 +69,11 @@ install: $(GIT_SUBTREE)
[...]
> -install-html: $(GIT_SUBTREE_HTML)
> +install-html: html
This broke the build for me:
make[2]: Entering directory '/build/git-2.19.1+next.20181016/
SZEDER Gábor wrote:
> On Tue, Oct 16, 2018 at 02:54:56PM -0700, Jonathan Nieder wrote:
>> SZEDER Gábor wrote:
>>> Our Makefile has lines like these:
>>>
>>> CFLAGS = -g -O2 -Wall
>>> CC = cc
>>> AR = ar
>>> SPATCH = spatch
[..
Hi,
SZEDER Gábor wrote:
> Our Makefile has lines like these:
>
> CFLAGS = -g -O2 -Wall
> CC = cc
> AR = ar
> SPATCH = spatch
>
> Note the use of '=', not '?='.
[...]
> I'm not sure what to do. I'm fine with updating our 'ci/' scripts to
> explicitly respect CC in the environment (either
Stefan Beller wrote:
> Reported-by: Jaewoong Jung
> Signed-off-by: Stefan Beller
> ---
> builtin/submodule--helper.c | 51 -
> t/t7400-submodule-basic.sh | 24 +
> 2 files changed, 58 insertions(+), 17 deletions(-)
Rev
Hi Christian,
On Tue, Sep 25, 2018, Christian Couder wrote:
> In the cover letter there is a "Discussion" section which is about
> this, but I agree that it might not be very clear.
>
> The main issue that this patch series tries to solve is that
> extensions.partialclone config option limits the
free(url);
> - url = relurl;
> + char *to_free = url;
> + url = compute_submodule_clone_url(url);
> + free(to_free);
I still think this would be easier to read with a style that makes
the ownership passing clearer:
char *oldurl = url;
url = compute_submodule_clone_url(oldurl);
free(oldurl);
With whatever subset of the above tweaks makes sense,
Reviewed-by: Jonathan Nieder
Thanks.
Josh Steadmon wrote:
> On 2018.10.12 16:32, Jonathan Nieder wrote:
>> Josh Steadmon wrote:
>>> For now, I'm going to try adding an --allowed_versions flag for the
>>> remote helpers, but if anyone has a better idea, let me know.
>>
>> I forgot to
Josh Steadmon wrote:
> For now, I'm going to try adding an --allowed_versions flag for the
> remote helpers, but if anyone has a better idea, let me know.
I forgot to mention: the stateless-connect remote helper capability is
still experimental so you're free to change its interface (e.g. to
chan
Hi,
Josh Steadmon wrote:
> So this runs into problems with remote-curl (and possibly other remote
> helpers):
>
> builtin/push.c can declare whatever allowed versions it wants, but those
> are not carried over when remote-curl is started to actually talk to the
> remote. What's worse, remote-curl
Hi,
Stefan Beller wrote:
> The submodule helper update_clone called by "git submodule update",
> clones submodules if needed. As submodules used to have the URL indicating
> if they were active, the step to resolve relative URLs was done in the
> "submodule init" step. Nowadays submodules can be
Jeff King wrote:
> On Fri, Oct 12, 2018 at 07:40:37PM +0100, Thomas Gummerer wrote:
>> 801fa63a90 ("config.mak.dev: add -Wformat-security", 2018-09-08) added
>> the -Wformat-security to the flags set in config.mak.dev. In the gcc
>> man page this is documented as:
>>
>> If -Wformat is sp
Hi,
Stefan Beller wrote:
> This applies on nd/the-index (b3c7eef9b05) and is the logical continuation of
> the object store series, which I sent over the last year.
>
> The previous series did take a very slow and pedantic approach,
> using a #define trick, see cfc62fc98c for details, but it turn
Hi,
Derrick Stolee wrote:
> commit-reach.c| 4 +++-
> t/t6600-test-reach.sh | 2 +-
> 2 files changed, 4 insertions(+), 2 deletions(-)
I like this testing technique, and the test passes for me.
Except: if I put
CC = cc -m32
NO_OPENSSL = YesPlease
NO_CURL = YesP
Ævar Arnfjörð Bjarmason wrote:
> Which is what I'm doing by running "gc --auto" across a set of servers
> and looking at the exit code. If it's been failing I get an error, if
> there's no need to gc nothing happens, and if it hasn't been failing and
> it just so happens that it's time to GC then
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Perhaps this reporting could also print the message from a previous
>> run, so you could write:
>>
>> git gc --detached-status || exit
>> git gc --auto; # perhaps also passing --detach
>>
Ævar Arnfjörð Bjarmason wrote:
> Right. I know. What I mean is now I can (and do) use it to run 'git gc
> --auto' across our server fleet and see whether I have any of #3, or
> whether it's all #1 or #2. If there's nothing to do in #1 that's fine,
> and it just so happens that I'll
Hi,
Ævar Arnfjörð Bjarmason wrote:
> Add an --auto-exit-code variable and a corresponding 'gc.autoExitCode'
> configuration option to optionally bring back the 'git gc --auto' exit
> code behavior as it existed between 2.6.3..2.19.0 (inclusive).
Hm. Can you tell me more about the use case where
Hi,
Ævar Arnfjörð Bjarmason wrote:
> I'm just saying it's hard in this case to remove one piece without the
> whole Jenga tower collapsing, and it's probably a good idea in some of
> these cases to pester the user about what he wants, but probably not via
> gc --auto emitting the same warning eve
Jeff King wrote:
> On Fri, Aug 17, 2018 at 10:26:05PM -0700, Jonathan Nieder wrote:
>> - testsvn:: is a demo and at a minimum we ought not to install it
>>with "make install"
>>
>> - keeping this in-tree for the benefit of just one user is excessive,
Hi,
Jeff King wrote:
> On Tue, Oct 02, 2018 at 11:43:50AM +0200, Stanisław Drozd wrote:
>> I'm trying to write a fast-import-based git remote helper, but I'm not
>> sure what the output of the `list` command should look like. How can I
>> find an example of the format in action?
>
> There's some
Jonathan Nieder wrote:
> Junio C Hamano wrote:
>> OK. This unfortunately came a bit too late for today's integration
>> cycle, so I'll leave this in my inbox and replace what is queued
>> with it later.
>>
>> Unless there is another one to supersede
101 - 200 of 3146 matches
Mail list logo