Re: [PATCH 0/2] routines to generate JSON data

On Sat, Mar 17, 2018 at 12:00:26AM +0100, Ævar Arnfjörð Bjarmason wrote: > > On Fri, Mar 16 2018, Jeff King jotted: > > > I really like the idea of being able to send our machine-readable output > > in some "standard" syntax for which people may already have parsers. But > > one big hangup with

Re: [PATCH 0/2] routines to generate JSON data

On Mon, Mar 19, 2018 at 06:19:26AM -0400, Jeff Hostetler wrote: > > To make the above work, I think you'd have to store a little more state. > > E.g., the "array_append" functions check "out->len" to see if they need > > to add a separating comma. That wouldn't work if we might be part of a > >

Re: [PATCH] Makefile: detect compiler and enable more warnings in DEVELOPER=1

On Sun, Mar 18, 2018 at 04:55:25PM +0100, Duy Nguyen wrote: > On Sun, Mar 18, 2018 at 9:18 AM, Nguyễn Thái Ngọc Duy > wrote: > > +ifneq ($(or $(filter gcc6,$(COMPILER_FEATURES)),$(filter > > clang4,$(COMPILER_FEATURES))),) > > +CFLAGS += -Wextra > > Another thing we can add

Re: Why does pack-objects use so much memory on incremental packing?

On Sat, Mar 17, 2018 at 11:05:59PM +0100, Ævar Arnfjörð Bjarmason wrote: > Splitting this off into its own thread. Aside from the improvements in > your repack memory reduction (20180317141033.21545-1-pclo...@gmail.com) > and gc config (20180316192745.19557-1-pclo...@gmail.com) series's I'm >

Re: .gitattributes override behavior (possible bug, or documentation bug)

> So I think the "recommended subset" is basically "everything but these > few constructs". We just need to document them. ;) Mentioned so-far/running list? - Matching directories recursively, or at all I guess (e.g. "/") - (???) Instead: "/*" - Negative matches - (???) Instead: Is there any

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Tue, Mar 20, 2018 at 12:25:27AM -0400, Dakota Hawkins wrote: > > Right. The technical reason is mostly "that is not how it was designed, > > and it would possibly break some corner cases if we switched it now". > > I'm just spitballing here, but do you guys think there's any subset of > the

Re: [PATCH 2/2] read-cache: fix an -Wmaybe-uninitialized warning

