Re: [PATCH 24/30] merge-recursive: Add computation of collisions due to dir rename & merging

fer by copying an existing color. However, using strcpy() makes it harder to audit the code-base for calls that _are_ problems. We should use something like xsnprintf(), which shows the reader that we expect this never to fail (and provides a run-time assertion if it does, just in case). Signed-

[PATCH v2 2/2] fsck: avoid looking at NULL blob->object

tead, let's just use lookup_unknown_object() to get the real "struct object", and pass that. Signed-off-by: Jeff King --- fsck.c | 3 ++- t/t7415-submodule-names.sh | 18 ++ 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/fsck.c b/fsck.

[PATCH v2 1/2] t7415: don't bother creating commit for symlink test

for more discussion). As a result, there's no need to create a commit in our tests. Let's drop it in the name of simplicity. Signed-off-by: Jeff King --- t/t7415-submodule-names.sh | 1 - 1 file changed, 1 deletion(-) diff --git a/t/t7415-submodule-names.sh b/t/t7415-submodule-names.sh index

[PATCH v2 0/2] .gitmodules fsck cleanups

Here's a v2 which fixes the comment typo and drops the unnecessary commit creation in the tests. I've added a preparatory patch to do the same cleanup in the existing test for consistency. As before, these should apply on 'maint'. [1/2]: t7415: don't bother creating commit for symlink test

Re: [PATCH] fsck: avoid looking at NULL blob->object

On Sat, Jun 09, 2018 at 10:50:36AM +0200, Martin Ågren wrote: > On 9 June 2018 at 10:32, Jeff King wrote: > > Except it _does_ do one non-trivial thing, which is call the > > report() function, which wants us to pass a pointer to a > > "struct object". Which we don

Re: [PATCH] fsck: avoid looking at NULL blob->object

On Sat, Jun 09, 2018 at 10:45:15AM +0200, Duy Nguyen wrote: > > It seems like we could refactor report() to just take the > > object_id itself. But we pass the object pointer along to > > a callback function, and indeed this ends up in > > builtin/fsck.c's objreport() which does want to look at >

Re: [PATCH] fsck: avoid looking at NULL blob->object

On Sat, Jun 09, 2018 at 04:38:54AM -0400, Eric Sunshine wrote: > On Sat, Jun 9, 2018 at 4:32 AM, Jeff King wrote: > > Commit 159e7b080b (fsck: detect gitmodules files, > > 2018-05-02) taught fsck to look at the content of > > .gitmodules files. If the object turns out not to

[PATCH] fsck: avoid looking at NULL blob->object

nown_object() to get the real "struct object", and pass that. Signed-off-by: Jeff King --- The problem is in v2.17.1, and of course the v2.18 release candidates. fsck.c | 3 ++- t/t7415-submodule-names.sh | 18 ++ 2 files changed, 20 insertions

Re: [RFC PATCH v1] telemetry design overview (part 1)

On Sat, Jun 09, 2018 at 09:04:16AM +0200, Johannes Sixt wrote: > > AFAICT this telemetry data is the same thing, but for performance. When > > somebody says "why does this command take so long", wouldn't it be nice > > for us to be able to tell them to flip a switch that will collect data > > on

Re: [RFC PATCH v1] telemetry design overview (part 1)

On Sat, Jun 09, 2018 at 08:31:58AM +0200, Ævar Arnfjörð Bjarmason wrote: > 1) I really don't see the basis for this argument that they'd need to >patch it out, they're not patching out e.g. GIT_TRACE now, which has >all the same sort of concerns, it's just a format that's more of a >

Re: [RFC PATCH v1] telemetry design overview (part 1)

On Sat, Jun 09, 2018 at 07:03:53AM +0200, Duy Nguyen wrote: > > > Am 08.06.2018 um 18:00 schrieb Thomas Braun: > > >> I for my part would much rather prefer that to be a compile time > > >> option so that I don't need to check on every git update on windows > > >> if this is now enabled or not.

Re: Truncating file names with Unicode characters

On Fri, Jun 08, 2018 at 09:25:29PM +0300, Vitaly Potyarkin wrote: > # Truncating file names with Unicode characters > > When shortening file names that contain Unicode characters, git performs > truncation without awareness of two-byte characters. That often leads to > splitting a character in

Re: [PATCH 2/2] pack-bitmap: add free function

On Thu, Jun 07, 2018 at 12:04:14PM -0700, Jonathan Tan wrote: > Add a function to free struct bitmap_index instances, and use it where > needed (except when rebuild_existing_bitmaps() is used, since it creates > references to the bitmaps within the struct bitmap_index passed to it). > > Note

