Re: [ANNOUNCE] Git v2.16.0-rc0

On Friday 29 December 2017 10:00 AM, Junio C Hamano wrote: * "git branch" and "git checkout -b" are now forbidden from creating a branch whose name is "HEAD". "git branch" already forbid a branch named "HEAD", didn't it? I thought we just made "git checkout -b" to reject "HEAD" as a

Re: [PATCH] Add shell completion for git remote rm

Sorry about that! Patch below. Previously git remote rm did not complete your list of removes as remove does. Signed-off-by: Keith Smiley --- contrib/completion/git-completion.bash | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH] Add shell completion for git remote rm

On Fri, Dec 29, 2017 at 02:01:00AM +, Keith Smiley wrote: > From: Keith Smiley > > Previously git remote rm did not complete your list of removes as remove > does. Your signed-off-by[1] is missing, could you please add that? [1]:

Re: [PATCH] merge: teach -Xours/-Xtheirs to symbolic link merge

On Thu, 28 Dec 2017, Elijah Newren wrote: > > Teach a similar trick to the codepath that deals with merging two > > conflicting changes to symbolic links. > Saw this change referenced in the "what's cooking" emails and decided > to review this. The code changes look obviously correct to me, and

[ANNOUNCE] Git v2.16.0-rc0

An early preview release Git v2.16.0-rc0 is now available for testing at the usual places. It is comprised of 435 non-merge commits since v2.15.0, contributed by 76 people, 22 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The

Re: [PATCH] Add shell completion for git remote rm

It looks like that was just about preferring remove in documentation and the like, I think it would still make sense to have both for completion since rm is still supported. -- Keith Smiley On 12/28, Todd Zullinger wrote: Hi Keith, Keith Smiley wrote: Previously git remote rm did not

With All Due Respect!

Greetings, Kindly Accept & Acknowledge my Proposal. I am (Mrs.Louisa Benicio), a Widow without child, I decided to donate what I have to you for investment towards the good work of charity organization, and also to help the motherless and the less privileged ones and to carry out charity works

Re: [PATCH] Add shell completion for git remote rm

Hi Keith, Keith Smiley wrote: > Previously git remote rm did not complete your list of removes as remove > does. Looking through the history, the rm subcomand completion was explicitly removed in e17dba8fe1 ("remote: prefer subcommand name 'remove' to 'rm'", 2012-09-06). -- Todd

Re: [PATCH] merge: teach -Xours/-Xtheirs to symbolic link merge

On Sun, Oct 15, 2017 at 10:38 PM, Junio C Hamano wrote: > The -Xours/-Xtheirs merge options were originally defined as a way > to "force" the resolution of 3way textual merge conflicts to take > one side without using your editor, hence did not even trigger in > situations

[PATCH] Add shell completion for git remote rm

From: Keith Smiley Previously git remote rm did not complete your list of removes as remove does. --- contrib/completion/git-completion.bash | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.bash

Re: [PATCH v3 7/7] wildmatch test: create & test files on disk in addition to in-memory

On Thu, Dec 28 2017, Ævar Arnfjörð Bjarmason jotted: > + pattern=$10 Junio, in lie of me spamming the list too much, do you mind squashing this into this (if no further issues arise): diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh index d7aa7eb5fe..f985139b6f 100755 ---

Re: [PATCH v2 0/7] increase wildmatch test coverage

On Thu, Dec 28 2017, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason writes: > >> This v2 addresses comments by Johannes Sixt in >> <8f4cdb23-8e2e-144a-1f70-99776b027...@kdbg.org> and there's osme other >> cleanups as noted below. > > One thing I found "interesting"

[PATCH v3 5/7] wildmatch test: remove dead fnmatch() test code

Remove the unused fnmatch() test parameter from the wildmatch test. The code that used to test this was removed in 70a8fc999d ("stop using fnmatch (either native or compat)", 2014-02-15). As a --word-diff shows the only change to the body of the tests is the removal of the second out of four

[PATCH v3 7/7] wildmatch test: create & test files on disk in addition to in-memory

There has never been any full roundtrip testing of what git-ls-files and other functions that use wildmatch() actually do, rather we've been satisfied with just testing the underlying C function. Due to git-ls-files and friends having their own codepaths before they call wildmatch() there's