On Mon, Mar 19, 2018 at 05:56:11PM +, Ramsay Jones wrote: > For the purposes of this discussion, the ce_write_entry() function has > three code blocks of interest, that look like so: > > /* block #1 */ > if (ce->ce_flags & CE_STRIP_NAME) { > saved_namelen =

Re: [PATCH 0/2] -Wuninitialized

On Mon, Mar 19, 2018 at 05:53:09PM +, Ramsay Jones wrote: > This series removes all 'self-initialised' variables (ie. var = var;). > This construct has been used to silence gcc '-W[maybe-]uninitialized' warnings > in the past [1]. Unfortunately, this construct causes warnings to be issued by

Re: [PATCH] doc/gitattributes: mention non-recursive behavior

That's perfect, thank you so much! On Tue, Mar 20, 2018 at 12:14 AM, Jeff King wrote: > On Tue, Mar 20, 2018 at 12:04:11AM -0400, Jeff King wrote: > >> > I guess my takeaway is that it would be _good_ if the gitattributes >> > documentation contained the caveat about not matching

Re: .gitattributes override behavior (possible bug, or documentation bug)

> Right. The technical reason is mostly "that is not how it was designed, > and it would possibly break some corner cases if we switched it now". I'm just spitballing here, but do you guys think there's any subset of the combined .gitignore and .gitattributes matching functionality that could at

Re: [PATCH] filter-branch: use printf instead of echo -e

On Mon, Mar 19, 2018 at 03:39:46PM +, CB Bailey wrote: > > diff --git a/git-filter-branch.sh b/git-filter-branch.sh > > index 1b7e4b2cd..21d84eff3 100755 > > --- a/git-filter-branch.sh > > +++ b/git-filter-branch.sh > > @@ -627,7 +627,7 @@ then > > print H

[PATCH] doc/gitattributes: mention non-recursive behavior

On Tue, Mar 20, 2018 at 12:04:11AM -0400, Jeff King wrote: > > I guess my takeaway is that it would be _good_ if the gitattributes > > documentation contained the caveat about not matching directories > > recursively, but _great_ if gitattributes and gitignore (and whatever > > else there is)

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Mon, Mar 19, 2018 at 11:17:04PM -0400, Dakota Hawkins wrote: > Sorry to tack on to my previous email, but I just thought of this: > > If something like "-diff=lfs" won't do what I (and git-lfs) thought it > would, do you think it would be prudent/reasonable to suggest git-lfs > add a "no-lfs"

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Mon, Mar 19, 2018 at 11:10:26PM -0400, Dakota Hawkins wrote: > > As you noted below, that second line does not match your path, because > > attributes on a directory aren't applied recursively. And it has nothing > > to do with overriding. If you remove the png line entirely, you can see > >

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Mon, Mar 19, 2018 at 08:33:15PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > The best you can probably do is: > > > > /.readme-docs/* diff=foo > > > > Since you have no diff.foo.* config, that will behave in the default way > > (including respecting the usual "is

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Mon, Mar 19, 2018 at 11:33 PM, Junio C Hamano wrote: > Jeff King writes: > >> The best you can probably do is: >> >> /.readme-docs/* diff=foo >> >> Since you have no diff.foo.* config, that will behave in the default way >> (including respecting the usual

Re: .gitattributes override behavior (possible bug, or documentation bug)

Jeff King writes: > The best you can probably do is: > > /.readme-docs/* diff=foo > > Since you have no diff.foo.* config, that will behave in the default way > (including respecting the usual "is it binary" checks). So a bit hacky, > but I think it would work as "ignore prior

Re: .gitattributes override behavior (possible bug, or documentation bug)

Sorry to tack on to my previous email, but I just thought of this: If something like "-diff=lfs" won't do what I (and git-lfs) thought it would, do you think it would be prudent/reasonable to suggest git-lfs add a "no-lfs" filter for exactly this case? That way I could have explicit exclusions

Re: .gitattributes override behavior (possible bug, or documentation bug)

Thanks for the quick reply! On Mon, Mar 19, 2018 at 10:34 PM, Jeff King wrote: > On Mon, Mar 19, 2018 at 09:49:28PM -0400, Dakota Hawkins wrote: > >> Summary: Trying to apply attributes to file extensions everywhere >> except in one directory. >> >> .gitattributes: >> >>

Re: .gitattributes override behavior (possible bug, or documentation bug)

On Mon, Mar 19, 2018 at 09:49:28PM -0400, Dakota Hawkins wrote: > Summary: Trying to apply attributes to file extensions everywhere > except in one directory. > > .gitattributes: > > *.[Pp][Nn][Gg] filter=lfs diff=lfs merge=lfs -text > /.readme-docs/ -filter=lfs -diff=lfs -merge=lfs >

.gitattributes override behavior (possible bug, or documentation bug)

According to the gitattributes docs: "When more than one pattern matches the path, a later line overrides an earlier line. This overriding is done per attribute." I had a need to do this recently, and while the attributes are git-lfs specific, I think the issue may be generic. Summary: Trying

Re: PATCH 1/2] -Wuninitialized: remove some 'init-self' workarounds

On 19/03/18 17:54, Ramsay Jones wrote: > > The 'self-initialised' variables construct (ie var = var;) has > been used to silence gcc '-W[maybe-]uninitialized' warnings. This has, > unfortunately, caused MSVC to issue 'uninitialized variable' warnings. > Also, using clang static analysis causes

Re: How to debug a "git merge"?

On 3/14/2018 4:53 PM, Lars Schneider wrote: On 14 Mar 2018, at 18:02, Derrick Stolee wrote: On 3/14/2018 12:56 PM, Lars Schneider wrote: Hi, I am investigating a Git merge (a86dd40fe) in which an older version of a file won over the newer version. I try to understand why

Re: [PATCH v6 00/14] Serialized Git Commit Graph

On 3/19/2018 8:55 AM, Derrick Stolee wrote: Thanks for this! Fixing this performance problem is very important to me, as we will use the "--stdin-packs" mechanism in the GVFS scenario (we will walk all commits in the prefetch packs full of commits and trees instead of relying on refs). This

Re: [GSoC] Regarding "Convert scripts to builtins"

On Tue, Mar 20, 2018 at 12:11 AM, Christian Couder wrote: > On Sun, Mar 18, 2018 at 11:15 PM, Paul Sebastian Ungureanu >> First of all, I find it difficult to pick which scripts would benefit >> the most by being rewritten. I am thinking of git bisect, git stash >> and

[PATCH v5 2/3] stash push: avoid printing errors

'git stash push -u -- ' prints the following errors if only matches untracked files: fatal: pathspec 'untracked' did not match any files error: unrecognized input This is because we first clean up the untracked files using 'git clean ', and then use a command chain involving 'git add -u

[PATCH v5 1/3] stash: fix nonsense pipeline

From: Junio C Hamano An earlier change bba067d2 ("stash: don't delete untracked files that match pathspec", 2018-01-06) was made by taking a suggestion in a list discussion [1] but did not copy the suggested snippet correctly. And the bug was unnoticed during the review and

[PATCH v5 3/3] stash push -u: don't create empty stash

When introducing the stash push feature, and thus allowing users to pass in a pathspec to limit the files that would get stashed in df6bba0937 ("stash: teach 'push' (and 'create_stash') to honor pathspec", 2017-02-28), this developer missed one place where the pathspec should be passed in. Namely

[PATCH v5 0/3] stash push -u -- fixes

Thanks again Marc for all the testing and Junio for fixing up my brown paper bag copy-pasto. This iteration addresses the breakage Marc noticed with the latest version of the patches, adds some more tests, and moves all the new tests to t3905 instead of t3903, which I just noticed exists and is a

Re: [GSoC] Regarding "Convert scripts to builtins"

Hi, On Sun, Mar 18, 2018 at 11:15 PM, Paul Sebastian Ungureanu wrote: > Hello, > > I am interested in the "Convert scripts to builtins" project. I have > recently started to analyze it better and see exactly what it entails > and a few questions came to my mind.

Re: [PATCH v2 2/2] git-svn: allow empty email-address in authors-prog and authors-file

Am 19.03.2018 um 00:04 schrieb Eric Wong: > Andreas Heiduk wrote: >> The email address in --authors-file and --authors-prog can be empty but >> git-svn translated it into a syntethic email address in the form >> $USERNAME@$REPO_UUID. Now git-svn behaves like git-commit: If the

Re: [PATCH] filter-branch: use printf instead of echo -e

On Mon, Mar 19, 2018 at 03:49:05PM +0100, Michele Locati wrote: > In order to echo a tab character, it's better to use printf instead of > "echo -e", because it's more portable (for instance, "echo -e" doesn't work > as expected on a Mac). > > This solves the "fatal: Not a valid object name"

Re: [PATCH v6 2/3] Makefile: add Perl runtime prefix support

On Mon, Mar 19, 2018 at 5:32 PM Martin Ågren wrote: > This commit message mentions RUNTIME_PREFIX_PERL twice, but there is no > use of RUNTIME_PREFIX_PERL in the actual diffs (patches 1-3/3). Should > it be s/_PERL//? Your cover letter hints as much under "Changes in v6 >

Re: [GSoC][PATCH v5] Make options that expect object ids less chatty if id is invalid

Paul-Sebastian Ungureanu writes: > Subject: Re: [GSoC][PATCH v5] Make options that expect object ids less chatty > if id is invalid For the past few iterations, this is no longer about "options that expect object IDs that get an invalid one" anymore, right?

Re: [PATCH v3 0/2] stash push -u -- fixes

On 03/19, Marc Strapetz wrote: > On 16.03.2018 21:43, Thomas Gummerer wrote: > >Thanks Marc for catching the regression I almost introduced and Junio > >for the review of the second patch. Here's a re-roll that should fix > >the issues of v2. > > Thanks, existing issues are fixed, but cleanup of

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Sergey, On 19/03/2018 06:44, Sergey Organov wrote: > > > > > > > Second side note: if we can fast-forward, currently we prefer > > > > > > that, and I think we should keep that behavior with -R, too. > > > > > > > > > > I agree. > > > > > > > > I'm admittedly somewhat lost in the discussion,

Re: [PATCH v6 2/3] Makefile: add Perl runtime prefix support

On 19 March 2018 at 03:50, Dan Jacques wrote: > Add a new Makefile flag, RUNTIME_PREFIX_PERL, which, when enabled, > configures Perl scripts to locate the Git installation's Perl support > libraries by resolving against the script's path, rather than > hard-coding that path at

[GSoC][PATCH v5] Make options that expect object ids less chatty if id is invalid

Usually, the usage should be shown only if the user does not know what options are available. If the user specifies an invalid value, the user is already aware of the available options. In this case, there is no point in displaying the usage anymore. This patch applies to "git tag --contains",

Re: [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git

On Mon, Mar 19, 2018, 04:34 Johannes Schindelin wrote: > > This is a real problem. No it isn't. We already handle those special cases specially, and install them in the bin directory (as opposed to libexec). And it all works fine. Look into the bin directory some

Re: What's cooking in git.git (Mar 2018, #03; Wed, 14)

On 3/15/2018 4:36 AM, Ævar Arnfjörð Bjarmason wrote: On Thu, Mar 15 2018, Junio C. Hamano jotted: * nd/repack-keep-pack (2018-03-07) 6 commits - SQUASH??? - pack-objects: display progress in get_object_details() - pack-objects: show some progress when counting kept objects - gc --auto:

Re: Bug With git rebase -p

Joseph Strauss writes: > I found the following erroneous behavior with "git rebase -p". > > My current version is git version 2.16.2.windows.1 > > I made an example at GitHub, https://github.com/jkstrauss/git-bug/ > > There seem to be two problems when rebasing merge

Re: [PATCH v4 1/4] worktree: improve message when creating a new worktree

Duy Nguyen writes: >> @@ -320,10 +318,19 @@ static int add_worktree(const char *path, const char >> *refname, >> if (ret) >> goto done; >> >> + fprintf(stderr, _("worktree HEAD is now at %s"), > > We use the term "working tree" for UI and

Bug With git rebase -p

I found the following erroneous behavior with "git rebase -p". My current version is git version 2.16.2.windows.1 I made an example at GitHub, https://github.com/jkstrauss/git-bug/ There seem to be two problems when rebasing merge commits with git rebase -p : 1. All lines of merge commits'

Re: [PATCH v6 2/3] Makefile: add Perl runtime prefix support

Daniel Jacques writes: >> > The merge conflict becomes a tad easier to deal with, also makes sense >> > to have gitexecdir after infodir since that's the order we're listing >> > these in just a few lines earlier, and this is otherwise (mostly) >> > consistent. > > Actually as a

Re: [PATCH 44/44] packfile: keep prepare_packed_git() private

On Sat, 3 Mar 2018 18:36:37 +0700 Nguyễn Thái Ngọc Duy wrote: > The reason callers have to call this is to make sure either packed_git > or packed_git_mru pointers are initialized since we don't do that by > default. Sometimes it's hard to see this connection between where

Re: Potential git bug

On Mon, Mar 19, 2018 at 04:14:31PM -0400, Nick Hunt wrote: > oh, wait, switching branches didn't vaporize my changes, it auto-committed > them. > which is still weird and possibly a bug? Are you sure that the changes were not already present on the switched-to branch? -Peff

Re: Potential git bug

oh, wait, switching branches didn't vaporize my changes, it auto-committed them. which is still weird and possibly a bug? Nick Hunt nhun...@gmail.com 404-988-1845 On Mon, Mar 19, 2018 at 3:13 PM, Nick Hunt wrote: > i committed my changes, then ran > git reset --soft HEAD^ >

Re: [PATCH 39/44] packfile: allow prepare_packed_git_one to handle arbitrary repositories

On Sat, 3 Mar 2018 18:36:32 +0700 Nguyễn Thái Ngọc Duy wrote: > From: Stefan Beller > > Signed-off-by: Stefan Beller > Signed-off-by: Junio C Hamano > Signed-off-by: Nguyễn Thái Ngọc Duy

Re: [PATCH v6 09/11] pack-objects: shrink size field in struct object_entry

Duy Nguyen writes: > There is a difference. For sizes smaller than 2^32, whatever you > pass to oe_set_size() will be returned by oe_size(), > consistently. It does not matter if this size is "good" If > it's different, oe_size() will return something else other than >

Re: feature-request: git "cp" like there is git mv.

Stefan Moch writes: > Are such redundant checks in general a pattern worth searching > for and cleaning up globally? Or is this rather in the category > of cleaning up only when noticed? A clean-up patch that is otherwise a no-op is still welcome as it will improve the

Re: [PATCH v6 2/3] Makefile: add Perl runtime prefix support

On Mon, Mar 19, 2018 at 3:21 PM Ævar Arnfjörð Bjarmason wrote: > I think it would be more idiomatic and more paranoid (we'll catch bugs) > to do: > my $exec_path; > if (exists $ENV{GIT_EXEC_PATH}) { > $exec_path = $ENV{GIT_EXEC_PATH}; > } else { >

Re: [PATCH v3 3/5] ref-filter: change parsing function error handling

Olga Telezhnaya writes: > Continue removing any printing from ref-filter formatting logic, > so that it could be more general. > > Change the signature of parse_ref_filter_atom() by adding > strbuf parameter for error message. > Return value means the same except

Re: [PATCH 10/44] object-store: move packed_git and packed_git_mru to object store

On Sat, 3 Mar 2018 18:36:03 +0700 Nguyễn Thái Ngọc Duy wrote: > From: Stefan Beller > > In a process with multiple repositories open, packfile accessors > should be associated to a single repository and not shared globally. > Move packed_git and

Re: [PATCH v6 3/3] exec_cmd: RUNTIME_PREFIX on some POSIX systems

On Mon, Mar 19, 2018 at 3:27 PM Ævar Arnfjörð Bjarmason wrote: > I wonder if it wouldn't be a lot more understandable if these were noted > together, i.e. let's first document RUNTIME_PREFIX, then for all the > other ones say below that: Sounds good to me, done. > Whitespace

Re: [PATCH v6 0/3] RUNTIME_PREFIX relocatable Git

On Mon, Mar 19 2018, Dan Jacques jotted: > I'm dusting this back off now that avarab@'s Perl Makefile simplification > patch set has landed. It's been a few months, so I'm a bit rusty, but I think > that I've incorporated all of the feedback. Please take a look and let me know > what you think!

Re: [PATCH v6 3/3] exec_cmd: RUNTIME_PREFIX on some POSIX systems

On Mon, Mar 19 2018, Dan Jacques jotted: > # > # Define HAVE_BSD_SYSCTL if your platform has a BSD-compatible sysctl > function. > # > +# Define HAVE_BSD_KERN_PROC_SYSCTL if your platform supports the KERN_PROC > BSD > +# sysctl function. > +# > +# Define PROCFS_EXECUTABLE_PATH if your

Re: [PATCH v3 2/5] ref-filter: add return value && strbuf to handlers

Olga Telezhnaya writes: > Continue removing any printing from ref-filter formatting logic, > so that it could be more general. "more general" sounds overly broad. Is this to avoid calling die() so that the caller can decide what error messages it wants to give, abort

Re: [PATCH v6 2/3] Makefile: add Perl runtime prefix support

> > The merge conflict becomes a tad easier to deal with, also makes sense > > to have gitexecdir after infodir since that's the order we're listing > > these in just a few lines earlier, and this is otherwise (mostly) > > consistent. Actually as a quick follow-up question: for these patch sets,

Re: [PATCH v6 2/3] Makefile: add Perl runtime prefix support

On Mon, Mar 19, 2018 at 3:12 PM Ævar Arnfjörð Bjarmason wrote: > The merge conflict becomes a tad easier to deal with, also makes sense > to have gitexecdir after infodir since that's the order we're listing > these in just a few lines earlier, and this is otherwise (mostly) >

Potential git bug

i committed my changes, then ran git reset --soft HEAD^ at this point everything is fine then i switched branches, and all of my changes vaporized into thin air. uhhh, is this supposed to happen? anyway, thank god intellij saves my work for me as i go, so i didn't have to re-write all my code.

Re: [PATCH v2 00/36] Promisor remotes and external ODB support

Christian Couder writes: > A lot of things are different because the jh/fsck-promisors and > jh/partial-clone have been merged into master since the v1. So the > integration is much more complete now (though not fully complete), and > this integration happens quite

Re: [PATCH v6 2/3] Makefile: add Perl runtime prefix support

On Mon, Mar 19 2018, Dan Jacques jotted: > +gitexecdir_relative = $(patsubst $(prefix)/%,%,$(gitexecdir)) > mandir_relative = $(patsubst $(prefix)/%,%,$(mandir)) > infodir_relative = $(patsubst $(prefix)/%,%,$(infodir)) > +localedir_relative = $(patsubst $(prefix)/%,%,$(localedir)) >

Re: [PATCH v6 07/14] commit-graph: implement 'git-commit-graph write'

On 3/19/2018 10:36 AM, Ævar Arnfjörð Bjarmason wrote: On Mon, Mar 19 2018, Derrick Stolee jotted: On 3/18/2018 9:25 AM, Ævar Arnfjörð Bjarmason wrote: On Wed, Mar 14 2018, Derrick Stolee jotted: +'git commit-graph write' [--object-dir ] + + +DESCRIPTION +--- + +Manage the

Re: [PATCH v3 2/7] gc: add --keep-base-pack

On Mon, Mar 19 2018, Duy Nguyen jotted: > On Fri, Mar 16, 2018 at 10:05 PM, Ævar Arnfjörð Bjarmason > wrote: >> >> On Fri, Mar 16 2018, Nguyễn Thái Ngọc Duy jotted: >> >>> +--keep-base-pack:: >>> + All packs except the base pack and those marked with a `.keep` >>> +

Re: [PATCH v6 09/11] pack-objects: shrink size field in struct object_entry

Duy Nguyen writes: > This is why I do "size_valid = size_ == size". In my private build, I > reduced size_ to less than 32 bits and change the "fits_in_32bits" > function to do something like > > int fits_in_32bits(unsigned long size) > { > struct object_entry e; > e.size_ =

Re: [PATCH 02/44] repository.c: move env-related setup code back to environment.c

On Mon, Mar 19, 2018 at 7:07 PM, Jonathan Tan wrote: >> -extern void repo_set_gitdir(struct repository *repo, const char *path); >> +struct set_gitdir_args { >> + const char *commondir; >> + const char *object_dir; >> + const char *graft_file; >> + const

[GSoC][PATCH v5] Make options that expect object ids less chatty if id is invalid

Usually, the usage should be shown only if the user does not know what options are available. If the user specifies an invalid value, the user is already aware of the available options. In this case, there is no point in displaying the usage anymore. This patch applies to "git tag --contains",

Re: [GSoC][PATCH v4] Make options that expect object ids less chatty if id is invalid

Hello, Thank you for your advice! Soon enough, I wil submit a new patch which fixes the issues you mentioned. Best regards, Paul Ungureanu

Re: [PATCH v6 07/14] commit-graph: implement 'git-commit-graph write'

On Mon, Mar 19 2018, Derrick Stolee jotted: > On 3/19/2018 10:36 AM, Ævar Arnfjörð Bjarmason wrote: >> On Mon, Mar 19 2018, Derrick Stolee jotted: >> >>> On 3/18/2018 9:25 AM, Ævar Arnfjörð Bjarmason wrote: On Wed, Mar 14 2018, Derrick Stolee jotted: > +'git commit-graph write'

Re: [PATCH v6 09/11] pack-objects: shrink size field in struct object_entry

On Mon, Mar 19, 2018 at 7:29 PM, Junio C Hamano wrote: + if (!e->size_valid) { + unsigned long real_size; + + if (sha1_object_info(e->idx.oid.hash, _size) < 0 || + size != real_size) +

Re: [PATCH 02/44] repository.c: move env-related setup code back to environment.c

On Sat, 3 Mar 2018 18:35:55 +0700 Nguyễn Thái Ngọc Duy wrote: > It does not make sense that generic repository code contains handling > of environment variables, which are specific for the main repository > only. Refactor repo_set_gitdir() function to take $GIT_DIR and >

Re: [PATCH v2] filter-branch: use printf instead of echo -e

Michele Locati writes: > In order to echo a tab character, it's better to use printf instead of > "echo -e", because it's more portable (for instance, "echo -e" doesn't work > as expected on a Mac). > > This solves the "fatal: Not a valid object name" error in

[PATCH 2/2] read-cache: fix an -Wmaybe-uninitialized warning

The function ce_write_entry() uses a 'self-initialised' variable construct, for the symbol 'saved_namelen', to suppress a gcc '-Wmaybe-uninitialized' warning, given that the warning is a false positive. For the purposes of this discussion, the ce_write_entry() function has three code blocks of

PATCH 1/2] -Wuninitialized: remove some 'init-self' workarounds

The 'self-initialised' variables construct (ie var = var;) has been used to silence gcc '-W[maybe-]uninitialized' warnings. This has, unfortunately, caused MSVC to issue 'uninitialized variable' warnings. Also, using clang static analysis causes complaints about an 'Assigned value is garbage or

Re: [PATCH] mingw: abort on invalid strftime formats

Johannes Schindelin writes: > On Windows, strftime() does not silently ignore invalid formats, but > warns about them and then returns 0 and sets errno to EINVAL. > > Unfortunately, Git does not expect such a behavior, as it disagrees > with strftime()'s semantics on

[PATCH 0/2] -Wuninitialized

This series removes all 'self-initialised' variables (ie. var = var;). This construct has been used to silence gcc '-W[maybe-]uninitialized' warnings in the past [1]. Unfortunately, this construct causes warnings to be issued by MSVC [2], along with clang static analysis complaining about an

Re: Bad refspec messes up bundle.

Luciano Joublanc writes: > Yesterday I created a git bundle as best as I can remember like this > > git bundle save chunk chunk.bundle --all master > > Note the 'master' I added accidentally at the end - this was a user > error but still the bundle was created. > > When I

[GSoC][PATCH] test: avoid pipes in git related commands for test suite

Thank you Eric Sunshine, I have done as you had instructed me. I look forward to more understanding of the codebase and would love to fix "git rev-parse" problems in my follow-on patches. Thank you for the professional review comment. Sorry for late follow-on patch, I got tied up with my

Re: [PATCH 0/2] routines to generate JSON data

On 3/17/2018 3:38 AM, Jacob Keller wrote: On Fri, Mar 16, 2018 at 2:18 PM, Jeff King wrote: 3. Some other similar format. YAML comes to mind. Last time I looked (quite a while ago), it seemed insanely complex, but I think you could implement only a reasonable

Re: [PATCH v6 3/3] exec_cmd: RUNTIME_PREFIX on some POSIX systems

On Mon, Mar 19, 2018 at 1:24 PM Junio C Hamano wrote: > Look for these misspelled words: Oh boy ... thanks, and done. > OK. An essentially no-op change but with the name better suited in > the extended context---we used to only care about argv0 but that was > an

Re: [GSoC] Scripts to be conversted into builtins

Hi, On Sat, 17 Mar 2018, Yash Yadav wrote: > In the project ideas listed there is one idea talking of conversion of > scripts to builtins. This interests me but no pointer forward is given > and I'd like to dive more into that idea and go through the script(s). > > So, where should I look

Re: [PATCH v3 2/7] gc: add --keep-base-pack

On Fri, Mar 16, 2018 at 10:05 PM, Ævar Arnfjörð Bjarmason wrote: > > On Fri, Mar 16 2018, Nguyễn Thái Ngọc Duy jotted: > >> +--keep-base-pack:: >> + All packs except the base pack and those marked with a `.keep` >> + files are consolidated into a single pack. The largest

Re: [PATCH v6 3/3] exec_cmd: RUNTIME_PREFIX on some POSIX systems

Dan Jacques writes: > Enable Git to resolve its own binary location using a variety of > OS-specific and generic methods, including: > > - procfs via "/proc/self/exe" (Linux) > - _NSGetExecutablePath (Darwin) > - KERN_PROC_PATHNAME sysctl on BSDs. > - argv0, if absolute (all,

Re: [PATCH v6 2/3] Makefile: add Perl runtime prefix support

On Mon, Mar 19, 2018 at 1:14 PM Junio C Hamano wrote: > > +# RUNTIME_PREFIX's resolution logic requires resource paths to be expressed > > +# relative to each other and share an installation path. > > +# > > +# This is a dependnecy in: > dependency? Oops, this is the second

Re: [PATCH v6 2/3] Makefile: add Perl runtime prefix support

Dan Jacques writes: > +# RUNTIME_PREFIX's resolution logic requires resource paths to be expressed > +# relative to each other and share an installation path. > +# > +# This is a dependnecy in: dependency? > +# - Git's binary RUNTIME_PREFIX logic in (see "exec_cmd.c"). > +# -

Re: [PATCH 1/2] completion: improve ls-files filter performance

Hi drizzd, first of all: thank you so much for working on this. I am sure it will be noticeable to many Windows users, and also make my life easier. On Sat, 17 Mar 2018, Clemens Buchacher wrote: > From the output of ls-files, we remove all but the leftmost path > component and then we eliminate

Re: [PATCH v4 1/4] worktree: improve message when creating a new worktree

On Sat, Mar 17, 2018 at 11:22 PM, Thomas Gummerer wrote: > Currently 'git worktree add' produces output like the following, when > '--no-checkout' is not given: > > Preparing foo (identifier foo) > HEAD is now at 26da330922 > > where the first line is written to

Re: [PATCH v6 0/3] RUNTIME_PREFIX relocatable Git

Dan Jacques writes: > This patch set expands support for the RUNTIME_PREFIX configuration flag, > currently only used on Windows builds, to include Linux, Darwin, and > FreeBSD. When Git is built with RUNTIME_PREFIX enabled, it resolves its > ancillary paths relative to the

Re: [PATCH] completion: complete tags with git tag --delete/--verify

Todd Zullinger writes: > Completion of tag names has worked for the short -d/-v options since > 88e21dc746 ("Teach bash about completing arguments for git-tag", > 2007-08-31). The long options were not added to "git tag" until many > years later, in c97eff5a95 ("git-tag:

Re: [PATCH v6 09/11] pack-objects: shrink size field in struct object_entry

On Mon, Mar 19, 2018 at 5:43 PM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> +static inline void oe_set_size(struct object_entry *e, >> +unsigned long size) >> +{ >> + e->size_ = size; >> + e->size_valid =

Re: [PATCH 1/1] Fix typo in merge-strategies documentation

David Pursehouse writes: > From: David Pursehouse > > Signed-off-by: David Pursehouse > --- I somehow had to stare at the patch for a few minutes, view it in two Emacs buffers and run M-x compare-windows before I

[PATCH] mingw: abort on invalid strftime formats

On Windows, strftime() does not silently ignore invalid formats, but warns about them and then returns 0 and sets errno to EINVAL. Unfortunately, Git does not expect such a behavior, as it disagrees with strftime()'s semantics on Linux. As a consequence, Git misinterprets the return value 0 as "I

Re: [PATCH v6 09/11] pack-objects: shrink size field in struct object_entry

Nguyễn Thái Ngọc Duy writes: > +static inline void oe_set_size(struct object_entry *e, > +unsigned long size) > +{ > + e->size_ = size; > + e->size_valid = e->size_ == size; A quite similar comment as my earlier one applies here. I wonder

Re: [PATCH] Makefile: detect compiler and enable more warnings in DEVELOPER=1

On Sun, Mar 18, 2018 at 7:56 PM, Ramsay Jones wrote: > > > On 18/03/18 15:55, Duy Nguyen wrote: >> On Sun, Mar 18, 2018 at 9:18 AM, Nguyễn Thái Ngọc Duy >> wrote: >>> +ifneq ($(or $(filter gcc6,$(COMPILER_FEATURES)),$(filter >>>

Re: [PATCH v6 09/11] pack-objects: shrink size field in struct object_entry

On Mon, Mar 19, 2018 at 5:19 PM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> +static inline int oe_fits_in_32bits(unsigned long limit) >> +{ >> + uint32_t truncated_limit = (uint32_t)limit; >> + >> + return limit == truncated_limit; >>

Re: [PATCH v6 09/11] pack-objects: shrink size field in struct object_entry

Nguyễn Thái Ngọc Duy writes: > +static inline int oe_fits_in_32bits(unsigned long limit) > +{ > + uint32_t truncated_limit = (uint32_t)limit; > + > + return limit == truncated_limit; > +} I do not think it is worth a reroll (there only are a few callsites), but the

[PATCH v2] filter-branch: use printf instead of echo -e

In order to echo a tab character, it's better to use printf instead of "echo -e", because it's more portable (for instance, "echo -e" doesn't work as expected on a Mac). This solves the "fatal: Not a valid object name" error in git-filter-branch when using the --state-branch option. Furthermore,

Re: [PATCH 04/36] t/helper: merge test-lazy-init-name-hash into test-tool

On Mon, Mar 19, 2018 at 10:40 AM, Jeff Hostetler wrote: > > > On 3/18/2018 4:47 AM, Eric Sunshine wrote: >> >> On Sun, Mar 18, 2018 at 4:25 AM, Duy Nguyen wrote: >>> >>> On Sun, Mar 18, 2018 at 3:11 AM, Eric Sunshine >>> wrote:

Re: [PATCH v3 0/2] stash push -u -- fixes

On 16.03.2018 21:43, Thomas Gummerer wrote: Thanks Marc for catching the regression I almost introduced and Junio for the review of the second patch. Here's a re-roll that should fix the issues of v2. Thanks, existing issues are fixed, but cleanup of the stashed files seems to not work

[PATCH] filter-branch: use printf instead of echo -e

In order to echo a tab character, it's better to use printf instead of "echo -e", because it's more portable (for instance, "echo -e" doesn't work as expected on a Mac). This solves the "fatal: Not a valid object name" error in git-filter-branch when using the --state-branch option.

  1   2   >