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()
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
>>
Æ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
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
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 histor
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)
>>
d &&
> + 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
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.
>
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 find th
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're
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
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
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
t.
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 +++
3 fil
elped-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 |
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/read-cache.c
@@ -1726,7
] 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 changed, 17
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 from v1.
As Jonathan
come, 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
Document
Æ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
Æ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
>
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
+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
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
+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
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
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
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
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..65530a68c2 100644
] 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/config.txt b
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 +++
read-cache.c
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
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
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);
> +
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"
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
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
= 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 menti
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
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,
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
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
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 =
Æ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
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
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
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 excess
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 this prop
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 this proposal comes before
> that happens, that is.
>
> Thanks.
Sounds
-by: Martin Ågren
Improved-by: Junio C Hamano
Signed-off-by: Jonathan Nieder
---
Junio C Hamano wrote:
>> Jonathan Nieder wrote:
>>> Hm. I think this encourages a behavior that I want to discourage:
>>> assuming that if a bug has already been reported then there's nothing
&
Ævar Arnfjörð Bjarmason wrote:
> On Thu, Sep 27 2018, Jonathan Nieder wrote:
>> That said, that seems to me like a lot of work to avoid adding some
>> patches to "next" that belong in "next" anyway. I understand why the
>> Git for Windows maintai
Hi,
Stefan Beller wrote:
> There are different opinions on how to document an API properly.
> Discussion turns out nobody disagrees with documenting new APIs on the
> function level in the header file and high level concepts in
> Documentation/technical, so let's state that in the guidelines.
I
(dropping cc-s to my internal address that I don't use on this list
and to git-c...@google.com which bounces)
Hi,
Stefan Beller wrote:
> Internally we have rolled out this as an experiment for
> "submodules replacing the repo tool[1]". The repo tool is described as:
>
> Repo unifies Git
Stefan Beller wrote:
> On Wed, Sep 26, 2018 at 6:25 PM Josh Steadmon wrote:
>> I've been discussing workarounds for this with Jonathan Nieder, but
>> please let me know if you have any suggestions for v3 of this series.
>
> Care to open the discussion to the list? W
Hi,
Ævar Arnfjörð Bjarmason wrote:
> So it's similar to various packages that have "alternates" and are semi
> or permanently forked, like emacs & xemacs, JDK etc., although I can't
> recall one offhand that's quite similar to GFW v.s. git.git.
>
> My only stake in this is I thought it would be
Ævar Arnfjörð Bjarmason wrote:
> GFW is a "friendly fork", but a permanent one it seems. The diff between
> it and 2.19.0 proper is ~10k lines, and e.g. this last release had
> experimental stash/rebase in C that 2.19.0 didn't.
>
> So it would be great if this were packaged up by linux distro as
Hi,
Martin Ågren wrote:
> --- a/Documentation/git.txt
> +++ b/Documentation/git.txt
> @@ -859,6 +859,9 @@ Reporting Bugs
> Report bugs to the Git mailing list where the
> development and maintenance is primarily done. You do not have to be
> subscribed to the list to send a message there.
>
Hi,
Jeff King wrote:
> On Wed, Sep 26, 2018 at 10:44:33PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> In terms of getting an overview it's indistinguishable from
>> comments. I.e. there's nothing like an index of:
>>
>> man git-api-strbuf ==> working with strings
>> man
brian m. carlson wrote:
> On Mon, Sep 24, 2018 at 10:39:02AM -0700, Jonathan Nieder wrote:
>> brian m. carlson wrote:
>>> I think this commit message makes sense.
[...]
>> What would it take to make the patch make
>> sense, too? ;
to produce a list of changes in each version,
grouped by author's (normalized) name.
Signed-off-by: Jonathan Nieder
---
Hi,
brian m. carlson wrote:
> I think this commit message makes sense. I apparently still fail to
> understand how the .mailmap format works, so I can't tell you if the
>
Hi,
A quick note.
Joan Daemen wrote:
> when going over my todo list I was confronted with the mail of Dan
> Shumow on the successor of SHA-1 for git. I know the decision was
> made and it is not my intention to change it, but please see below
> some comments on Dan's arguments.
When the time
(+cc: Taylor Blau, git-lfs expert)
Randall S. Becker wrote:
> On September 17, 2018 3:28 PM, Jonathan Nieder wrote:
>> Randall S. Becker wrote:
>>> Does anyone know whether it is practical to rework git-lfs under a
>>> language other than "go"? GCC is not eve
Thomas Gummerer wrote:
> On 09/17, Junio C Hamano wrote:
>> The other
>> effort implicitly depends on the expected output is kept sorted, but
>> this one is more explicit---I tend to prefer this approach as tools
>> and automation is easier
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> I'd rather that we revert this change altogether. I have nothing
>> against a convenient command to do this kind of non build related
>> cleanup, but it shouldn't be spelled as "make clean".
>
> OK, let's
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Eric Sunshine wrote:
>>> + '$(SHELL_PATH_SQ)' ./doc-diff --clean
>>
>> This means I need a copy of git in order to run "make clean". That
>> was never required before. It makes bootstrapping d
Hi,
Randall S. Becker wrote:
> Does anyone know whether it is practical to rework git-lfs under a language
> other than "go"? GCC is not even close to being possible to port to my
> NonStop platform (may have tried, some have died - joke - trying). I would
> like to convert this directly to C
Thomas Gummerer wrote:
> Currently the 'compute_assignment()' function may read memory out
> of bounds, even if used correctly. Namely this happens when we only
> have one column.
[...]
> Reported-by: ryenus
> Helped-by: Derrick Stolee
> Signed-off-by: Thomas Gummerer
> ---
>
Hi,
Jeff King wrote:
> On Tue, Jul 17, 2018 at 03:59:47PM -0400, Jeff King wrote:
>> On Mon, Jul 16, 2018 at 11:54:16PM -0700, Jonathan Nieder wrote:
>>> A value of -1 returned from cmd_gc gets propagated to exit(),
>>> resulting in an exit status of 255. Use die inst
Hi,
Eric Sunshine wrote:
> doc-diff creates a temporary working tree (git-worktree) and generates a
> bunch of temporary files which it does not remove since they act as a
> cache to speed up subsequent runs. Although doc-diff's working tree and
> generated files are not strictly build products
Jeff King wrote:
> Let me inject some more uncertainty, then. ;)
>
> If we are not going to do 3/3, then should 2/3 simply avoid passing "-1"
> back via return from main? I guess I don't have a strong opinion, but
> one of the things I noted was that we converted those die() calls
> introduced in
to produce a list of changes in each version,
grouped by author's (normalized) name.
Signed-off-by: Jonathan Nieder
---
brian m. carlson wrote:
> On Tue, May 22, 2018 at 03:08:26PM -0700, Jonathan Nieder wrote:
>> These commits use author Brian M. Carlson .
>> Previou
Matthew DeVore wrote:
> Subject: t/*: fix pipe placement and remove \'s
>
> Where ever there was code in the tests like this:
>
> foo \
> | bar
Language nits:
- s/Where ever/Wherever/
- Git's commit messages use the present tense to describe the existing
previous state of
Taylor Blau wrote:
> On Sun, Sep 16, 2018 at 03:05:48PM -0700, Jonathan Nieder wrote:
> > On Sun, Sep 16, 2018 at 11:17:27AM -0700, John Austin wrote:
> > > Taylor Blau wrote:
>>>> Right, though this still subjects the remote copy to all of the
>>>> d
On Mon, Sep 17, 2018 at 03:27:21AM +0200, Chris Coutinho wrote:
> On Sep-16-18, Jonathan Nieder wrote:
>> Chris Coutinho wrote:
>>> Currently my gitconfig contains the following line:
>>>
>>> sendemail.smtpserveroption=-a
>>>
>>> Whereas,
Hi,
Chris Coutinho wrote:
> Currently my gitconfig contains the following line:
>
> sendemail.smtpserveroption=-a
>
> Whereas, the following results in an 'account' not found error:
>
> sendemail.smtpserveroption=-a
Do you mean that your ~/.gitconfig literally contains that exact
Hi,
On Sun, Sep 16, 2018 at 11:17:27AM -0700, John Austin wrote:
> Taylor Blau wrote:
>> Right, though this still subjects the remote copy to all of the
>> difficulty of packing large objects (though Christian's work to support
>> other object database implementations would go a long way to help
1 - 100 of 2895 matches
Mail list logo
