Bug: 'git config --local user.email=' fails silently?

Hi, >From the documentation I would have expected  git config --local user.email=alt.email@alt.domain to create a section  [user] email=alt.email@alt.domain in the local .git/config. Instead it returns status 1 with no error message. Is this intentional? If I add the [user] section

Re: [PATCH v6 4/5] dir_iterator: refactor state machine model

On 04/02/2017 06:46 AM, Daniel Ferreira (theiostream) wrote: > Gah, I just realized I failed to correct refs/files-backend.c's > behavior and kept 0 instead of DIR_ITERATOR_PRE_ORDER_TRAVERSAL as its > flag. I'll correct this on a v7, but I'll wait for the rest of your > reviews before sending

Re: [PATCH v6 4/5] dir_iterator: refactor state machine model

Gah, I just realized I failed to correct refs/files-backend.c's behavior and kept 0 instead of DIR_ITERATOR_PRE_ORDER_TRAVERSAL as its flag. I'll correct this on a v7, but I'll wait for the rest of your reviews before sending that revision. On Sun, Apr 2, 2017 at 1:35 AM, Daniel Ferreira

[PATCH v6 5/5] remove_subtree(): reimplement using iterators

Use dir_iterator to traverse through remove_subtree()'s directory tree, avoiding the need for recursive calls to readdir(). Simplify remove_subtree()'s code. A conversion similar in purpose was previously done at 46d092a ("for_each_reflog(): reimplement using iterators", 2016-05-21).

[PATCH v6 3/5] dir_iterator: add helpers to dir_iterator_advance

Create inline helpers to dir_iterator_advance(). Make dir_iterator_advance()'s code more legible and allow some behavior to be reusable. Signed-off-by: Daniel Ferreira --- dir-iterator.c | 65 +- 1 file changed, 42

[PATCH v6 4/5] dir_iterator: refactor state machine model

Perform major refactor of dir_iterator_advance(). dir_iterator has ceased to rely on a convoluted state machine mechanism of two loops and two state variables (level.initialized and level.dir_state). This serves to ease comprehension of the iterator mechanism and ease addition of new features to

[PATCH v6 2/5] remove_subtree(): test removing nested directories

Test removing a nested directory when an attempt is made to restore the index to a state where it does not exist. A similar test could be found previously in t/t2000-checkout-cache-clash.sh, but it did not check for nested directories, which could allow a faulty implementation of remove_subtree()

[PATCH v6 1/5] dir_iterator: add tests for dir_iterator API

Create t/helper/test-dir-iterator.c, which prints relevant information about a directory tree iterated over with dir_iterator. Create t/t0065-dir-iterator.sh, which tests that dir_iterator does iterate through a whole directory tree. Signed-off-by: Daniel Ferreira ---

[PATCH v6 0/5] [GSoC] remove_subtree(): reimplement using iterators

This is the sixth version of a patch series that implements the GSoC microproject of converting a recursive call to readdir() to use dir_iterator. v1: https://public-inbox.org/git/CAGZ79kZwT-9mHTiOJ5CEjk2wDFkn6+NcogjX0=vjhsah16a...@mail.gmail.com/T/#t v2:

Re: [BUG?] iconv used as textconv, and spurious ^M on added lines on Windows

On 2017-03-31 21:44, Jakub Narębski wrote: > W dniu 31.03.2017 o 14:38, Torsten Bögershausen pisze: >> On 30.03.17 21:35, Jakub Narębski wrote: >>> Hello, >>> >>> Recently I had to work on a project which uses legacy 8-bit encoding >>> (namely cp1250 encoding) instead of utf-8 for text files

Re: [PATCH v4 2/5] dir_iterator: iterate over dir after its contents

Why exactly would it not be applicable to read_directory_recursively()? On Thu, Mar 30, 2017 at 8:08 AM, Duy Nguyen wrote: > On Thu, Mar 30, 2017 at 1:39 PM, Michael Haggerty > wrote: >> * DIR_ITERATOR_RECURSE -- recurse into subdirectories >> >> would