Re: [PATCH 1/2] pack-bitmap: remove bitmap_git global variable

On Thu, Jun 07, 2018 at 12:04:13PM -0700, Jonathan Tan wrote: > Remove the bitmap_git global variable. Instead, generate on demand an > instance of struct bitmap_index for code that needs to access it. > > This allows us significant control over the lifetime of instances of > struct

Re: [RFC PATCH v1] telemetry design overview (part 1)

On Thu, Jun 07, 2018 at 11:10:52PM +0200, Johannes Sixt wrote: > Am 07.06.2018 um 16:53 schrieb g...@jeffhostetler.com: > > From: Jeff Hostetler > > > > I've been working to add code to Git to optionally collect telemetry data. > > The goal is to be able to collect performance data from Git

Re: [RFC PATCH v1] http: add http.keepRejectedCredentials config

On Thu, Jun 07, 2018 at 08:15:16PM -0700, Lars Schneider wrote: > > In fact, this patch probably should give the user some advice in that > > regard (either in the documentation, or as a warning when we skip the > > rejection). If you _do_ have a bogus credential and set the new option, > > you'd

Re: [ANNOUNCE] Git v2.16.0-rc0

On Tue, Jan 02, 2018 at 09:35:16PM -0800, Jonathan Nieder wrote: > > bturner@ubuntu:~$ ssh -V > > OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8, OpenSSL 1.0.1f 6 Jan 2014 > > > > bturner@ubuntu:~$ ssh -G -p 7999 localhost > > unknown option -- G > > usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address]

Re: [PATCH v7 2/2] json-writer: t0019: add Python unit test

On Wed, Jun 06, 2018 at 10:23:53PM -0400, Jeff King wrote: > Though maybe I am wrong that the remote-svn stuff requires python. I > thought it did, but poking around, it looks like it's all C, and just > the "svnrdump_sim" helper is python. I think I was ge

Re: [PATCH 01/10] t: add tool to translate hash-related values

On Thu, Jun 07, 2018 at 12:57:04AM +, brian m. carlson wrote: > > > Unless I'm wrong, we don't use the "local" keyword ? > > > > We've got a test balloon out; see 01d3a526ad (t: check whether the > > shell supports the "local" keyword, 2017-10-26). I think it's reasonable > > to consider

Re: [PATCH v7 2/2] json-writer: t0019: add Python unit test

On Wed, Jun 06, 2018 at 09:49:09PM -0400, Todd Zullinger wrote: > Ramsay Jones wrote: > [...] > > I don't run the p4 or svn tests, so ... :-D > > Heh, lucky you. :) > > I try to run them all as part of the fedora builds since > they cover much more than I'd ever use. That's the main > reason I

Re: [PATCH v7 2/2] json-writer: t0019: add Python unit test

On Thu, Jun 07, 2018 at 01:16:14AM +0100, Ramsay Jones wrote: > > Probably. We may want to go the same route as we did for perl in > > a0e0ec9f7d (t: provide a perl() function which uses $PERL_PATH, > > 2013-10-28) so that test writers don't have to remember this. > > > > That said, I wonder if

Re: [PATCH v7 2/2] json-writer: t0019: add Python unit test

On Wed, Jun 06, 2018 at 01:10:52PM -0400, Todd Zullinger wrote: > g...@jeffhostetler.com wrote: > > +# As a sanity check, ask Python to parse our generated JSON. Let Python > > +# recursively dump the resulting dictionary in sorted order. Confirm that > > +# that matches our expectations. > >

Re: [PATCH 01/10] t: add tool to translate hash-related values