[PATCH v3 2/7] wildmatch test: use more standard shell style

Change the wildmatch test to use more standard shell style, usually we use "if test" not "if [". Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t3070-wildmatch.sh | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/t/t3070-wildmatch.sh

[PATCH v3 1/7] wildmatch test: indent with tabs, not spaces

Replace the 4-width mixed space & tab indentation in this file with indentation with tabs as we do in most of the rest of our tests. Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t3070-wildmatch.sh | 54 ++-- 1 file changed, 27

[PATCH v3 3/7] wildmatch test: don't try to vertically align our output

Don't try to vertically align the test output, which is futile anyway under the TAP output where we're going to be emitting a number for each test without aligning the test count. This makes subsequent changes of mine where I'm not going to be aligning this output as I add new tests easier.

[PATCH v3 4/7] wildmatch test: use a paranoia pattern from nul_match()

Use a pattern from the nul_match() function in t7008-grep-binary.sh to make sure that we don't just fall through to the "else" if there's an unknown parameter. This is something I added in commit 77f6f4406f ("grep: add a test helper function for less verbose -f \0 tests", 2017-05-20) to grep

[PATCH v3 6/7] wildmatch test: perform all tests under all wildmatch() modes

Rewrite the wildmatch() test suite so that each test now tests all combinations of the wildmatch() WM_CASEFOLD and WM_PATHNAME flags. Before this change some test inputs were not tested on e.g. WM_PATHNAME. Now the function is stress tested on all possible inputs, and for each input we declare

[PATCH v3 0/7] increase wildmatch test coverage

Fixes issues noted since v2 and one I spotted myself, notes below: Ævar Arnfjörð Bjarmason (7): wildmatch test: indent with tabs, not spaces wildmatch test: use more standard shell style wildmatch test: don't try to vertically align our output wildmatch test: use a paranoia pattern from

Re: [PATCH v2 0/7] increase wildmatch test coverage

Ævar Arnfjörð Bjarmason writes: > This v2 addresses comments by Johannes Sixt in > <8f4cdb23-8e2e-144a-1f70-99776b027...@kdbg.org> and there's osme other > cleanups as noted below. One thing I found "interesting" (because it is usually the other way around) is that about two

Re: [PATCH 4/4] builtin/blame: highlight recently changed lines

On Thu, Dec 28, 2017 at 4:03 PM, Stefan Beller wrote: > Choose a different color for dates and imitate a 'temperature cool down' > for the dates. s/for the dates/depending upon age/ > [...] > Signed-off-by: Stefan Beller > --- > diff --git

Re: [PATCH 2/4] builtin/blame: dim uninteresting metadata

On Thu, Dec 28, 2017 at 4:03 PM, Stefan Beller wrote: > When using git-blame lots of lines contain redundant information, for > example in hunks that consist of multiple lines, the metadata (commit > name, author, date) are repeated. A reader may not be interested in those, >

Re: [PATCH 1/4] color.h: document and modernize header

On Thu, Dec 28, 2017 at 4:03 PM, Stefan Beller wrote: > Add documentation explaining the functions in color.h. > While at it, mark them extern. > > Signed-off-by: Stefan Beller > --- > diff --git a/color.h b/color.h > @@ -72,26 +72,48 @@ extern int

Re: [PATCH 1/1] diffcore: add a pickaxe option to find a specific blob