Re: Bug in "git am" when the body starts with spaces

On Sat, Apr 01, 2017 at 12:03:44PM -0700, Linus Torvalds wrote: > On Fri, Mar 31, 2017 at 5:52 PM, Linus Torvalds > wrote: > > > > The continuation logic is oddly complex, and I can't follow the logic. > > But it is completely broken in how it thinks empty lines

Re: Very promising results with libpcre2

Ævar Arnfjörð Bjarmason writes: > I am very tempted though to support them in parallel, if only for ease > of performance testing and to be able to roll out support for > grep.patternType=perl meaning pcre1 for now, but add a > grep.patternType=pcre2 for testing (and make

Re: Very promising results with libpcre2

Jeffrey Walton writes: >> Just to make sure that we are on the same page. While I do not see >> the need to link with both variants and allow users to choose >> between them at runtime, I do not know if the whole world is ready >> to drop pcre1 and use pcre2 (the latter of

Re: [PATCH v2 00/20] Separate `ref_cache` into a separate module

Ramsay Jones writes: >> I am getting the impression that the files-backend thing as well as >> this topic are ready for 'next'. Please stop me if I missed something >> in these topics (especially the other one) that needs updating >> before that happens. > > Hmm,

Re: [PATCH 2/2] [GSOC] show_bisect_vars(): Use unsigned int instead of signed int for flags

Robert Stanca writes: > I am used to 1change per patch so it's easier to redo specific > patches...if there are small changes(10 lines max) can i send them as > 1 patch? It's not number of lines. One line per patch does not make sense if you need to make

Re: Very promising results with libpcre2

> Just to make sure that we are on the same page. While I do not see > the need to link with both variants and allow users to choose > between them at runtime, I do not know if the whole world is ready > to drop pcre1 and use pcre2 (the latter of which has only been > around for a bit over two

Re: [PATCH v2 00/20] Separate `ref_cache` into a separate module

On 31/03/17 17:01, Junio C Hamano wrote: > Michael Haggerty writes: > >> This version literally only contains a few commit message changes and >> one minor comment changes relative to v1. The code is identical. I >> wasn't sure whether it is even worth sending this patch

Re: [RFC PATCH] git-news: obtain latest news for your favorite VCS

On Sat, Apr 1, 2017 at 1:59 AM, Stefan Beller wrote: [...] > diff --git a/git-news.sh b/git-news.sh > new file mode 100755 > index 00..1707dc633e > --- /dev/null > +++ b/git-news.sh > @@ -0,0 +1,4 @@ > +#!/bin/sh > +# > + > +/usr/bin/sensible-browser

Re: [PATCH 1/2] [GSOC] Convert signed flags to unsigned

Regarding the first part , i can resend those 2 patches rewriting the commit message if you want. On Sat, Apr 1, 2017 at 10:12 PM, Junio C Hamano wrote: > Robert Stanca writes: > >> Subject: Re: [PATCH 1/2] [GSOC] Convert signed flags to unsigned > >

Re: [PATCH] Documentation: make 3-way merge warning more generic

"brian m. carlson" writes: > With the strategies that use 3-way merge (including the default, > 'recursive'), > -if a change is made on both branches, but later reverted on one of the > -branches, that change will be present in the merged result; some people find

Re: [PATCH 2/2] [GSOC] show_bisect_vars(): Use unsigned int instead of signed int for flags

I am used to 1change per patch so it's easier to redo specific patches...if there are small changes(10 lines max) can i send them as 1 patch? On Sat, Apr 1, 2017 at 10:13 PM, Junio C Hamano wrote: > Robert Stanca writes: > >> As rev_list_info's

Re: [PATCH 2/2] [GSOC] show_bisect_vars(): Use unsigned int instead of signed int for flags

Robert Stanca writes: > As rev_list_info's flag is unsigned int , var flags should have proper > type.Also var cnt could be unsigned as there's no negative number of commits > (all-reaches) > > Signed-off-by: Robert Stanca > --- OK. I

Re: [PATCH 1/2] [GSOC] Convert signed flags to unsigned

Robert Stanca writes: > Subject: Re: [PATCH 1/2] [GSOC] Convert signed flags to unsigned Try git shortlog --no-merges -40 to learn how commits are typically titled. And then imagine this patch makes into our codebase and appear in the output. Can you tell what

Re: Very promising results with libpcre2

On Sat, Apr 1, 2017 at 8:24 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> On Sat, Apr 1, 2017 at 12:48 AM, Junio C Hamano wrote: >>> Ævar Arnfjörð Bjarmason writes: >>> That enables the new JIT

Re: Bug in "git am" when the body starts with spaces

On Fri, Mar 31, 2017 at 5:52 PM, Linus Torvalds wrote: > > The continuation logic is oddly complex, and I can't follow the logic. > But it is completely broken in how it thinks empty lines are somehow > "continuations". The attached patch seems to work for me.

Re: [PATCH] git-bisect.txt: add missing word

Quentin Pradet writes: > Signed-off-by: Quentin Pradet > --- > Documentation/git-bisect.txt | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) The updated text is more grammatically correct. It would have been better if you

Re: [PATCH] [GSOC] prune_worktrees(): reimplement with dir_iterator

Robert Stanca writes: > On Sat, Apr 1, 2017 at 5:29 AM, Junio C Hamano wrote: >> >> Using dir_iterator() to make it recursive is not just overkill but >> is a positively wrong change, isn't it? > > Thanks for the review, and yes the commit message is

Re: [BUG?] iconv used as textconv, and spurious ^M on added lines on Windows

W dniu 01.04.2017 o 08:08, Jeff King pisze: > On Fri, Mar 31, 2017 at 03:24:48PM +0200, Jakub Narębski wrote: > >>> I suspect in the normal case that git is doing line-ending conversion, >>> but it's suppressed when textconv is in use. >> >> I would not consider this a bug if not for the fact

Assalamu`Alaikum.

Dear Sir/Madam. Assalamu`Alaikum. I am Dr mohammad ouattara, I have ($10.6 Million us dollars) to transfer into your account, I will send you more details about this deal and the procedures to follow when I receive a positive response from you, Have a great day, Dr mohammad ouattara.

Re: Very promising results with libpcre2

Ævar Arnfjörð Bjarmason writes: > On Sat, Apr 1, 2017 at 12:48 AM, Junio C Hamano wrote: >> Ævar Arnfjörð Bjarmason writes: >> >>> That enables the new JIT support in pcre v2: >>> >>> s/iterrx fixed prx >>> rx 2.19--

Re: [PATCH v2] Documentation: improve git ls-files -s manpage entry

Thanks.

Re: [PATCH] name-hash: fix buffer overrun

Johannes Schindelin writes: > On Fri, 31 Mar 2017, Junio C Hamano wrote: > >> Junio C Hamano writes: >> >> > Ah, of course. Avoid GNUism to spell HT as "\t" in a sed script. > > Sorry about that, I suggested this snippet to Kevin, it is my fault

Re: [PATCH v3] http.postbuffer: allow full range of ssize_t values

Jeff King writes: > On Fri, Mar 31, 2017 at 01:26:31PM -0400, David Turner wrote: > >> Unfortunately, in order to push some large repos, the http postbuffer >> must sometimes exceed two gigabytes. On a 64-bit system, this is OK: >> we just malloc a larger buffer. > > I'm still

Re: [PATCH 2/2] index-pack: detect local corruption in collision check

Jeff King writes: > is not a collision but rather local corruption. We should > reoprt that instead (just like we do if reading the rest of > the object content fails a few lines later). s/reoprt/report/ (locally amended while queuing). > We may want to tighten that up. In the

Re: [PATCH 1/2] sha1_loose_object_info: return error for corrupted objects

Jeff King writes: > When sha1_loose_object_info() finds that a loose object file > cannot be stat(2)ed or mmap(2)ed, it returns -1 to signal an > error to the caller. However, if it found that the loose > object file is corrupt and the object data cannot be used > from it, it

Re: [RFC PATCH 0/5] Localise error headers

Jeff King writes: > On Thu, Mar 30, 2017 at 05:18:59PM +0200, Michael J Gruber wrote: > >> I read back the whole thread, and I'm still not sure if there's >> consensus and how to go forward. Should we let the topic die? I don't >> care too much personally, I just thought the mixed

Re: [PATCH v5 4/6] dir_iterator: add tests for dir_iterator API

Jeff King writes: > I think we actually prefer just: > > >dir/b > > in our tests. The advantages over touch are: > > 1. It is clear that the output will be empty afterwards (whereas with > touch, it might just update the timestamp on an existing file). > > 2. It's

[RFC] [GSoC] Proposal Draft for GSoC 2017 : Incremental Rewrite of git-submodules

Hello everyone, This is the first draft of my project proposal. I decided to change my project since the project I initially intended to do and also proposed was slightly a smaller project for 13 weeks. Also when I came across this project, and also found out that there are left over bits (git

[PATCH 1/2] [GSOC] Convert signed flags to unsigned

Unsigned int is a closer representation of bitflags rather than signed int that uses 1 special bit for sign.This shouldn't make much difference because rev_list_info.flags uses only 2 bits(BISECT_SHOW_ALL and REV_LIST_QUIET) Signed-off-by: Robert Stanca --- bisect.h

[PATCH 2/2] [GSOC] show_bisect_vars(): Use unsigned int instead of signed int for flags

As rev_list_info's flag is unsigned int , var flags should have proper type.Also var cnt could be unsigned as there's no negative number of commits (all-reaches) Signed-off-by: Robert Stanca --- builtin/rev-list.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH] status: show in-progress info for short status

On Fri, Mar 31, 2017 at 03:59:17PM +0200, Michael J Gruber wrote: > Ordinary (long) status shows information about bisect, revert, am, > rebase, cherry-pick in progress, and so does git-prompt.sh. status > --short currently shows none of this information. > > Introduce an `--inprogress` argument

[PATCH] Documentation: make 3-way merge warning more generic

The documentation for merge strategies noted that if a change was reverted on only one branch of a merge, the resultant merge would contain the change. However, similar surprising behavior can occur where cherry-picking only one commit from a series to the other branch can cause conflicts.

Re: [PATCH] [GSOC] prune_worktrees(): reimplement with dir_iterator

On Sat, Apr 1, 2017 at 5:29 AM, Junio C Hamano wrote: > > Robert Stanca writes: > > > Replaces recursive traversing of opendir with dir_iterator > > The original code for this one, and also the other one, is not > recursive traversing. This one

Re: [PATCH] name-hash: fix buffer overrun

Hi Junio, On Fri, 31 Mar 2017, Junio C Hamano wrote: > Junio C Hamano writes: > > > Ah, of course. Avoid GNUism to spell HT as "\t" in a sed script. Sorry about that, I suggested this snippet to Kevin, it is my fault for not remembering BSD sed's idiosynchracies. Ciao,

Re: [PATCH v5 4/6] dir_iterator: add tests for dir_iterator API

On Thu, Mar 30, 2017 at 03:25:43PM -0300, Daniel Ferreira (theiostream) wrote: > On Thu, Mar 30, 2017 at 4:46 AM, Michael Haggerty > wrote: > > Is there a special reason to write the date to the file as opposed to, say > > > > touch dir/b > > > > ? (Some people use `:

Re: Very promising results with libpcre2

On Sat, Apr 1, 2017 at 12:48 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> That enables the new JIT support in pcre v2: >> >> s/iterrx fixed prx >> rx 2.19-- -33% -44% >> fixed 1.47 49%-- -17% >> prx 1.22

Re: [PATCH 3/3] completion: offer ctags symbol names for 'git log -S', '-G' and '-L:'

On Thu, Mar 30, 2017 at 12:06:56PM +0200, SZEDER Gábor wrote: > > 1. You still have to come up with the filename yourself for "-L". > > I was already quite satisfied that both the symbol name and the > filename can be TAB completed... but right, in most cases the > function name uniquely

Re: [PATCH] read-cache: avoid git_path() race in freshen_shared_index()

On Thu, Mar 30, 2017 at 04:24:40PM +0700, Duy Nguyen wrote: > On Thu, Mar 30, 2017 at 12:56 AM, Jeff King wrote: > > But in the end it doesn't really matter. I think code like: > > > > const char *filename = git_path(...); > > > > or > > > > nontrivial_function(git_path(...));

Re: [RFC PATCH 0/5] Localise error headers

On Thu, Mar 30, 2017 at 05:18:59PM +0200, Michael J Gruber wrote: > Jeff King venit, vidit, dixit 21.01.2017 15:20: > > On Wed, Jan 11, 2017 at 10:08:46AM -0800, Junio C Hamano wrote: > > > >> Jeff King writes: > >> > >>> Yes, I would think die_errno() is a no-brainer for

[PATCH 2/2] index-pack: detect local corruption in collision check

When we notice that we have a local copy of an incoming object, we compare the two objects to make sure we haven't found a collision. Before we get to the actual object bytes, though, we compare the type and size from sha1_object_info(). If our local object is corrupted, then the type will be

[PATCH 1/2] sha1_loose_object_info: return error for corrupted objects

When sha1_loose_object_info() finds that a loose object file cannot be stat(2)ed or mmap(2)ed, it returns -1 to signal an error to the caller. However, if it found that the loose object file is corrupt and the object data cannot be used from it, it stuffs OBJ_BAD into "type" field of the

Re: SHA1 collision in production repo?! (probably not)

On Fri, Mar 31, 2017 at 02:16:29PM -0700, Junio C Hamano wrote: > Before we forget... > > -- >8 -- > From: Jeff King > > When sha1_loose_object_info() finds that a loose object file cannot > be stat(2)ed or mmap(2)ed, it returns -1 to signal an error to the > caller. However,

[PATCH v2] Documentation: improve git ls-files -s manpage entry

List the fields in order of appearance in the command output. Signed-off-by: Mostyn Bramley-Moore --- Documentation/git-ls-files.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt index

[PATCH] git-bisect.txt: add missing word

Signed-off-by: Quentin Pradet --- Documentation/git-bisect.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index bdd915a66..90148bb07 100644 --- a/Documentation/git-bisect.txt +++

Re: [PATCH v2 00/20] Separate `ref_cache` into a separate module

On Fri, Mar 31, 2017 at 04:10:58PM +0200, Michael Haggerty wrote: > * I added a long blurb about the removal of an internal consistency > check in the commit message for > > [18/20] commit_packed_refs(): use reference iteration Thanks, the explanation there makes sense. I think this

Re: [BUG?] iconv used as textconv, and spurious ^M on added lines on Windows

On Fri, Mar 31, 2017 at 03:24:48PM +0200, Jakub Narębski wrote: > > I suspect in the normal case that git is doing line-ending conversion, > > but it's suppressed when textconv is in use. > > I would not consider this a bug if not for the fact that there is no ^M > without using iconv as

Re: [PATCH v3] http.postbuffer: allow full range of ssize_t values

On Fri, Mar 31, 2017 at 01:26:31PM -0400, David Turner wrote: > Unfortunately, in order to push some large repos, the http postbuffer > must sometimes exceed two gigabytes. On a 64-bit system, this is OK: > we just malloc a larger buffer. I'm still not sure why a 2GB post-buffer is necessary.