On Wed, Jun 06, 2018 at 08:19:27AM +0200, Torsten Bögershausen wrote: > > +test_translate_f_ () { > > + local file="$TEST_DIRECTORY/translate/$2" && > > Unless I'm wrong, we don't use the "local" keyword ? We've got a test balloon out; see 01d3a526ad (t: check whether the shell supports

Re: git rm bug

On Wed, Jun 06, 2018 at 04:01:38PM -0400, Todd Zullinger wrote: > Thomas Fischer wrote: > > I agree that the entire chain of empty directories should not be tracked, > > as git tracks content, not files. > > > > However, when I run 'rm path/to/some/file', I expect path/to/some/ to still > >

Re: Where is git checkout --orphan implemented at.

On Tue, Jun 05, 2018 at 12:02:12PM -0400, Sean Hunt wrote: > I would like to see the source code to git checkout --orphan so I can > learn how it works and so I can manually do what it does by hand on > making a new branch with no history in the refs folder. I can only do > it on my iPhone as my

Re: [RFC PATCH v1] http: add http.keepRejectedCredentials config

On Mon, Jun 04, 2018 at 12:18:59PM -0400, Martin-Louis Bright wrote: > Why must the credentials must be deleted after receiving the 401 (or > any) error? What's the rationale for this? Because Git only tries a single credential per invocation. So if a helper provides one, it doesn't prompt. If

Re: What's cooking in git.git (Jun 2018, #02; Mon, 4)

On Mon, Jun 04, 2018 at 04:18:17PM +0200, SZEDER Gábor wrote: > > > * jk/index-pack-maint (2018-06-01) 2 commits > > (merged to 'next' on 2018-06-04 at c553a485e8) > > + index-pack: handle --strict checks of non-repo packs > > + prepare_commit_graft: treat non-repository as a noop > > > >

Re: [RFC PATCH v1] http: add http.keepRejectedCredentials config

On Mon, Jun 04, 2018 at 05:26:35AM -0700, lars.schnei...@autodesk.com wrote: > From: Lars Schneider > > If a Git HTTP server responds with 401 or 407, then Git tells the > credential helper to reject and delete the credentials. In general > this is good. > > However, in certain automation

Re: What's cooking in git.git (Jun 2018, #02; Mon, 4)

On Mon, Jun 04, 2018 at 10:57:30PM +0900, Junio C Hamano wrote: > * jk/index-pack-maint (2018-06-01) 2 commits > (merged to 'next' on 2018-06-04 at c553a485e8) > + index-pack: handle --strict checks of non-repo packs > + prepare_commit_graft: treat non-repository as a noop > > "index-pack

Re: how exactly can git config section names contain periods?

On Sun, Jun 03, 2018 at 06:35:44AM -0400, Robert P. J. Day wrote: > > > if (for some weird reason) i wanted to define a multi-level > > > subsection, > > > > You can't, there are no multi-level subsections, see above. > > no, i *get* that, what i was asking was if i wanted to simulate or >

Re: [PATCH 2/2] sequencer.c: plug mem leak in git_sequencer_config

On Sun, Jun 03, 2018 at 11:56:37PM -0400, Jeff King wrote: > So sometimes some_var needs to be freed and sometimes not (and every one > of those uses is a potential leak, but it's OK because they're all > program-lifetime globals anyway, and people don't _tend_ to set the same >

Re: [PATCH 2/2] sequencer.c: plug mem leak in git_sequencer_config

On Mon, Jun 04, 2018 at 01:26:57PM +0900, Junio C Hamano wrote: > > Doing it "right" in C would probably involve two variables: > > > > const char *some_var = "default"; > > const char *some_var_storage = NULL; > > > > int git_config_string_smart(const char **ptr, char **storage, > >

Re: [PATCH v7 2/2] http-backend: respect CONTENT_LENGTH for receive-pack

On Sun, Jun 03, 2018 at 12:27:49AM +0300, Max Kirillov wrote: > Push passes to another commands, as described in > https://public-inbox.org/git/20171129032214.gb32...@sigill.intra.peff.net/ > > As it gets complicated to correctly track the data length, instead transfer > the data through parent

Re: [PATCH 2/2] sequencer.c: plug mem leak in git_sequencer_config

On Mon, Jun 04, 2018 at 12:44:15PM +0900, Junio C Hamano wrote: > >> diff --git a/sequencer.c b/sequencer.c > >> index b98690ecd41..aba03e9429a 100644 > >> --- a/sequencer.c > >> +++ b/sequencer.c > >> @@ -175,6 +175,7 @@ static int git_sequencer_config(const char *k, const > >> char *v, void

Re: [PATCH v7 1/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

On Sun, Jun 03, 2018 at 12:27:48AM +0300, Max Kirillov wrote: > http-backend reads whole input until EOF. However, the RFC 3875 specifies > that a script must read only as many bytes as specified by CONTENT_LENGTH > environment variable. Web server may exercise the specification by not closing >

Re: [PATCH] update-ref --stdin: use skip_prefix()

On Sun, Jun 03, 2018 at 04:36:51PM +0200, SZEDER Gábor wrote: > Use skip_prefix() instead of starts_with() and strcmp() when parsing > 'git update-ref's stdin to avoid a couple of magic numbers. I was coincidentally looking at this the other day also noticed these. Thanks for cleaning it up (and

Re: how exactly can git config section names contain periods?

On Sat, Jun 02, 2018 at 04:50:57AM -0400, Robert P. J. Day wrote: > On Fri, 1 Jun 2018, Jeff King wrote: > > > On Fri, Jun 01, 2018 at 04:14:12PM -0400, Robert P. J. Day wrote: > > > > > $ git config --global a.b.c.d.e rday > > > > > > huh

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Sat, Jun 02, 2018 at 06:46:31AM +0200, Duy Nguyen wrote: > > if (used_deprecated_reflog_option) { > > - warning("the '-l' alias for '--create-reflog' is > > deprecated;"); > > - warning("it will be removed in a future version of Git"); > > +

Re: [PATCH v4] json_writer: new routines to create data in JSON format

On Sat, Jun 02, 2018 at 06:41:06AM +0200, Duy Nguyen wrote: > On Mon, Mar 26, 2018 at 4:31 PM, wrote: > > +static inline void assert_in_array(const struct json_writer *jw) > > +{ > > + if (!jw->open_stack.len) > > + die("json-writer: array: missing jw_array_begin()"); > >

Re: how exactly can git config section names contain periods?

On Sat, Jun 02, 2018 at 08:05:22AM +0900, Junio C Hamano wrote: > > This has been deprecated since 2011. Maybe it's time to finally get rid > > of it. > > Sure, but is it worth the transition noise? > > The way we lightly utter the word "deprecated" around here probably > does not align well

Re: how exactly can git config section names contain periods?

On Fri, Jun 01, 2018 at 04:14:12PM -0400, Robert P. J. Day wrote: > more oddities in my travels, this from Doc.../config.txt: > > "The file consists of sections and variables. A section begins with > the name of the section in square brackets and continues until the > next section begins.

Re: does a new repo actually *need* default template content?

On Mon, May 28, 2018 at 07:56:12PM +0200, Ævar Arnfjörð Bjarmason wrote: > > On Mon, May 28 2018, Robert P. J. Day wrote: > > > (apologies for more pedantic nitpickery, just little things i'm > > running across in my travels. aside: i actually teach git courses, so > > it's a bit embarrassing

Re: [RFC] git gc "--prune=now" semantics considered harmful

On Sun, May 27, 2018 at 08:31:14AM +0900, Junio C Hamano wrote: > > So I actually would much prefer that foir git gc, "--prune=now" means > > > > (a) "now" > > > > (b) now at the _start_ of the "git gc" operation, not the time at > > the _end_ of the operation when we've already spent a

Re: Is origin/HEAD only being created on clone a bug? #leftoverbits

On Wed, May 30, 2018 at 11:46:16AM +0900, Junio C Hamano wrote: > Junio C Hamano writes: > > > - When we fetch from a remote that has refs/remotes/$name/HEAD, and > >if the protocol notices that their HEAD today is pointing to a > >branch different from what our side has, should we

Re: Bug: Install from .tar.xz fails without write permission on /usr/local/share/man/man3

On Thu, May 31, 2018 at 06:30:18PM +0200, ml...@posteo.de wrote: > I was trying to build git 2.9.5 as a normal user, as I have no root access > on a cluster with outdated software. > > The build fails, unless I change the PREFIX=/usr/local line in > per/perl.mak:80 to a folder where I have write

Re: [PATCH] fsckObjects tests: show how v2.17.1 can exploit downstream

On Fri, Jun 01, 2018 at 10:42:00AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > I haven't tested it, but I suspect that doing multiple fetches could > > result in passing bad objects through a fetch.fsckObjects filter. > > Because the objects aren't quarantin

Re: [RFC PATCH 3/4] color.ui config: don't die on unknown values

On Thu, May 31, 2018 at 09:17:41AM +0200, Ævar Arnfjörð Bjarmason wrote: > > Ævar Arnfjörð Bjarmason writes: > > > >> Before this change git will die on any unknown color.ui values: > >> > >> $ git -c color.ui=doesnotexist show > >> fatal: bad numeric config value 'doesnotexist' for

Re: [PATCH 1/4] config doc: move color.ui documentation to one place

On Thu, May 31, 2018 at 09:09:58AM +0200, Ævar Arnfjörð Bjarmason wrote: > >> Instead let's briefly describe what each variable is for, and then > >> copy/paste a new boilerplate saying that this variable takes the exact > >> same values as color.ui, and if it's unset it'll fallback to whatever >

Re: [RFC PATCH 4/4] color.ui config: add "isatty" setting

On Thu, May 31, 2018 at 09:01:49AM +0200, Ævar Arnfjörð Bjarmason wrote: > > Is there some case where a pager can only handle color if _it's_ output > > is going to a tty, and otherwise not? > > Maybe I'm missing something but how is that something we can deal with? > We just: > > 1. use

[PATCH 2/2] index-pack: handle --strict checks of non-repo packs

because we were able to resolve the whole fsck in the first pass), then it actually isn't an interesting error at all. Signed-off-by: Jeff King --- builtin/index-pack.c | 8 ++-- t/t7415-submodule-names.sh | 10 ++ 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/bu

[PATCH 1/2] prepare_commit_graft: treat non-repository as a noop

but we BUG() anyway trying to even find that out. Signed-off-by: Jeff King --- commit.c | 3 +++ t/t5300-pack-object.sh | 6 ++ 2 files changed, 9 insertions(+) diff --git a/commit.c b/commit.c index b0e57cc440..0030e79940 100644 --- a/commit.c +++ b/commit.c @@ -207,6 +207,9

[PATCH 0/2] index-pack out-of-repo fixups

Coverity reported that the recently-added call to add_packed_git() in index-pack.c actually does nothing. It's right, and it turns out this is a minor bug in the .gitmodules fsck patches in v2.17.1. I say minor because it errs on the side of complaining too much (so it's not a security problem)

Re: Git Vulnerability Announced?

On Thu, May 31, 2018 at 04:00:38PM +, Erika Voss wrote: > Yes here is what was sent to me - > > https://www.theregister.co.uk/2018/05/30/git_vulnerability_could_lead_to_an_attack_of_the_repo_clones/ > https://www.debian.org/security/2018/dsa-4212 Yeah, the release announcement from the

Re: [RFC PATCH 1/3] usage: extract `prefix_suffix_lines()` from `advise()`

On Wed, May 30, 2018 at 12:26:40PM +0200, Martin Ågren wrote: > >>> So perhaps: > >>> > >>> void report_lines(FILE *out, > >>> const char *color, const char *color_reset, > >>> const char *prefix, const char *msg); > >>> > >>> or something? > >> > >> Sounds

Re: [PATCH] fsckObjects tests: show how v2.17.1 can exploit downstream

On Wed, May 30, 2018 at 10:32:19AM +0900, Junio C Hamano wrote: > If we want to also encourage people to vet their own "fetches", I am > not against extending documentation. It just is different from "we > extended the mechanism to help server side protect their clients" > that was the focus of

Re: [PATCH] fsckObjects tests: show how v2.17.1 can exploit downstream

On Tue, May 29, 2018 at 11:59:07PM +0200, Ævar Arnfjörð Bjarmason wrote: > > I'm not sure what testing this buys us. [...] > > Half of what I'm trying to do here is clarifying the v2.17.1 release > notes. The initial version Junio had & my proposed amendment on > git-security was: I think

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Wed, May 30, 2018 at 11:52:19AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > Right, what I meant by "gentler" is that we continue to perform the same > > behavior as the old version, alongside the warning. It's arguable here > > because running

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Wed, May 30, 2018 at 11:48:32AM +0900, Junio C Hamano wrote: > Jeff King writes: > > >> - if (list) { > >> - warning("the '-l' option is an alias for > >> '--create-reflog' and"); > >> -

Re: Weird revision walk behaviour

On Wed, May 30, 2018 at 11:20:40AM +0300, Kevin Bracey wrote: > On 30/05/2018 00:04, Jeff King wrote: > > > > Do we even need to do the parent rewriting here? By definition those > > parents aren't interesting, and we're TREESAME to whatever is in > > treesame_parent

Re: [RFC PATCH 4/4] color.ui config: add "isatty" setting

On Wed, May 30, 2018 at 09:06:41PM +, Ævar Arnfjörð Bjarmason wrote: > A co-worker of mine who was using UNIX systems when dinosaurs roamed > the earth was lamenting that kids these days were using tools like > "git" that thought they knew better than isatty(3) when deciding > whether or not

Re: [PATCH 2/4] config doc: clarify "to a terminal" in color.ui

On Wed, May 30, 2018 at 09:06:39PM +, Ævar Arnfjörð Bjarmason wrote: > Change the documentation added when color.ui=auto was made the default > in 4c7f1819b3 ("make color.ui default to 'auto'", 2013-06-10) to > describe "auto" as kicking in when writing to the terminal or a pager, > not just

Re: [PATCH 1/4] config doc: move color.ui documentation to one place

On Wed, May 30, 2018 at 09:06:38PM +, Ævar Arnfjörð Bjarmason wrote: > Ever since b982592d66 ("git-status: document colorization config > options", 2006-09-11) we've slowly been accumulating more and more > color.* options, where the documentation for each new one has > seemingly been

Re: [PATCH 1/3] refs/packed-backend.c: close fd of empty file

On Wed, May 30, 2018 at 10:03:00AM -0700, Stefan Beller wrote: > diff --git a/refs/packed-backend.c b/refs/packed-backend.c > index cec3fb9e00f..d447a731da0 100644 > --- a/refs/packed-backend.c > +++ b/refs/packed-backend.c > @@ -499,6 +499,7 @@ static int load_contents(struct snapshot *snapshot)

Re: [RFC PATCH 1/3] usage: extract `prefix_suffix_lines()` from `advise()`

On Fri, May 25, 2018 at 11:00:53PM +0200, Martin Ågren wrote: > +/* > + * Write the message to the file, prefixing and suffixing > + * each line with `prefix` resp. `suffix`. > + */ > +void prefix_suffix_lines(FILE *f, const char *prefix, > + const char *message, const char

Re: [RFC PATCH 1/3] usage: extract `prefix_suffix_lines()` from `advise()`

On Mon, May 28, 2018 at 08:40:16PM +0200, Duy Nguyen wrote: > On Fri, May 25, 2018 at 11:00 PM, Martin Ågren wrote: > > advice.c contains a useful code snippet which takes a multi-line string > > and prints the lines, prefixing and suffixing each line with two > > constant strings. This was

Re: [RFC PATCH 2/3] usage: prefix all lines in `vreportf()`, not just the first

On Mon, May 28, 2018 at 06:25:18PM +0900, Junio C Hamano wrote: > Martin Ågren writes: > > > diff --git a/t/t1011-read-tree-sparse-checkout.sh > > b/t/t1011-read-tree-sparse-checkout.sh > > index 0c6f48f302..31b0702e6c 100755 > > --- a/t/t1011-read-tree-sparse-checkout.sh > > +++

Re: [PATCH] fsckObjects tests: show how v2.17.1 can exploit downstream

On Tue, May 29, 2018 at 09:19:50PM +, Ævar Arnfjörð Bjarmason wrote: > Something that's known but not explicitly discussed in the v2.17.1 > release notes, or tested for, is that v2.17.1 will still happily pass > on evil .gitmodules objects by default to vulnerable downstream > clients. > >

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Tue, May 29, 2018 at 05:20:29PM -0400, Jeff King wrote: > Thanks. There's one bit missing here, because it did not cause a textual > conflict during the rebase (but it's now dead code). Patch below (to be > squashed to the tip of jk/branch-l-

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

are trivial and > hopefully I did them correctly. > -- >8 -- > From: Jeff King > Date: Mon, 26 Mar 2018 03:29:22 -0400 > Subject: [PATCH] branch: drop deprecated "-l" option > > We marked the "-l" option as deprecated back in here>. Now that sufficie

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Sun, May 27, 2018 at 12:15:40AM +0530, Kaartic Sivaraam wrote: > > Hmm, actually, I suppose the true value of the warning is to help people > > doing "git branch -l foo", and it would still work there. The "more > > extreme" from your suggested patch would only affect "branch -l". > > > >

Re: Weird revision walk behaviour

On Tue, May 29, 2018 at 12:06:51AM +0200, SZEDER Gábor wrote: > diff --git a/revision.c b/revision.c > index 4e0e193e57..0ddd2c1e8a 100644 > --- a/revision.c > +++ b/revision.c > @@ -605,7 +605,7 @@ static inline int limiting_can_increase_treesame(const > struct rev_info *revs) > > static

Re: RFC: New reference iteration paradigm

On Sat, May 26, 2018 at 07:25:32PM +0200, Jakub Narebski wrote: > > At one point I wrote a patch to binary search the packed-refs file, find > > the first "refs/tags/" entry, and then walk linearly through there. What > > stopped me is that the current refs.c code (I guess file-backend.c these >

Re: js/empty-config-section-fix, was Re: What's cooking in git.git (May 2018, #03; Wed, 23)

On Mon, May 28, 2018 at 01:20:41PM +0200, Johannes Schindelin wrote: > On Mon, 28 May 2018, Junio C Hamano wrote: > > > Johannes Schindelin writes: > > > > > On Thu, 24 May 2018, Junio C Hamano wrote: > > > > > >> * js/empty-config-section-fix (2018-05-18) 1 commit > > >> - config: a

Re: [PATCH 1/2] make show-index a builtin

On Tue, May 29, 2018 at 12:31:53AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > diff --git a/show-index.c b/builtin/show-index.c > > similarity index 96% > > rename from show-index.c > > rename to builtin/show-index.c > > index 1ead41e211..65fa

[PATCH 2/2] show-index: update documentation for index v2

pack might help a reader who is looking for more information. Signed-off-by: Jeff King <p...@peff.net> --- Documentation/git-show-index.txt | 26 -- 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/Documentation/git-show-index.txt b/Documentation/gi

[PATCH 1/2] make show-index a builtin

here, 2011-10-06) switched that back to xmalloc, which later become ALLOC_ARRAY(). Making it a builtin should give us the best of both worlds: no wasted space and no need to avoid the usual patterns. Signed-off-by: Jeff King <p...@peff.net> --- Makefile |

[PATCH 0/2] minor show-index modernizations

While recommending show-index to somebody today, I noticed that it has a few ancient warts. This series turns it into a builtin and fixes the documentation. I suspect it could do with some more modernization and friendliness, like: - re-using the existing packfile.c code instead of

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Fri, May 25, 2018 at 06:14:16PM +0900, Junio C Hamano wrote: > Junio C Hamano writes: > > >> - warning("the '-l' alias for '--create-reflog' is deprecated;"); > >> - warning("it will be removed in a future version of Git"); > >> + if (list) { >

Re: [PATCH v2] t: make many tests depend less on the refs being files

On Fri, May 25, 2018 at 10:48:04AM +0200, Michael Haggerty wrote: > > test_expect_success "multi-fetch works off a 'clean' repository" ' > > - rm -r "$GIT_DIR/svn" "$GIT_DIR/refs/remotes" "$GIT_DIR/logs" && > > + rm -rf "$GIT_DIR/svn" "$GIT_DIR/refs/remotes" && > > + git reflog expire

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Fri, May 25, 2018 at 10:55:45AM +0900, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > > Hmm, actually, I suppose the true value of the warning is to help people > > doing "git branch -l foo", and it would still work there. The "more >

[PATCH] branch: issue "-l" deprecation warning after pager starts

On Thu, May 24, 2018 at 03:22:14PM -0400, Jeff King wrote: > On Thu, May 24, 2018 at 08:40:18PM +0530, Kaartic Sivaraam wrote: > > > > On the other hand, I'm not sure this is that big a deal. The point of > > > the deprecation warning is to catch people who are actually

Re: jk/branch-l-0-deprecation (was Re: What's cooking in git.git (May 2018, #02; Thu, 17))

On Thu, May 24, 2018 at 08:40:18PM +0530, Kaartic Sivaraam wrote: > > On the other hand, I'm not sure this is that big a deal. The point of > > the deprecation warning is to catch people who are actually trying to > > use "-l" as "--create-reflog", and that case does not page. The people > >

Re: BUG: No way to set fsck. when cloning

On Thu, May 24, 2018 at 07:04:04PM +0200, Ævar Arnfjörð Bjarmason wrote: > That doesn't work, because that's for the server-side, but I need the > fetch.fsck.* that doesn't exist. This works (I'll send a better patch > with tests / docs etc. soon): Yeah, I think this is the right direction. >

Re: unexpected "unresolved merge conflict" for a new file

On Thu, May 24, 2018 at 01:36:57PM +0200, Michal Hocko wrote: > `git commit' fails on a newly added file with the following > * > * You have some suspicious patch lines: > * > * In Documentation/core-api/gfp_mask-from-fs-io.rst > * unresolved merge conflict (line 27) >

Re: [PATCH v2] rev-parse: check lookup'ed commit references for NULL

up_commit_reference() as part of > their logic. Neither usage checked the returned commit to see if it was > non-NULL before using it. Check for NULL and ensure an appropriate error > is reported to the user. > > Reported by Florian Weimer and Todd Zullinger. > > Helped-by: Jeff K

Re: BUG: No way to set fsck. when cloning

On Thu, May 24, 2018 at 05:25:29PM +0200, Ævar Arnfjörð Bjarmason wrote: > When I do: > > git -c fetch.fsckObjects=true clone > g...@github.com:robbyrussell/oh-my-zsh.git > > I get: > > error: object 2b7227859263b6aabcc28355b0b994995b7148b6: > zeroPaddedFilemode: contains zero-padded

Re: [PATCH 1/2] t6101: add a test for rev-parse $garbage^@

On Wed, May 23, 2018 at 01:46:12PM -0700, Elijah Newren wrote: > diff --git a/t/t6101-rev-parse-parents.sh b/t/t6101-rev-parse-parents.sh > index 8c617981a3..7b1b2dbdf2 100755 > --- a/t/t6101-rev-parse-parents.sh > +++ b/t/t6101-rev-parse-parents.sh > @@ -214,4 +214,8 @@ test_expect_success

Re: [PATCH 2/2] rev-parse: verify that commit looked up is not NULL

On Wed, May 23, 2018 at 01:46:13PM -0700, Elijah Newren wrote: > In commit 2122f8b963d4 ("rev-parse: Add support for the ^! and ^@ syntax", > 2008-07-26), try_parent_shorthands() was introduced to parse the special > ^! and ^@ syntax. However, it did not check the commit returned from >

Re: Weird revision walk behaviour

On Wed, May 23, 2018 at 01:32:46PM -0400, Jeff King wrote: > On Wed, May 23, 2018 at 07:10:58PM +0200, SZEDER Gábor wrote: > > > $ git log --oneline master..ba95710a3b -- ci/ > > ea44c0a594 Merge branch 'bw/protocol-v2' into jt/partial-clone-proto-v2 > > >

Re: Weird revision walk behaviour

On Wed, May 23, 2018 at 07:10:58PM +0200, SZEDER Gábor wrote: > $ git log --oneline master..ba95710a3b -- ci/ > ea44c0a594 Merge branch 'bw/protocol-v2' into jt/partial-clone-proto-v2 > > But as far as I can tell, there are no changes in the 'ci/' directory > on any of the merge's parents: >

Re: git push => git: 'credential-winstore' is not a git command.

On Sun, May 20, 2018 at 10:17:54AM -0500, Chris wrote: > git config --global --unset credential.helper > > > This did help me, because previously Git was trying to authenticate me > with the Microsoft account I use to log into my Windows, which is > unrelated to the account I need to use to

Re: [PATCH] Add initial support for pax extended attributes

On Wed, May 23, 2018 at 11:34:52AM +0900, Junio C Hamano wrote: > > @@ -90,13 +99,32 @@ foreach my $tar_file (@ARGV) > > Z8 Z1 Z100 Z6 > > Z2 Z32 Z32 Z8 Z8 Z*', $_; > > } > > - next if $name =~ m{/\z}; > > $mode = oct

Re: commit-graph: change in "best" merge-base when ambiguous

On Mon, May 21, 2018 at 02:10:54PM -0400, Derrick Stolee wrote: > In the Discussion section of the `git merge-base` docs [1], we have the > following: > >     When the history involves criss-cross merges, there can be more than one > best common ancestor for two commits. For example, with this

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

On Mon, May 21, 2018 at 02:40:57PM -0700, Brandon Williams wrote: > > > > Most fellow German software engineers (who seem to have a knack for > > > > idiotically long variable/function names) would now probably suggest: > > > > > > > > git compare-patch-series-with-revised-patch-series >

Re: commit-graph: change in "best" merge-base when ambiguous

On Mon, May 21, 2018 at 11:33:11AM -0700, Elijah Newren wrote: > > In t6024-recursive-merge.sh, we have the following commit structure: > > > > # 1 - A - D - F > > # \ X / > > # B X > > # X \ > > # 2 - C - E - G > > > > When merging F to G, there are two

Re: [PATCH v5 0/4] unpack_trees_options: free messages when done

On Mon, May 21, 2018 at 04:54:24PM +0200, Martin Ågren wrote: > That is, I've replaced the `string_list_appendf()`-patch with Junio's > `argv_push*()`-patch, then squashed Junio's "redoing the 4/4"-patch into > patch 4/4 -- with the exception of keeping the `memset(opts->msgs, ...)` > which I

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

On Mon, May 21, 2018 at 10:56:47AM -0700, Stefan Beller wrote: > > It is very much about > > comparing two *ranges of* revisions, and not just any ranges, no. Those > > ranges need to be so related as to contain mostly identical changes. > > range-diff, eh? > > > Most fellow German software

Re: [PATCH 1/5] http: use strbufs instead of fixed buffers

On Mon, May 21, 2018 at 11:11:51AM -0700, Stefan Beller wrote: > Hi Jeff, > > On Fri, May 18, 2018 at 6:56 PM, Jeff King <p...@peff.net> wrote: > > > @@ -2421,4 +2426,5 @@ void release_http_object_request(struct > > http_object_request *freq) > .. > > +

Re: Re*: [PATCH v4 3/4] string-list: provide `string_list_appendf()`

On Mon, May 21, 2018 at 09:25:01AM +0900, Junio C Hamano wrote: > Junio C Hamano writes: > > > I have a feeling that argv_array might be a better fit for the > > purpose of keeping track of to_free[] strings in the context of this > > series. Moving away from string_list

Re: Re*: [PATCH v4 3/4] string-list: provide `string_list_appendf()`

On Mon, May 21, 2018 at 09:01:05AM +0900, Junio C Hamano wrote: > Jacob Keller writes: > > > On Sun, May 20, 2018 at 3:17 AM, Martin Ågren > > wrote: > >> +/** > >> + * Add formatted string to the end of `list`. This function ignores > >> + *

<    9   10   11   12   13   14   15   16   17   18   >