On Thu, Dec 28, 2017 at 1:33 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> +static int parse_objfind_opt(struct diff_options *opt, const char *arg) >> +{ >> + struct object_id oid; >> + >> + if (get_oid(arg, )) >> + return

Re: [PATCH 1/1] diffcore: add a pickaxe option to find a specific blob

Stefan Beller writes: > +static int parse_objfind_opt(struct diff_options *opt, const char *arg) > +{ > + struct object_id oid; > + > + if (get_oid(arg, )) > + return error("unable to resolve '%s'", arg); > + > + if (!opt->objfind) > +

Re: [PATCH v2 7/9] checkout: avoid using the rev_info flag leak_pending

René Scharfe writes: > diff --git a/builtin/checkout.c b/builtin/checkout.c > index f9f3797e11..afb225ca79 100644 > --- a/builtin/checkout.c > +++ b/builtin/checkout.c > @@ -790,37 +790,26 @@ static void suggest_reattach(struct commit *commit, > struct rev_info *revs) > static

Re: [PATCH v2 6/9] bundle: avoid using the rev_info flag leak_pending

René Scharfe writes: > The leak_pending flag is so awkward to use that multiple comments had to > be added around each occurrence. We use it for remembering the > prerequisites for the bundle. That is easy, though: We have the > ref_list named "prerequisites" in the header for

[PATCH 3/4] builtin/blame: add option to color metadata fields separately

Unlike the previous commit, this dims colors for each metadata field individually. Signed-off-by: Stefan Beller --- builtin/blame.c | 82 +++-- t/t8012-blame-colors.sh | 38 +++ 2 files changed, 111

[PATCH 1/4] color.h: document and modernize header

Add documentation explaining the functions in color.h. While at it, mark them extern. Signed-off-by: Stefan Beller --- color.c | 2 -- color.h | 48 +++- 2 files changed, 35 insertions(+), 15 deletions(-) diff --git a/color.c

[PATCH 2/4] builtin/blame: dim uninteresting metadata

When using git-blame lots of lines contain redundant information, for example in hunks that consist of multiple lines, the metadata (commit name, author, date) are repeated. A reader may not be interested in those, so offer an option to color the information that is repeated from the previous line

[PATCHv2 0/4] blame: (dim rep. metadata lines or fields, decay date coloring)

This is picking up [1], but presenting it in another approach, as I realized these are orthogonal features: * dimming repeated lines/fields of information * giving a quick visual information how old (as a proxy for 'well tested') a line of code is. Both features are configurable. Changes

[PATCH 4/4] builtin/blame: highlight recently changed lines

Choose a different color for dates and imitate a 'temperature cool down' for the dates. Originally I had planned to have the temperature cooldown dependent on the age of the project or file for example, as that might scale better, but that can be added on top of this commit, e.g. instead of

Re: [PATCH v2 0/9] revision: get rid of the flag leak_pending

René Scharfe writes: > The flag leak_pending is weird, let's get rid of it. > > Changes from v1: Everything. ;-) > An independent optimization found while working on this series: > > commit: avoid allocation in clear_commit_marks_many() > > Trivial unrelated conversions

Re: [PATCH v2 6/7] wildmatch test: perform all tests under all wildmatch() modes

Ævar Arnfjörð Bjarmason writes: > + if test "$match_w_pathmatchi" = 1 > + then > + test_expect_success "ipathmatch:match '$text' '$pattern'" " > + test-wildmatch ipathmatch '$text' '$pattern' > + " > + elif test

Re: [PATCH] dir.c: avoid stat() in valid_cached_dir()

On Thu, Dec 28 2017, Nguyễn Thái Ngọc Duy jotted: > stat() may follow a symlink and return stat data of the link's target > instead of the link itself. We are concerned about the link itself. > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > I noticed this while looking at the

Re: [PATCH v2 3/7] perf/aggregate: implement codespeed JSON output

Christian Couder writes: > ... > +sub print_codespeed_results { > + my ($results_section) = @_; > + > + #use Data::Dumper qw/ Dumper /; > + #print Dumper(\@data); Perhaps lose these. It is OK to keep the code live and hide it behind --debug or something,

Re: [PATCH v2 1/7] perf/aggregate: fix checking ENV{GIT_PERF_SUBSECTION}

Christian Couder writes: > Signed-off-by: Christian Couder > --- > t/perf/aggregate.perl | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/t/perf/aggregate.perl b/t/perf/aggregate.perl > index e401208488..769d418708

Re: [PATCH v2 0/7] Codespeed perf results

Christian Couder writes: > This patch series is built on top of cc/perf-run-config which recently > graduated to master. > > It makes it possible to send perf results to a Codespeed server. See > https://github.com/tobami/codespeed/ and web sites like >

Re: [PATCH] git-archive: accepts --owner --group aslike GNU tar.

suzuki toshiya writes: > Current tar output by git-archive has always root:root. Thanks for a patch. On top of Ævar's comments... > ... > * t/t5005-archive-uid-gid.sh: a test script comparing > uid, gid, uname, gname between the options and > generated tar

Re: [PATCH] dir.c: avoid stat() in valid_cached_dir()

Junio C Hamano writes: >> [1] >> https://public-inbox.org/git/cacsjy8ambksp0mdlradcwn45veenc03b-gq8r8pqprdt9bm...@mail.gmail.com/ >> >> dir.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/dir.c b/dir.c >> index 7c4b45e30e..edcb7bb462 100644 >>

Re: [PATCH v2 2/2] Windows: stop supplying BLK_SHA1=YesPlease by default

Ævar Arnfjörð Bjarmason wrote: > Using BLK_SHA1 in lieu of the OpenSSL routines was done in > 9bccfcdbff ("Windows: use BLK_SHA1 again", 2009-10-22), since DC_SHA1 > is now the default for git in general it makes sense for Windows to > use that too, this looks like something that was missed back

Re: [PATCH] dir.c: avoid stat() in valid_cached_dir()

Nguyễn Thái Ngọc Duy writes: > stat() may follow a symlink and return stat data of the link's target > instead of the link itself. We are concerned about the link itself. > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > I noticed this while looking at the

Re: [PATCH v2 1/2] Makefile: NO_OPENSSL=1 should no longer imply BLK_SHA1=1

Ævar Arnfjörð Bjarmason wrote: > Use the collision detecting SHA-1 implementation by default even when > NO_OPENSSL is set. > > Setting NO_OPENSSL=UnfortunatelyYes has implied BLK_SHA1=1 ever since > the former was introduced in dd53c7ab29 (Support for NO_OPENSSL, > 2005-07-29). That implication

Re: What's cooking in git.git (Dec 2017, #05; Wed, 27)

Elijah Newren writes: > surprised by the branch name, though. Was 'ew/' a typo, Blush X-<. Yes it is a typo.

Re: [PATCH 2/2] travis-ci: record and skip successfully built trees

SZEDER Gábor writes: > I was aware that things like 'cmd file >file' don't work, because the > shell opens and truncates 'file' before executing the command, so 'cmd' > will open the already empty file, but I didn't know that 'echo "$(cmd > file)" >file' works. Thanks for

Re: [PATCH v2 8/9] rebase -i: learn to abbreviate command names

Liam Beguin writes: > Since this came up, would it be a good thing to add -Wignored-qualifiers > to the DEVELOPER flags? Quite frankly, I am not sure if catching that particular warning violation buys us much. As a return value from a function is never an lvalue, what

Re: [PATCH v6] Makefile: replace perl/Makefile.PL with simple make rules

Ævar Arnfjörð Bjarmason writes: >> Here is the difference as I see between what we already have and >> this update, and a proposed summary. >> ... > > When I read this back on the 22nd I missed that you were waiting on my > feedback on this. Just saw What's Cooking now. Yes,

Re: [PATCH] status: add a failing test showing a core.untrackedCache bug

Duy Nguyen writes: >> Duy, what am I missing here? > > The problem is there, it's just easier to see or verify with > symlinks. Below is my test patch on top of your original one. Two > points: > > - if you look at the test-dump-untracked-cache output, you can see the >

Re: [PATCH 1/2] travis-ci: don't try to create the cache directory unnecessarily

SZEDER Gábor wrote: > On Wed, Dec 27, 2017 at 8:46 PM, Jonathan Nieder wrote: > > SZEDER Gábor wrote: >>> Travis CI creates that directory for us anyway, even when a previous >>> cache doesn't exist for the current build job. >>> >>> In itself it doesn't hurt to try, of

Re: [PATCH v1] convert: add support for 'encoding' attribute

> On 17 Dec 2017, at 18:14, Torsten Bögershausen wrote: > > On Mon, Dec 11, 2017 at 04:50:23PM +0100, lars.schnei...@autodesk.com wrote: >> From: Lars Schneider >> >> +`encoding` >> +^^ >> + >> +By default Git assumes UTF-8 encoding for text

Bug/feature request: Can’t disable fsck warnings during clone

Hi! I’ve set transfer.fsckObjects to true globally, for safety. Unfortunately, this messed up my Spacevim install. Doing some digging, I found that some of the repos had a warning. I can turn the warning off, but that only affects git fsck, not git clone. Turning off transfer.fsckObjects also

Re: [PATCH] git-archive: accepts --owner --group aslike GNU tar.

On Thu, Dec 28 2017, suzuki toshiya jotted: Thanks for working on this Just a quick review from skimming this, haven't actually applied + run this: > git-archive: accepts --owner --group aslike GNU tar. Make this: git-archive: accept --owner and --group like GNU tar I.e. imperative

[PATCH v2 1/2] Makefile: NO_OPENSSL=1 should no longer imply BLK_SHA1=1

Use the collision detecting SHA-1 implementation by default even when NO_OPENSSL is set. Setting NO_OPENSSL=UnfortunatelyYes has implied BLK_SHA1=1 ever since the former was introduced in dd53c7ab29 (Support for NO_OPENSSL, 2005-07-29). That implication should have been removed when the default

[PATCH v2 0/2] When DC_SHA1 was made the default we missed a spot

On Wed, Dec 27 2017, Jonathan Nieder jotted: Here's v2, the only changes are to the commit messages. > Ævar Arnfjörð Bjarmason wrote: > >> Stop supplying BLK_SHA1=YesPlease when NO_OPENSSL=UnfortunatelyYes is >> supplied. This has been done ever since [1], when switching to DC_SHA1 >> by default

[PATCH v2 2/2] Windows: stop supplying BLK_SHA1=YesPlease by default

Using BLK_SHA1 in lieu of the OpenSSL routines was done in 9bccfcdbff ("Windows: use BLK_SHA1 again", 2009-10-22), since DC_SHA1 is now the default for git in general it makes sense for Windows to use that too, this looks like something that was missed back in e6b07da278 ("Makefile: make DC_SHA1

Re: [PATCH 2/2] Windows: stop supplying BLK_SHA1=YesPlease by default

On Wed, Dec 27 2017, Jonathan Nieder jotted: > +git-for-windows > Ævar Arnfjörð Bjarmason wrote: > >> Using BLK_SHA1 in lieu of the OpenSSL routines was done in [1], but >> since DC_SHA1 is now the default for git in general it makes sense for >> Windows to use that too, this looks like

Re: [PATCH v3 3/4] travis-ci: save prove state for the 32 bit Linux build

> On 27 Dec 2017, at 22:42, SZEDER Gábor wrote: > > On Wed, Dec 27, 2017 at 7:46 PM, Lars Schneider > wrote: >>> + --volume "${HOME}/travis-cache:/tmp/travis-cache" \ >> >> I assume "${HOME}/travis-cache:/usr/src/git/t/.prove" would not >>

Re: [PATCH 2/2] travis-ci: record and skip successfully built trees

> On 28 Dec 2017, at 00:00, SZEDER Gábor wrote: > > On Wed, Dec 27, 2017 at 8:15 PM, Lars Schneider > wrote: >> >>> On 27 Dec 2017, at 17:49, SZEDER Gábor wrote: >>> +# Skip the build job if the same tree has already been

Re: [PATCH 2/2] travis-ci: record and skip successfully built trees

> On 28 Dec 2017, at 11:31, SZEDER Gábor wrote: > > On Wed, Dec 27, 2017 at 8:35 PM, Lars Schneider > wrote: >> >>> On 27 Dec 2017, at 17:49, SZEDER Gábor wrote: > >>> Using an ever-growing flat text file might seem like

Re: [PATCH 1/2] travis-ci: don't try to create the cache directory unnecessarily

On Wed, Dec 27, 2017 at 8:46 PM, Jonathan Nieder wrote: > SZEDER Gábor wrote: > >> Travis CI creates that directory for us anyway, even when a previous >> cache doesn't exist for the current build job. >> >> In itself it doesn't hurt to try, of course, but the following patch

Re: [PATCH 2/2] travis-ci: record and skip successfully built trees

On Wed, Dec 27, 2017 at 8:35 PM, Lars Schneider wrote: > >> On 27 Dec 2017, at 17:49, SZEDER Gábor wrote: >> Using an ever-growing flat text file might seem like asking for >> trouble on the long run, but it's perfectly adequate for this purpose.

[PATCH] git-archive: accepts --owner --group aslike GNU tar.

Current tar output by git-archive has always root:root. To generate tar output with non-root owner/group, the options like GNU tar are added. * archive.h: add members 'uid', 'gid', 'uname', 'gname' to struct archiver_args. * archive.c: add functions to reflect the operands of '--owner' and