Did You Get My Message This Time?

-- This is the second time i am sending you this mail.I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally for more details. Regards.Friedrich Mayrhofer

[GSoC][PATCH v4] t2027: avoid using pipes

From: Prathamesh Whenever a git command is present in the upstream of a pipe, its failure gets masked by piping and hence it should be avoided for testing the upstream git command. By writing out the output of the git command to a file, we can test the exit codes of both

Re: [PATCH] branch doc: update description for `--list`

On Fri, Mar 24, 2017 at 5:56 AM, Junio C Hamano wrote: > The paragraph begins with a sample command line `git branch ` > that has nothing to do with the option being described. Remove it, > but use the space to instead show that multiple patterns can be > given. > > Also

Re: [PATCH v2] travis-ci: build and test Git on Windows

> On 24 Mar 2017, at 12:48, Daniel Stenberg wrote: > > On Fri, 24 Mar 2017, Lars Schneider wrote: > >> Most Git developers work on Linux and they have no way to know if their >> changes would break the Git for Windows build. Let's fix that by adding a >> job to TravisCI that

RE: [PATCH v1 1/3] pkt-line: add packet_write_list_gently()

> -Original Message- > From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Wednesday, March 22, 2017 4:21 PM > To: Ben Peart > Cc: git@vger.kernel.org; Ben Peart ; > christian.cou...@gmail.com; larsxschnei...@gmail.com > Subject: Re: [PATCH

RE: [PATCH v1 2/3] sub-process: refactor the filter process code into a reusable module

> -Original Message- > From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Thursday, March 23, 2017 2:17 AM > To: Ben Peart > Cc: git@vger.kernel.org; Ben Peart ; > christian.cou...@gmail.com; larsxschnei...@gmail.com > Subject: Re: [PATCH

report on a possible bug: git commit -p myfile.py unexpected output

Hello there this is the first bug report of my life and I am not a native English speaker so, first of all, I would like to apologize for my English skills and the report itself (if it is not precise enough). I have already read this 'guidelines'

[RFC] A Notedb Standard

Hello again, Apologies to those who will receive this for a second time, git@vger.kernel.org rejected the previous mail. This follows from previous discussion[1]. I must firstly apologise for taking such a long time to produce a written spec which I believe I promised over a year ago, but

Re: [PATCH v2 0/7] thread lazy_init_name_hash

On 3/23/2017 1:52 PM, Junio C Hamano wrote: The API document update in 4/7 is a nice addition and it comes at the right spot in the series, just after API enhancement is done. I gave a quick reading on it twice, and all looked reasonable. Nicely done. Thanks. I queued the sparse things

[PATCH v2] travis-ci: build and test Git on Windows

Most Git developers work on Linux and they have no way to know if their changes would break the Git for Windows build. Let's fix that by adding a job to TravisCI that builds and tests Git on Windows. Unfortunately, TravisCI does not support Windows. Therefore, we did the following: * Johannes

Re: [PATCH v2] travis-ci: build and test Git on Windows

On Fri, 24 Mar 2017, Lars Schneider wrote: Most Git developers work on Linux and they have no way to know if their changes would break the Git for Windows build. Let's fix that by adding a job to TravisCI that builds and tests Git on Windows. Unfortunately, TravisCI does not support Windows.

Re: [GSoC][PATCH v4] t2027: avoid using pipes

On 24/03/17 09:27, Prathamesh Chavan wrote: From: Prathamesh Welcome to Git. The name in the "From:" must match the name in the sign-off: git config --global user.name "Prathamesh Chavan" Signed-off-by: Prathamesh Chavan The patch looks good

[GSoC][PATCH v4] t2027: avoid using pipes

Whenever a git command is present in the upstream of a pipe, its failure gets masked by piping and hence it should be avoided for testing the upstream git command. By writing out the output of the git command to a file, we can test the exit codes of both the commands as a failure exit code in any

Re: [PATCH v2] travis-ci: build and test Git on Windows

On Fri, 24 Mar 2017, Lars Schneider wrote: 2. run your own buildbot and submit data using the regular github hook and have buildbot submit the results back (it has a plugin that can do that). We do solaris-builds in the curl project using that method (thanks to opencsw.org) and some

Re: [PATCH v2] travis-ci: build and test Git on Windows

On Fri, Mar 24, 2017 at 1:35 PM, Lars Schneider wrote: >> 1. use appveyor.com, as that is a Travis-like service for Windows. We do our >> windows-builds in the curl project using that. > > The Git for Windows build and tests are *really* resources intensive and they >

[PATCH] read-cache: call verify_hdr() in a background thread

From: Jeff Hostetler This patch contains a performance optimization to run verify_hdr() in a background thread while the foreground thread parses the index. This allows do_read_index() to complete faster. This idea was recently discussed on the mailing list in:

[PATCH] read-cache: call verify_hdr() in a background thread

From: Jeff Hostetler Teash do_read_index() in read-cache.c to call verify_hdr() in a background thread while the forground thread parses the index and builds the_index. This is a performance optimization to reduce the overall time required to get the index into memory.

Re: [git-gui] Amending doesn't preserve timestamp

Hi Igor! Thanks on for thoroughly searching the mailing list and on your suggestions. I hope that someone will come up with a fix that both preserves the author details and date correctly. Regards, Juraj On Thu, Mar 23, 2017 at 11:54 PM, Igor Djordjevic wrote: > Hi

Re: How do I copy a branch & its config to a new name?

On Fri, Mar 24, 2017 at 1:52 AM, Jonathan Nieder wrote: > Hi, > > Ęvar Arnfjörš Bjarmason wrote: > >> I couldn't find any previous list discussion about this, but if not I >> think something like: >> >> git [checkout|branch] --copy src dest >> >> Would make sense as an

Re: [PATCH v2 5/7] name-hash: perf improvement for lazy_init_name_hash

On 3/23/2017 1:45 PM, Stefan Beller wrote: On Thu, Mar 23, 2017 at 8:25 AM, Ramsay Jones wrote: + /* + * Either we have a parent directory and path with slash(es) + * or the directory is an immediate child of the root directory. + */ +

[GSoC] Git CI Improvements 5 microproject

Hello, git team. My name is Nikita Kunevich. I’m student of Belarusian State University of Informatics and Radioelectronics. I’d like to particapate in Google Summer of Code 2017 under git organization. I’m working on “Git CI Improvements 5” microproject which is creating web page for analyzing

[PATCH] mailmap: use Michael J Gruber's new address

Map both old addresses to the new, hopefully more permanent one. Signed-off-by: Michael J Gruber Signed-off-by: Michael J Gruber --- .mailmap | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.mailmap b/.mailmap index

Re: [PATCH] read-cache: call verify_hdr() in a background thread

Jeff Hostetler wrote: > On 3/24/2017 12:35 PM, Jonathan Nieder wrote: >> What happens if there is an error before the code reaches the end of >> the function? I think there needs to be a verify_hdr_finish call in >> the 'unmap:' cleanup section. > > But the "unmap" section calls die(). Do need

[PATCH 5/7] submodule.c: stricter checking for submodules in is_submodule_modified

By having a stricter check in the superproject we catch errors earlier, instead of spawning a child process to tell us. Reviewed-by: Jonathan Nieder Signed-off-by: Stefan Beller --- submodule.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)

[PATCH 7/7] submodule.c: correctly handle nested submodules in is_submodule_modified

When a nested submodule has untracked files, it would be reported as "modified submodule" in the superproject, because submodules are not parsed correctly in is_submodule_modified as they are bucketed into the modified pile as "they are not an untracked file". Signed-off-by: Stefan Beller

[PATCH 3/7] submodule.c: convert is_submodule_modified to use strbuf_getwholeline

Instead of implementing line reading yet again, make use of our beautiful library function to read one line. By using strbuf_getwholeline instead of strbuf_read, we avoid having to allocate memory for the entire child process output at once. That is, we limit maximum memory usage. Once we know

[PATCH 4/7] submodule.c: port is_submodule_modified to use porcelain 2

Migrate 'is_submodule_modified' to the new porcelain format of git-status. This conversion attempts to convert faithfully, i.e. the behavior ought to be exactly the same. As the output in the parsing only distinguishes between untracked files and the rest, this is easy to port to the new format,

[PATCH 6/7] short status: improve reporting for submodule changes

If I add an untracked file to a submodule or modify a tracked file, currently "git status --short" treats the change in the same way as changes to the current HEAD of the submodule: $ git clone --quiet --recurse-submodules https://gerrit.googlesource.com/gerrit $ echo hello

[PATCH v6 0/7] short status: improve reporting for submodule changes

v6: * kill the child once we know all information that we ask for, as an optimization * reordered the patches for that * strbuf_getwholeline instead of its _fd version. v5: * fixed rebase error in the first 2 patches * the last 3 patches introduce behavior change outside the scope of

[PATCH 1/7] submodule.c: use argv_array in is_submodule_modified

struct argv_array is easier to use and maintain Signed-off-by: Stefan Beller --- submodule.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/submodule.c b/submodule.c index 3200b7bb2b..2c667ac95a 100644 --- a/submodule.c +++ b/submodule.c @@

[PATCH 2/7] submodule.c: factor out early loop termination in is_submodule_modified

This makes it easier for a follow up patch. Signed-off-by: Stefan Beller --- submodule.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/submodule.c b/submodule.c index 2c667ac95a..e52cb8a958 100644 --- a/submodule.c +++ b/submodule.c @@

Re: [PATCH v2] log: if --decorate is not given, default to --decorate=auto

Alex Henrie wrote: > Signed-off-by: Alex Henrie > --- > builtin/log.c | 9 - > t/t4202-log.sh | 10 +- > 2 files changed, 17 insertions(+), 2 deletions(-) Nice. Reviewed-by: Jonathan Nieder

[PATCH 1/4] fast-import: use xsnprintf for writing sha1s

When we have to write a sha1 with a newline, we do so by copying both into a single buffer, so that we can issue a single write() call. We use snprintf but don't bother to check the output, since we know it will fit. However, we should use xsnprintf() in such a case so that we're notified if our

[PATCH 2/4] fast-import: use xsnprintf for formatting headers

The stream_blob() function checks the return value of snprintf and dies. This is more simply done with xsnprintf (and matches the similar call in store_object). The message the user would get is less specific, but since the point is that this _shouldn't_ ever happen, that's OK. Signed-off-by:

Re: [PATCH] read-cache: call verify_hdr() in a background thread

On 3/24/2017 12:35 PM, Jonathan Nieder wrote: g...@jeffhostetler.com wrote: From: Jeff Hostetler Teash do_read_index() in read-cache.c to call verify_hdr() ... Nice. Do you have example commands I can run to reproduce that benchmark? (Even better if you can

Re: [PATCH 3/3] t7004, t7030: fix here-doc syntax errors

Jeff King writes: > It seems like t7030 should just skip_all when the GPG prereq is not > met (it's not wrong to mark each test that's added, but it would have > made this particular mistake harder). I'd leave that to be done by others after the dust settles ;-). Here is what

Re: [PATCH 3/3] t7004, t7030: fix here-doc syntax errors

On Fri, Mar 24, 2017 at 11:04:27AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > It seems like t7030 should just skip_all when the GPG prereq is not > > met (it's not wrong to mark each test that's added, but it would have > > made this particular mistake harder). > >

[PATCH v4 03/16] tag doc: reword --[no-]merged to talk about commits, not tips

Change the wording for the --merged and --no-merged options to talk about "commits" instead of "tips". This phrasing was copied from the "branch" documentation in commit 5242860f54 ("tag.c: implement '--merged' and '--no-merged' options", 2015-09-10). Talking about the "tip" is branch

[PATCH v4 01/16] tag doc: move the description of --[no-]merged earlier

Move the documentation for the --merged & --no-merged options earlier in the documentation, to sit along the other switches, and right next to the similar --contains and --points-at switches. It makes more sense to group the options together, not have some options after the like of , , etc.

[PATCH v4 05/16] ref-filter: add test for --contains on a non-commit

Change the tag test suite to test for --contains on a tree & blob. It only accepts commits and will spew out " is a tree, not a commit". It's sufficient to test this just for the "tag" and "branch" commands, because it covers all the machinery shared between "branch" and "for-each-ref".

[PATCH v4 04/16] ref-filter: make combining --merged & --no-merged an error

Change the behavior of specifying --merged & --no-merged to be an error, instead of silently picking the option that was provided last. Subsequent changes of mine add a --no-contains option in addition to the existing --contains. Providing both of those isn't an error, and has actual meaning.

[PATCH v4 09/16] tag: add more incompatibles mode tests

Amend the test suite to test for more invalid uses like "-l -a" etc. This change tests the code path in builtin/tag.c between lines: if (argc == 0 && !cmdmode) And: if ((create_tag_object || force) && (cmdmode != 0)) Signed-off-by: Ævar Arnfjörð Bjarmason ---

[PATCH v4 08/16] for-each-ref: partly change to in help

Change mentions of to in the help output of for-each-ref as appropriate. Both --[no-]merged and --contains only take commits, but --points-at can take any object, such as a tag pointing to a tree or blob. Signed-off-by: Ævar Arnfjörð Bjarmason --- builtin/for-each-ref.c | 4

[PATCH v4 06/16] tag: remove a TODO item from the test suite

Change the test for "git tag -l" to not have an associated TODO comment saying that it should return non-zero if there's no tags. This was added in commit ef5a6fb597 ("Add test-script for git-tag", 2007-06-28) when the tests for "tag" were initially added, but at this point changing this would be

[PATCH v4 10/16] parse-options: add OPT_NONEG to the "contains" option

Add the OPT_NONEG flag to the "contains" option and its hidden synonym "with". Since this was added in commit 694a577519 ("git-branch --contains=commit", 2007-11-07) giving --no-{contains,with} hasn't been an error, but has emitted the help output since filter.with_commit wouldn't get set. Now

[PATCH v4 12/16] tag: implicitly supply --list given another list-like option

Change the "tag" command to implicitly turn on its --list mode when provided with a list-like option such as --contains, --points-at etc. This is for consistency with how "branch" works. When "branch" is given a list-like option, such as --contains, it implicitly provides --list. Before this

[PATCH v4 11/16] tag: change misleading --list documentation

Change the documentation for --list so that it's described as a toggle, not as an option that takes a as an argument. Junio initially documented this in b867c7c23a ("git-tag: -l to list tags (usability).", 2006-02-17), but later Jeff King changed "tag" to accept multiple patterns in 588d0e834b

[PATCH v4 02/16] tag doc: split up the --[no-]merged documentation

Split up the --[no-]merged documentation into documentation that documents each option independently. This is in line with how "branch" and "for-each-ref" are documented, and makes subsequent changes to discuss the limits & caveats of each option easier to read. Signed-off-by: Ævar Arnfjörð

[PATCH v4 00/16] Various changes to the "tag" command & related

Hopefully the final version. This is exactly like v3 except for a couple of minor changes (and rebased on the latest upstream master): Ævar Arnfjörð Bjarmason (16): tag doc: move the description of --[no-]merged earlier tag doc: split up the --[no-]merged documentation tag doc: reword

Re: [PATCH v2 0/7] thread lazy_init_name_hash

On Fri, Mar 24, 2017 at 5:39 AM, Jeff Hostetler wrote: > WRT the assert() in name-hash.c, Stefan suggested converting it > to an if-!-die form in an earlier message in this thread. I'm OK > with that or with removing the assert completely. I think removing them

[PATCH v4 07/16] tag tests: fix a typo in a test description

Change "suceed" to "succeed" in a test description. The typo has been here since the code was originally added in commit ef5a6fb597 ("Add test-script for git-tag", 2007-06-28). Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t7004-tag.sh | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v4 14/16] ref-filter: add --no-contains option to tag/branch/for-each-ref

Change the tag, branch & for-each-ref commands to have a --no-contains option in addition to their longstanding --contains options. This allows for finding the last-good rollout tag given a known-bad . Given a hypothetically bad commit cf5c7253e0, the git version to revert to can be found with

[PATCH v4 16/16] tag: add tests for --with and --without

Change the test suite to test for these synonyms for --contains and --no-contains, respectively. Before this change there were no tests for them at all. This doesn't exhaustively test for them as well as their --contains and --no-contains synonyms, but at least it's something. Signed-off-by:

[PATCH v4 13/16] tag: change --point-at to default to HEAD

Change the --points-at option to default to HEAD for consistency with its siblings --contains, --merged etc. which default to HEAD. Previously we'd get: $ git tag --points-at 2>&1 | head -n 1 error: option `points-at' requires a value This changes behavior added in commit ae7706b9ac

[PATCH v4 15/16] ref-filter: reflow recently changed branch/tag/for-each-ref docs

Reflow the recently changed branch/tag-for-each-ref documentation. This change shows no changes under --word-diff, except the innocuous change of moving git-tag.txt's "[--sort=]" around slightly. Signed-off-by: Ævar Arnfjörð Bjarmason --- Documentation/git-branch.txt | 15

Re: [PATCH 3/3] t7004, t7030: fix here-doc syntax errors

Jeff King writes: > On Thu, Mar 23, 2017 at 03:00:08PM -0700, Junio C Hamano wrote: > >> Santiago Torres writes: >> >> > This sounds like a helpful addition to implement. We could update/add >> > tests for compliance on this once the feature is addded and fix

Re: [PATCH] [GSoC] remove_subtree(): reimplement using iterators

Welcome to the Git community! On Thu, Mar 23, 2017 at 9:07 PM, Daniel Ferreira wrote: > Uses dir_iterator to traverse through remove_subtree()'s directory tree, > avoiding the need for recursive calls to readdir() and simplifying code. Please use a more imperative style. (e.g.

[PATCH 3/4] encode_in_pack_object_header: respect output buffer length

The encode_in_pack_object_header() writes a variable-length header to an output buffer, but it doesn't actually know long the buffer is. At first glance, this looks like it might be possible to overflow. In practice, this is probably impossible. The smallest buffer we use is 10 bytes, which would

[PATCH 4/4] pack.h: define largest possible encoded object size

Several callers use fixed buffers for storing the pack object header, and they've picked 10 as a magic number. This is reasonable, since it handles objects up to 2^67. But let's give them a constant so it's clear that the number isn't pulled out of thin air. Signed-off-by: Jeff King

[PATCH] name-hash: add test-lazy-init-name-hash to .gitignore

Signed-off-by: Ramsay Jones --- Hi Jeff, If you need to re-roll your 'jh/memihash-opt' branch, could you please squash this into the relevant patch (commit f25dde4fbf, "name-hash: add test-lazy-init-name-hash", 23-03-2017). Thanks! ATB, Ramsay Jones

LETS WORK TOGETHER AND ACHIEVED THIS FUND.

Dear Friend, I need your help transferring (US$4.5M DOLLARS) to your bank account.I have every enquiries’details to make the bank believed you and release the fund in within 5 banking working days with your full co-operation with me for success. Send the below requirement to enable me advice

RE: [PATCH v2 1/4] t7800: remove whitespace before redirect

Please disregard. I apologize - somehow my format-patch/send-email went awry. Thanks, Ben > -Original Message- > From: Ben Peart [mailto:peart...@gmail.com] > Sent: Friday, March 24, 2017 11:27 AM > To: git@vger.kernel.org > Cc: Ben Peart ;

Re: [PATCH] read-cache: call verify_hdr() in a background thread

g...@jeffhostetler.com wrote: > From: Jeff Hostetler > > Teash do_read_index() in read-cache.c to call verify_hdr() s/Teash/Teach/ > in a background thread while the forground thread parses s/forground/foreground/ > the index and builds the_index. > > This is a

Re: [PATCH 3/3] t7004, t7030: fix here-doc syntax errors

On Fri, Mar 24, 2017 at 09:45:30AM -0700, Junio C Hamano wrote: > I actually think this uncovers another class of breakage. t7030 > tests should be protected with GPG prereq and 'fourth-signed' that > is made only with the prereq in the first test will not be found. It seems like t7030 should

Re: [GSoC] Git CI Improvements 5 microproject

> On 24 Mar 2017, at 14:58, Nikita Kunevich wrote: > > Hello, git team. My name is Nikita Kunevich. I’m student of Belarusian State > University of Informatics and Radioelectronics. I’d like to particapate in > Google Summer of Code 2017 under git organization. > I’m

[PATCH] push: allow atomic flag via configuration

Added a "push.atomic" option to git-config to allow site-specific configuration of the atomic flag of git push Signed-off-by: Romuald Brunet --- Documentation/config.txt | 5 + builtin/push.c | 6 ++

Re: [PATCH] name-hash: add test-lazy-init-name-hash to .gitignore

On 24/03/17 17:26, Ramsay Jones wrote: > > Signed-off-by: Ramsay Jones > --- > > Hi Jeff, > > If you need to re-roll your 'jh/memihash-opt' branch, could you please > squash this into the relevant patch (commit f25dde4fbf, "name-hash: add >

Re: [PATCH v3 2/2] l10n: Add git-add.txt to localized man pages

Ævar Arnfjörð Bjarmason writes: > On Mon, Mar 20, 2017 at 11:05 PM, Junio C Hamano wrote: >> But more importantly, aren't we essentially adding an equivalent of >> >> cd Documentation && cat git-*.txt >> >> to our codebase? >> >> Surely we cannot

Re: [PATCH 3/3] t7004, t7030: fix here-doc syntax errors

On Fri, Mar 24, 2017 at 12:49:43PM -0400, Jeff King wrote: > On Fri, Mar 24, 2017 at 09:45:30AM -0700, Junio C Hamano wrote: > > > I actually think this uncovers another class of breakage. t7030 > > tests should be protected with GPG prereq and 'fourth-signed' that > > is made only with the

Re: [PATCH] push: allow atomic flag via configuration

On Fri, Mar 24, 2017 at 06:17:54PM +0100, Romuald Brunet wrote: > Added a "push.atomic" option to git-config to allow site-specific > configuration of the atomic flag of git push I don't really use --atomic myself, but this seems like a reasonable thing to want, and the implementation looks

Re: [PATCH v1 2/3] sub-process: refactor the filter process code into a reusable module

Ben Peart writes: > How about I squash the last two patches together so that its more > apparent that it's just a refactoring of existing code with the before > and after in a single patch? I do not think making a pair of patches, each already does too much, into one

Re: [PATCH v2] travis-ci: build and test Git on Windows

Lars Schneider writes: > I think I addressed all issues from the v1 review (see interdiff below) > with one exception. The script still uses bash instead of sh. Something > about this does not work in sh: > --output >(sed "$(printf '1s/^\xef\xbb\xbf//')" >cat >&3) >

Re: [PATCH v1 2/3] sub-process: refactor the filter process code into a reusable module

Junio C Hamano writes: > ... > And for something of sub-process.[ch]'s size, I suspect that it > would have more than 1 such logical unit to be independently > refactored, so in total, I would suspect the series would become > > 1 (boring mechanical part) + > 2 or more

[PATCH 0/4] a few minor buffer cleanups in fast-import

I don't think any of these is a triggerable bug. They're just cleanups to make it more obvious that the code is doing the right thing (and making it harder to do the wrong thing). [1/4]: fast-import: use xsnprintf for writing sha1s [2/4]: fast-import: use xsnprintf for formatting headers

Re: [PATCH v2] log: if --decorate is not given, default to --decorate=auto

Alex Henrie writes: > +test_expect_success TTY 'log output on a TTY' ' > + git log --oneline --decorate >expect.short && > + > + test_terminal git log --oneline >actual && > + test_cmp expect.short actual > +' > + Nice. I didn't know test_terminal was so

Re: [PATCH v2 0/7] thread lazy_init_name_hash

Jeff Hostetler writes: > WRT the assert() in name-hash.c, Stefan suggested converting it > to an if-!-die form in an earlier message in this thread. I'm OK > with that or with removing the assert completely. I actually am OK with leaving things as they are ;-)

[PATCH] pager_in_use: use git_env_bool()

On Fri, Mar 24, 2017 at 02:55:43PM -0400, Jeff King wrote: > But I was concerned that there might be a bug in pager_in_use(), so I > dug into it a little. I think the code there is correct; [...] I did see this small cleanup opportunity, though. -- >8 -- Subject: [PATCH] pager_in_use: use

What's cooking in git.git (Mar 2017, #10; Fri, 24)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. The second maintenance release

[PATCH v4 2/2] diff --no-index: support reading from pipes

diff <(command1) <(command2) provides useful output, let's make it possible for git to do the same. Signed-off-by: Dennis Kaarsemaker --- diff-no-index.c | 9 + diff.c | 18 -- t/t4053-diff-no-index.sh | 10 ++

[PATCH v4 0/2] diff --no-index: support symlinks and pipes

git diff <(command1) <(command2) is less useful than it could be, all it outputs is: diff --git a/dev/fd/63 b/dev/fd/62 index 9e6542b297..9f7b2c291b 12 --- a/dev/fd/63 +++ b/dev/fd/62 @@ -1 +1 @@ -pipe:[464811685] \ No newline at end of file +pipe:[464811687] \ No newline at end of file

[PATCH v4 1/2] diff --no-index: optionally follow symlinks

Git's diff machinery does not follow symlinks, which makes sense as git itself also does not, but stores the symlink destination. In --no-index mode however, it is useful for diff to be able to follow symlinks, matching the behaviour of ordinary diff. A new --dereference (name copied from diff)

Re: [PATCH] push: allow atomic flag via configuration

On Fri, Mar 24, 2017 at 11:53:54AM -0700, Jonathan Nieder wrote: > I didn't receive the original patch (maybe mailing delay?) so > commenting here. Vger seems a bit slow lately. The list copy did eventually get delivered to me and public-inbox:

Re: [PATCHv2 08/14] completion: let 'for-each-ref' and 'ls-remote' filter matching refs

On Thu, Mar 23, 2017 at 04:29:18PM +0100, SZEDER Gábor wrote: > When completing refs, several __git_refs() code paths list all the > refs from the refs/{heads,tags,remotes}/ hierarchy and then > __gitcomp_nl() iterates over those refs in a shell loop to filter out > refs not matching the current

Re: [PATCHv2 00/14] completion: speed up refs completion

On Thu, Mar 23, 2017 at 11:28:52AM -0700, Junio C Hamano wrote: > SZEDER Gábor writes: > > > This series is the updated version of 'sg/completion-refs-speedup'. > > It speeds up refs completion for large number of refs, partly by > > giving up disambiguating ambiguous refs

A note from the maintainer

Welcome to the Git development community. This message is written by the maintainer and talks about how Git project is managed, and how you can work with it. * Mailing list and the community The development is primarily done on the Git mailing list. Help requests, feature proposals, bug reports

Re: [PATCH] push: allow atomic flag via configuration

Jeff King writes: > My one question would be whether people would want this to actually be > specific to a particular remote, and not just on for a given repository > (your "site-specific" in the description made me think of that). In that > case it would be better as part of the

Re: [PATCHv2 07/14] completion: don't disambiguate short refs

On Thu, Mar 23, 2017 at 04:29:17PM +0100, SZEDER Gábor wrote: > However, it's questionable whether ambiguous refs are really that bad > to justify that much extra cost: It's not clear to me that the existing completion actually does a good job with disambiguation anyway. If I have a tag and a

[ANNOUNCE] Git v2.12.2

The latest maintenance release Git v2.12.2 is now available at the usual places. These fixes have all been in the 'master' branch to be included in the next feature release. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a

Re: [PATCH] log: if --decorate is not given, default to --decorate=auto

Jeff King writes: > I see you ended up with a test that uses test_terminal, which is much > better (and your patch looks good to me). > > But I was concerned that there might be a bug in pager_in_use(), so I > dug into it a little. I think the code there is correct; it's just >

Re: How do I copy a branch & its config to a new name?

On Fri, Mar 24, 2017 at 12:10:49PM +0100, Ævar Arnfjörð Bjarmason wrote: > Actually this is a bit confusing, but I think reversing the arguments > makes sense, i.e.: > > git branch -c dest [src] > > And similarly: > > git checkout -c dest [] > > This is confusing in that it reverses

[PATCH v2] send-email: Net::SMTP::SSL is obsolete, use only when necessary

Net::SMTP itself can do the necessary SSL and STARTTLS bits just fine since version 1.28, and Net::SMTP::SSL is now deprecated. Since 1.28 isn't that old yet, keep the old code in place and use it when necessary. While we're in the area, mark some messages for translation that were not yet marked

Re: [PATCH] push: allow atomic flag via configuration

Hi, Jeff King wrote: > On Fri, Mar 24, 2017 at 06:17:54PM +0100, Romuald Brunet wrote: >> Added a "push.atomic" option to git-config to allow site-specific >> configuration of the atomic flag of git push > > I don't really use --atomic myself, but this seems like a reasonable > thing to want,

Re: [PATCHv2 11/14] completion: let 'for-each-ref' sort remote branches for 'checkout' DWIMery

On Thu, Mar 23, 2017 at 04:29:21PM +0100, SZEDER Gábor wrote: > diff --git a/contrib/completion/git-completion.bash > b/contrib/completion/git-completion.bash > index 394dcece6..d26312899 100644 > --- a/contrib/completion/git-completion.bash > +++ b/contrib/completion/git-completion.bash > @@

Re: [PATCH] log: if --decorate is not given, default to --decorate=auto

On Thu, Mar 23, 2017 at 10:52:34AM -0600, Alex Henrie wrote: > Unfortunately, I think I found a bug. Even when using `git -p`, the > function pager_in_use() always returns false if the output is not a > TTY. So, `isatty(1) || pager_in_use()` and `color_stdout_is_tty || > (pager_in_use() &&

Re: Re: Re: GSoC Project | Convert interactive rebase to C

Johannes Schindelin wrote: > On Tue, 21 Mar 2017, Ivan Tham wrote: > > Stefan Beller wrote: > > > On Mon, Mar 20, 2017 at 9:41 AM, Ivan Tham wrote: > > > > I am Ivan Tham. Currently studying in Computer Science in APIIT > > >

Re: [PATCH v2 1/2] pkt-line: add packet_writel() and packet_read_line_gently()

On 2017-03-24 16:27, Ben Peart wrote: > Add packet_writel() which writes multiple lines in a single call and > then calls packet_flush_gently(). Add packet_read_line_gently() to > enable reading a line without dying on EOF. > > Signed-off-by: Ben Peart > --- > pkt-line.c

Re: [PATCH v7 0/7] short status: improve reporting for submodule changes

Stefan Beller wrote: > v7: > * taken all of Jonathan minor nits, so patch 1..6 should be good to go > * patch 7 lacks tests and documentation (according to Jonathan...) > but as it is the last patch, just fixing a minor detail we can leave it off. > > Junio, please take patch 1-6 as usual, I

[PATCH] sha1dc: safeguard against outside definitions of BIGENDIAN

In sha1dc/sha1.c, we #define BIGENDIAN under certain circumstances, and obviously leave the door open for scenarios where our conditions do not catch and that constant is #defined elsewhere. However, we did not expect that anybody would possibly #define BIGENDIAN to 0, indicating that the current

Re: [PATCH 6/7] short status: improve reporting for submodule changes

Stefan Beller wrote: > +++ b/wt-status.c > @@ -431,10 +431,19 @@ static void wt_status_collect_changed_cb(struct > diff_queue_struct *q, > } > if (!d->worktree_status) > d->worktree_status = p->status; > - d->dirty_submodule =

Re: [PATCH 3/7] submodule.c: convert is_submodule_modified to use strbuf_getwholeline

On Fri, Mar 24, 2017 at 3:38 PM, Jonathan Nieder wrote: > It also overlaps work a little better. mentioned >> Once we know all information that we care about, we can terminate >> the child early. In that case we do not care about its exit code as well. > > Should this say

  1   2   >