Hi,
A few small points.
Vegard Nossum wrote:
> * git am (or an alternative command) needs to recreate the commit
> perfectly when applied, including applying it to the correct parent
Interesting. "git format-patch" has a --base option to do some of
what you're looking for, for the sake of sn
Eric Wong wrote:
> Konstantin Ryabitsev wrote:
>> This is actually really fast if you already have a local copy of the
>> repository with most objects. Try this yourself if you have
>> torvalds/linux.git locally:
>>
>> git clone --bare -s torvalds/linux.git test
>
> Yep, -s (--shared) makes cloni
(+cc: git)
Hi,
Konstantin Ryabitsev wrote[1]:
> How I envision this would work:
>
> - user creates an account (which requires a mail confirmation)
> - they choose a "submit patch" option from the menu
> - the patch submission screen has a succession of screens:
Interesting! This reminds me a bi
Hi,
Andrew Donnellan wrote:
> To avoid triggering spam filters due to failed signature validation, many
> mailing lists mangle the From header to change the From address to be the
> address of the list, typically where the sender's domain has a strict DMARC
> policy enabled.
>
> In this case, we
Hi!
Dominik Salvet wrote:
> 1) `git fetch origin && git remote set-head origin -a`
> 2) `git fetch origin +refs/heads/*:refs/remotes/origin/*
> HEAD:refs/remotes/origin/HEAD`
> 3) instead of git init and remote, use directly `git clone --no-checkout`
>
> The first solution is not suitable due its
ould see once such a series
> lands).
Acked-by: Jonathan Nieder
Thanks for your thoughtful work.
Jonathan Tan wrote:
> This was raised by a coworker at $DAYJOB. I run the following script:
[reproduction recipe from (*) snipped]
> The cherry-pick must be manually resolved, when I would expect it to
> happen without needing user intervention.
>
> You can see that at the point of the cherry-pick
SZEDER Gábor wrote:
> On Mon, Sep 16, 2019 at 11:42:08AM -0700, Emily Shaffer wrote:
>> - try and make progress towards running many tests from a single test
>>file in parallel - maybe this is too big, I'm not sure if we know how
>>many of our tests are order-dependent within a file for n
(+cc: Thomas Gummerer)
Hi Johannes,
Johannes Schindelin wrote:
> On Fri, 13 Jul 2018, Jonathan Nieder wrote:
>> Some of us have been informally doing a "git standup" on #git-devel on
>> irc.freenode.net on IRC every two weeks at 17:00-17:30 UTC. It's a
>>
XP_QPAT in subevalvar, 2013-08-23).
Signed-off-by: Jonathan Nieder
---
t/test-lib-functions.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 7860491660..de58e8b502 100644
--- a/t/test-lib-functions.sh
+++ b/t/te
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Lukas Gross wrote:
>>> I had intended to stage commits but forgot to do so. Git responded
>>> with a normal commit creation message, so I pushed to the remote to
>>> begin a CI build. When the build failed
Lukas Gross wrote:
> I had intended to stage commits but forgot to do so. Git responded
> with a normal commit creation message, so I pushed to the remote to
> begin a CI build. When the build failed for the same reason, I
> realized I had forgotten to stage the changes. An additional line in
> th
(administrivia: please don't top-post)
Lukas Gross wrote:
> I had intended to stage commits but forgot to do so. Git responded
> with a normal commit creation message, so I pushed to the remote to
> begin a CI build. When the build failed for the same reason, I
> realized I had forgotten to stage
Hi,
Lukas Gross wrote:
> I have occasionally used git commit --amend without staging any
> changes or modifying the commit message (--no-edit). Since this is
> often done unintentionally, could amend warn when it is being used in
> this way?
Can you say more about the context? What were you try
Hi,
Kyohei Kadota wrote:
> I think it is possible to replace rc with ape/sh, ape/sh is POSIX
> shell in Plan 9.
>
> However Plan 9 don't have recent versions of Unix tools,
> such as gcc, g++, autotools, gmake or perl,
> so it is VERY hard to use Makefile instead of mkfile.
The default Git build
SZEDER Gábor wrote:
> On Fri, Aug 02, 2019 at 09:59:13AM -0700, Jonathan Nieder wrote:
>> In the short term, we can run tests internally to check that Git keeps
>> following the schema. Let's not block patches 1 and 2 by this ---
>
> To my understanding patch 2 is o
SZEDER Gábor wrote:
> On Thu, Aug 01, 2019 at 06:52:47PM -0700, Jonathan Nieder wrote:
>> Gábor, if we introduce such a parameter, do you think it would make
>> sense for us to set up a worker that passes it?
>
> That would be even worse than the current approach of the third
Hi,
Johannes Schindelin wrote:
> On Thu, 1 Aug 2019, Jonathan Nieder wrote:
>> What do you think of making the validation disabled by default and
>> using a parameter (see "Running tests with special setups" in
>> t/README) to turn it on? That way, it should be ok
(cc: Duy, who might enjoy this walk through history)
Hi,
Alexander Mills wrote:
> git clone --single-branch=
>
> doesn't seem to work?
I've occasionally wanted something like this (actually, I've wanted to
pass a refname like "refs/meta/config"). builtin/clone.c contains
static struct
Hi,
Bryan Turner wrote:
> Promisor remotes and other in-flight changes might help provide some
> of what you're looking for, but I'm not aware of any already-available
> solution.
You can do
git clone --no-checkout --filter=blob:none $url repo
cd repo
git checkout $commi
). We can simplify further by removing the "-1" case --- we do
not need to distinguish between "on" and "unspecified" any more.
We'll also want to update the docs. And as Todd suggests, we should
cover how to disable mailmap in tests.
Signed-off-by: Jonathan Nied
Josh Steadmon wrote:
> On 2019.07.26 15:03, Josh Steadmon wrote:
>> [ajv-cli] can validate the full 1.7M line trace output in just over a
>> minute. Moreover, it has helpful output when validation fails. So I
>> would be happy to re-implement this using ajv-cli.
>
> Unfortunately, ajv on Travis is
Jeff King wrote:
> This seems OK to me, though I kind of wonder if anybody really wants
> "auto".
Sure. It's just the usual way of handling the lack of support for an
"unset" directive in git's config syntax (for example, if a script
author wants to test the default behavior).
Thanks,
Jonathan
w log.mailmap setting "auto" that can be used to
explicitly request the new automatic behavior (so that e.g. if
log.mailmap is set to "true" system-side, I can set it to "auto" in my
per-user configuration).
Reported-by: Johannes Schindelin
Signed-of
(cc: René Scharfe, "git archive" expert)
Matt Turner wrote:
> tar2sqfs (part of https://github.com/topics/tar2sqfs) rejects tarballs
> made with git archive with the message
>
> invalid tar header checksum!
>
> tar2sqfs recomputes the tarball's checksum to verify it. Its checksum
> implementat
APH=1
> export GIT_TEST_MULTI_PACK_INDEX=1
> make test
> -fi
> + ;;
> +linux-gcc-4.8)
> + # Don't run the tests; we only care about whether Git can be
> + # built with GCC 4.8, as it errors out on some undesired (C99)
> + # constructs that newer compilers seem to quietly accept.
> + ;;
> +*)
> + make test
> + ;;
> +esac
Does what it says on the tin.
Reviewed-by: Jonathan Nieder
at it, extend the existing variable declaration rule a bit to
> read better with the newly spelled out rule for the for loop.
>
> Signed-off-by: Junio C Hamano
> ---
> Documentation/CodingGuidelines | 25 ++---
> 1 file changed, 22 insertions(+), 3 deletions(-)
Reviewed-by: Jonathan Nieder
Thanks.
ning of the block, before
> + the first statement (i.e. -Wdeclaration-after-statement).
> +
> + - Declaring a variable in the for loop "for (int i = 0; i < 10; i++)"
> + is still not allowed in this codebase.
Nice.
Reviewed-by: Jonathan Nieder
Thanks.
t would be nice to use -std=gnu99 for better consistency
between gcc versions, but it's moot here: avoiding the declaration in
for loop initializer is more consistent with
-Wdeclaration-after-statement anyway.
Reviewed-by: Jonathan Nieder
Thanks.
Anton Ermolenko wrote:
> My understanding is that recursive merge here won't consider that situation to
> be a merge conflict as the changes have been introduced in different spots in
> the file.
Yes, that seems right to me.
Do you have more details about the context? What do these files look
l
Hi,
Matthew DeVore wrote:
> On Sun, Jun 09, 2019 at 10:17:19AM +0200, Johannes Schindelin wrote:
>> I find that it makes sense in general to suppress one's urges regarding
>> introducing `{ ... }` around one-liners when the patch does not actually
>> require it.
>>
>> For example, I found this pa
+--
> t/t5616-partial-clone.sh | 61
> 2 files changed, 85 insertions(+), 2 deletions(-)
Thanks much.
This bugfix has been working well at $DAYJOB:
Tested-by: Jonathan Nieder
Is it something that could be in 2.22.0 or 2.22.1?
ticed when testing against a
> JGit server implementation, which follows the documentation in this
> regard.
>
> Signed-off-by: Jonathan Tan
> ---
> fetch-pack.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Oh, dear. Thanks for fixing it.
Reviewed-by: Jonathan Nied
it message
change like suggested above,
Reviewed-by: Jonathan Nieder
Thanks.
Eric S. Raymond wrote:
> Jakub Narebski :
>> Currently Git makes use of the fact that SHA-1 and SHA-256 identifiers
>> are of different lengths to distinguish them (see section "Meaning of
>> signatures") in Documentation/technical/hash-function-transition.txt
>
> That's the obvious hack. As a fu
Emily Shaffer wrote:
> Signed-off-by: Emily Shaffer
> Reviewed-by: Jonathan Nieder
> ---
> Since v3, only the commit message has changed. Reworked based on
> Jonathan Nieder's suggestions (with some modifications for readability).
>
> grep.c | 4
> 1 file chan
Hi,
Jakub Narebski wrote:
> I think Documentation/technical/hash-function-transition.txt misses
> considerations for fast-import format (it talks about problem with
> submodules, shallow clones, and currently not solved problem of
> translating notes; it does not talk about git-replace, either).
ep it close to the error
> itself and reflowed the commit message.
Makes sense. Thanks for these summaries of what changed between each
revision of the patch --- they're very helpful.
With whatever subset of the above suggested commit message changes
make sense,
Reviewed-by: Jonathan Nied
Hi,
Emily Shaffer wrote:
> On Thu, May 16, 2019 at 06:02:54PM -0400, Jeff King wrote:
>> On Thu, May 16, 2019 at 02:44:44PM -0700, Emily Shaffer wrote:
>>> + /* TODO: In the future it may become desirable to pass in the name as
>>> +* an argument to grep_buffer(). At that time, "(in core)"
Hi,
Eric S. Raymond wrote:
> Jonathan Nieder :
>> Eric S. Raymond wrote:
>>> One reason I am sure of this is the SHA-1 to whatever transition.
>>> We can't count on the successor hash to survive attack forever.
[...]
>> Have you read through Documentation/t
SZEDER Gábor wrote:
> On Sat, May 18, 2019 at 09:54:12AM +0900, Mike Hommey wrote:
>> There are established corner cases, where in a repo where commit dates
>> are not monotonically increasing,
[...]
> All the above is without commit-graph, I presume? If so, then you
> should give it a try, as it
Hi!
Eric S. Raymond wrote:
> One reason I am sure of this is the SHA-1 to whatever transition.
> We can't count on the successor hash to survive attack forever.
> Accordingly, git's design needs to be stable against the possibility
> of having to accommodate multiple future hash algorithms in the
Jeff King wrote:
> The patch itself looks good to me.
For what it's worth,
Reviewed-by: Jonathan Nieder
as well. It's a straightforward patch and solves the reader-facing
problem. Thanks.
For the curious, the upstream discussion in docbook-xsl is
https://lists.oasis-open
Junio C Hamano wrote:
> Currently the only use of the function is to see if the log message
> matches with the given pattern (yes/no), but it is conceivable that
> new callers may want to prepare in-core data and use it to see if
> that matches the pattern, or even to _show_ the lines that match t
lk. I didn't want to print all the lines associated with
> a matching change, but it didn't seem good that a seemingly-sane
> grep_filter config was segfaulting.
Good find, and thanks for taking the time to make it easier to debug for
the next person.
[...]
> Jonathan Nieder proposed a
brian m. carlson wrote:
> Also, this is the way that most other programs on Unix do this behavior,
> and I think that is a compelling argument for this design in and of
> itself. I think Unix has generally made the best decisions in operating
> system design, and I aim to emulate it as much as pos
d wasting time debugging tests which
> fail due to a broken tool outside of our control.
>
> ¹ https://bugzilla.redhat.com/1709624
Reviewed-by: Jonathan Nieder
It would be nice to describe that bug in the commit message, to save
readers some head scratching.
Thanks,
Jonathan
Hi,
brian m. carlson wrote:
> On Mon, May 13, 2019 at 05:51:01PM -0700, Jonathan Nieder wrote:
>> brian m. carlson wrote:
>>> the fact that inheritance in the configuration
>>> is in-order and can't be easily modified means that it's
Hi,
brian m. carlson wrote:
> I've thought a lot about the discussion over whether this series should
> use the configuration as the source for multiple hooks. Ultimately, I've
> come to the decision that it's not a good idea. Even adopting the empty
> entry as a reset marker, the fact that inher
Hi,
Matthew DeVore wrote:
> On 2019/05/09, at 11:00, Jonathan Tan wrote:
>> - Supporting any combination of filter means that we have more to
>> implement and test, especially if we want to support more filters in
>> the future. In particular, the different filters (e.g. blob, tree)
>> have d
Matthew DeVore wrote:
> On 2019/05/06, at 12:46, Jonathan Nieder wrote:
>> Ah, interesting. When this was discussed before, the proposal has been
>> that the client can say "have" anyway. They don't have the commit and
>> all referenced objects, but they
Hi,
Jonathan Tan wrote:
> Matthew DeVore wrote:
>> I'm considering implementing a feature in the Git protocol which would
>> enable efficient and accurate object negotiation when the client is a
>> partial clone. I'd like to refine and get some validation of my
>> approach before I start to write
Hi,
Matthew DeVore wrote:
> I'm considering implementing a feature in the Git protocol which would
> enable efficient and accurate object negotiation when the client is a
> partial clone. I'd like to refine and get some validation of my
> approach before I start to write any code, so I've written
Jeffrey Walton wrote:
> On Wed, May 1, 2019 at 6:30 PM Jonathan Nieder wrote:
>> Sounds like it's using "install" when it should be using "ginstall".
>> config.mak.uname contains, under the SunOS category:
>>
>> INSTALL = /usr/ucb/ins
on we require. Use the /usr/ucb/install command specified in
config.mak.uname instead to fix it.
This should also help on other platforms where the default "install"
command is not functional enough.
Reported-by: Jeffrey Walton
Signed-off-by: Jonathan Nieder
---
Completely untested.
Hi,
Jeff King wrote:
> I wonder if this points to this patch touching the wrong level. These
> compiler flags are a thing that _some_ builds want (i.e., production
> builds where people care most about security and not about debugging),
> but not necessarily all.
>
> I'd have expected this to be
Hi,
Ævar Arnfjörð Bjarmason wrote:
> Because we don't have some general config facility for this it keeps
> coming up, and various existing/proposed options have their own little
> custom hacks for doing it, e.g. this for Barret Rhoden's proposed "blame
> skip commits" feature
> https://public-in
Hi,
brian m. carlson wrote:
> On Tue, Apr 23, 2019 at 07:34:38PM -0700, Jonathan Nieder wrote:
>> brian m. carlson wrote:
>>> I've talked with some people about this approach, and they've indicated
>>> they would prefer a configuration-based approach.
&g
Hi,
brian m. carlson wrote:
> I've talked with some people about this approach, and they've indicated
> they would prefer a configuration-based approach.
I would, too, mostly because that reduces the problem of securing
hooks to securing configuration. See
https://public-inbox.org/git/201710022
Ævar Arnfjörð Bjarmason wrote:
> On Wed, Apr 24 2019, Jonathan Nieder wrote:
>> Do you mean this for when a pack is self-contained and contains all
>> objects reachable from those "tip" commits?
>>
>> What would you do when a pack is not self-contained in that
Ævar Arnfjörð Bjarmason wrote:
> On Wed, Apr 24 2019, Jonathan Nieder wrote:
>> Jeff King wrote:
>>> On Fri, Mar 08, 2019 at 01:55:17PM -0800, Jonathan Tan wrote:
>>>> +If the 'packfile-uris' feature is advertised, the following argument
>>>>
Hi,
Ævar Arnfjörð Bjarmason wrote:
> This is really orthagonal to this series, but wouldn't a better
> resumption strategy here be to walk the pack we just downloaded, run the
> equivalent of 'commit-graph write' on it to figure out likely "tip"
> commits, and use those in "have" lines to negotia
Hi,
Jeff King wrote:
> On Fri, Mar 08, 2019 at 01:55:17PM -0800, Jonathan Tan wrote:
>> +If the 'packfile-uris' feature is advertised, the following argument
>> +can be included in the client's request as well as the potential
>> +addition of the 'packfile-uris' section in the server's response a
be fast enough for people to consistently run them).
[...]
> config.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Jonathan Nieder
Thanks.
(thanks for cc-ing bmc!)
Hi,
Heinrich Schuchardt wrote:
> Subject: send-email: fix transferencoding config option
nit: "fix" doesn't tell me what was broken and what you improved about
it. Here, I think you mean "respect transferencoding config option".
> Since e67a228cd8a ("send-email: automa
clone and for fetch, that server
> handling of server options are server-specific.
>
> Signed-off-by: Jonathan Tan
> Reviewed-by: Jonathan Nieder
> Signed-off-by: Junio C Hamano
> ---
> Documentation/fetch-options.txt | 3 ++-
> Documentation/git-clone.txt | 8
>
ort
> *transport,
> break;
> case protocol_v1:
> case protocol_v0:
> + warn_server_options_unsupported(transport);
> refs = fetch_pack(&args, data->fd, data->conn,
Looks like this only affects fetch, so the question above about push
is only about the commit message.
With whatever subset of the suggested changes makes sense,
Reviewed-by: Jonathan Nieder
Thanks.
27; '
> + test_when_finished "rm -rf log myclone" &&
> +
> + GIT_TRACE_PACKET="$(pwd)/log" git -c protocol.version=2 \
> + clone --server-option=hello --server-option=world \
> + "file://$(pwd)/file_parent" myclone &&
> +
> + grep "server-option=hello" log &&
> + grep "server-option=world" log
> +'
Nice. Thanks for including this.
Reviewed-by: Jonathan Nieder
Thanks for a pleasant read.
.txt), so that "info/refs"
> + # can serve refs, just like it does in protocol v0.
> + GIT_TEST_PROTOCOL_VERSION=0 git --git-dir=half-auth fetch &&
> expect_askpass none
I suspect it's fine if protocol v2 never supports this. Can we change
the NEEDSWORK comment to say that the protocol v2 spec should document
the lack of support for half-auth?
With or without such a change,
Reviewed-by: Jonathan Nieder
Thanks.
Josh Steadmon wrote:
> A question for the list: should these new config vars also be documented
> in the git-config manpage, or is it better to keep these separate since
> they are only read from the system config?
Yes, they should be in the git-config manpage.
*If* they are read only from the s
Hi,
Jeff Hostetler via GitGitGadget wrote:
> Teach git to read the system config (usually "/etc/gitconfig") for
> default Trace2 settings. This allows system-wide Trace2 settings to
> be installed and inherited to make it easier to manage a collection of
> systems.
Yay! Thanks for writing this
Hi,
Ævar Arnfjörð Bjarmason wrote:
> --- a/Documentation/git-gc.txt
> +++ b/Documentation/git-gc.txt
> @@ -41,10 +41,20 @@ OPTIONS
> --aggressive::
> Usually 'git gc' runs very quickly while providing good disk
> space utilization and performance. This option will cause
> - 'git
Hi,
John Passaro wrote:
> I find myself fairly frequently doing something like "git log $(git
> merge-base A B)..C".
Hm. Can you tell me more about the workflow / higher-level operation
where you do this?
Curious,
Jonathan
Hi,
Fabio Aiuto wrote:
> What a pity, It would have been very useful for me, to debug around
> that simple version, to understand how everithing works.
Jeff King suggested how you can update the build command to get it
working. In general, I think people sometimes overthink what is
involved in
rk, not a way to have a partial
repository on the server side.
[...]
> On Tue, Feb 26, 2019 at 12:45 AM Jonathan Nieder wrote:
>> This doesn't stop a hosting provider from using e.g. server options to
>> allow the client more control over how their response is served, just
&g
ne "", I'm not sure, but that's
> outside the scope of this patch set, I think.
>
> Signed-off-by: Jonathan Tan
> ---
> remote-curl.c | 32 +++-
> 1 file changed, 19 insertions(+), 13 deletions(-)
Tested-by: Jonathan Nieder
Hi,
Christian Couder wrote:
> On Sun, Feb 24, 2019 at 12:39 AM Jonathan Tan
> wrote:
>> Teach upload-pack to send part of its packfile response as URIs.
>>
>> An administrator may configure a repository with one or more
>> "uploadpack.blobpackfileuri" lines, each line containing an OID and a
>>
Hi,
Christian Couder wrote:
> On Sun, Feb 24, 2019 at 12:39 AM Jonathan Tan
> wrote:
>> There are probably some more design discussions to be had:
>
> [...]
>
>> - Client-side whitelist of protocol and hostnames. I've implemented
>>whitelist of protocol, but not hostnames.
>
> I would appr
t;
> Signed-off-by: Johannes Schindelin
> ---
> config.mak.uname | 1 -
> 1 file changed, 1 deletion(-)
Yay!
Reviewed-by: Jonathan Nieder
Is there a way to automate checking for make variables that are set
but never used?
Thanks,
Jonathan
Hi,
Randall S. Becker wrote:
> While this is a bit of a hack, it might be useful for skipping t9020 in
> environments where the svn.remote package is not installed. I can make this
> into a patch if this style is reasonable - guessing probably not and that
> the REMOTE_SVN test should go elsewher
gt;
> Signed-off-by: Josh Steadmon
> ---
> Documentation/technical/protocol-capabilities.txt | 14 ++
> 1 file changed, 14 insertions(+)
Reviewed-by: Jonathan Nieder
Thanks.
Hi,
Stefan Beller wrote:
> This patch tightens the check upfront, such that we do not need
> to spawn a child process to find out if the submodule is broken.
Sounds sensible.
[...]
> --- a/submodule.c
> +++ b/submodule.c
[...]
> @@ -1319,10 +1338,23 @@ static int get_next_submodule(struct child
Hi,
Jeremy Huddleston Sequoia wrote:
> Unfortunately, I was quick to celebrate. This picks up the bundled
> file instead of a system-wide file. I'd love it if we could still
> honor system-wide config/attributes in addition to
> RUNTIME_PREFIX-relative ones (eg: user overrides system which
> ov
Hi,
Jonathan Tan wrote:
> --- a/t/lib-httpd/apache.conf
> +++ b/t/lib-httpd/apache.conf
> @@ -78,6 +78,7 @@ PassEnv GNUPGHOME
> PassEnv ASAN_OPTIONS
> PassEnv GIT_TRACE
> PassEnv GIT_CONFIG_NOSYSTEM
> +PassEnv GIT_TEST_SIDEBAND_ALL
This is producing
[env:warn] [pid 248632] AH01506: PassEnv
(+cc: Uwe Kleine-König, maintainer of the sparse package in Debian)
Hi,
Ramsay Jones wrote[1]:
> Hmm, I've never built an Ubuntu package before, so I don't know
> exactly what would be required (spec file etc.) to create a PPA.
> But I suspect you are not talking about doing that, right?
Ubuntu
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> I find --ignore-removal fairly easy to understand, and I had no idea
>> what --overlay would mean.
>>
>> I realize this is just one user's experience.
>
> Exactly. My impression was the exact opposite from
Hi,
Junio C Hamano wrote:
> Thomas Gummerer writes:
>> Jonathan Nieder wrote:
>>> Is this analogous to "git add --ignore-removal"? If so, can we just
>>> call it --ignore-removal?
>>
>> Yes, it seems like they are very similar.
>
> Hmm,
Thomas Gummerer wrote:
> On 01/22, Jonathan Nieder wrote:
>> I had no idea what --overlay would mean and am still not clear on it.
>> Is this analogous to "git add --ignore-removal"? If so, can we just
>> call it --ignore-removal?
>
> Yes, it seems like
Hi,
Thomas Gummerer wrote:
> Currently 'git checkout' is defined as an overlay operation, which
> means that if in 'git checkout -- []' we have an
> entry in the index that matches , but that doesn't exist in
> , that entry will not be removed from the index or the
> working tree.
>
> Introduce
(moving conversation to the main Git list. I hope that's okay.)
Hi,
Jeff King wrote:
> On Tue, Jan 15, 2019 at 02:35:29PM +0100, Marketa Calabkova wrote:
>> meggy@irbis:/tmp/test> /usr/bin/time git clone
>> https://github.com/Katee/git-bomb.git
>> Cloning into 'git-bomb'...
>> remote: Enumeratin
Nate Weaver wrote:
> Upon further digging, this is an issue in gettext's code on macOS:
> The function _nl_language_preferences_default (in langprefs.c) specifically
> breaks early when it sees the literal string "en" in the list (from the
> "AppleLanguages" defaults key), but not when it gets "en
Nate Weaver wrote:
>>> On Fri, Sep 14, 2018 at 10:20 PM Niko Dzhus wrote:
Looks like the issue appeared after updating git from brew.
[...]
A quick search revealed that brew changed how it builds git recently.
I think, it just didn't include i18n by default before, so I never
Hi,
SZEDER Gábor wrote:
> On Fri, Jan 11, 2019 at 07:51:18PM +0100, SZEDER Gábor wrote:
>> As to re-importing obstack.{c,h} from upstream, we've made some
>> portability fixes to these files, and neither of the commit messages
>> of those fixes mention that they are backports from upstream. OTOH
Jonathan Nieder wrote:
> Junio C Hamano wrote:
>> In short, are you shooting js/smart-http-detect-remote-error topic
>> down and replacing it with this one?
>>
>> As that topic is not yet in 'next', I am perfectly fine doing that.
>> I just want to make
Hi,
Junio C Hamano wrote:
> Masaya Suzuki writes:
>> This makes it possible for servers to send an error message back to clients
>> in
>> an arbitrary situation.
Yay! Yes, this should simplify server implementations and user support.
[...]
> In short, are you shooting js/smart-http-detect-re
hether they're valid or not.
>
> Reviewed-by: Josh Steadmon
For what it's worth, we've been running with this at Google (using the
sb/submodule-recursive-fetch-gets-the-tip branch from "pu") for more
than a month, with no user complaints.
Tested-by: Jonathan Nieder
Hi,
In August, 2018, Brandon Williams wrote:
> Commit 0383bbb901 (submodule-config: verify submodule names as paths,
> 2018-04-30) introduced some checks to ensure that submodule names don't
> include directory traversal components (e.g. "../").
>
> This addresses the vulnerability identified in
Hi,
Jeff Hostetler wrote:
> This patch series contains a new trace2 facility that hopefully addresses
> the recent trace- and structured-logging-related discussions. The intent is
> to eventually replace the existing trace_ routines (or to route them to the
> new trace2_ routines) as time permits
the tree
entry are valid.
Signed-off-by: Jeff King
Signed-off-by: Jonathan Nieder
---
Hi,
This patch is from the 2.20.0 era, from the same series as
fsck: detect submodule urls starting with dash
It was omitted from that series because it does not address any known
exploit, but to me it s
"checkout -f master" in the submodule as well)
clone: see checkout
reset --hard: see checkout
Signed-off-by: Stefan Beller
Signed-off-by: Jonathan Nieder
---
Documentation/git-checkout.txt | 13 +++--
Makefile | 1 +
branc
1 - 100 of 3146 matches
Mail list logo
