Re: BUG report: unicode normalization on APFS (Mac OS High Sierra)

Hi, On Fri, Apr 27, 2018 at 2:45 PM, Totsten Bögershausen wrote: > On 2018-04-26 19:23, Elijah Newren wrote: >> Sure. First, though, note that I can make it pass (or at least "not >> ok...TODO known breakage") with the following patch (may be >> whitespace-damaged by gmail): >>

Re: Bug: format-patch MIME boundary not added to cover letter when attach enabled

On Mon, Apr 30, 2018 at 12:30:57PM +0900, Junio C Hamano wrote: > Thanks. It is true that the current output from the tool is corrupt > mime multi-part, and we need to do something about it. > > I however have to wonder if it even makes sense for --cover to pay > attention to --attach and

Re: Bug: format-patch MIME boundary not added to cover letter when attach enabled

"brian m. carlson" writes: > On Sun, Apr 29, 2018 at 09:40:13PM -0400, Patrick Hemmer wrote: >> When you use `git format-patch --cover-letter --attach`, the cover >> letter does not have the trailing MIME boundary. RFC2046 states that the >> last part must be

Re: [PATCH 6/6] Convert remaining die*(BUG) messages

gt; diff --git a/submodule.c b/submodule.c > @@ -2043,7 +2043,7 @@ const char *get_superproject_working_tree(void) > if (super_sub_len > cwd_len || > strcmp([cwd_len - super_sub_len], super_sub)) > - die (_(&q

Re: Bug: format-patch MIME boundary not added to cover letter when attach enabled

On Sun, Apr 29, 2018 at 09:40:13PM -0400, Patrick Hemmer wrote: > When you use `git format-patch --cover-letter --attach`, the cover > letter does not have the trailing MIME boundary. RFC2046 states that the > last part must be followed by a closing boundary. This causes some email > clients

Bug: format-patch MIME boundary not added to cover letter when attach enabled

When you use `git format-patch --cover-letter --attach`, the cover letter does not have the trailing MIME boundary. RFC2046 states that the last part must be followed by a closing boundary. This causes some email clients (Thunderbird in my case) to discard the message body. This is experienced

[PATCH 6/6] Convert remaining die*(BUG) messages

tx) do { \ if (qsort_s((base), (n), sizeof(*(base)), compar, ctx)) \ - die("BUG: qsort_s() failed"); \ + BUG("qsort_s() failed");\ } while (0) #ifndef REG_STARTEND diff --git a/pat

[PATCH 5/6] Replace all die("BUG: ...") calls by BUG() ones

In d8193743e08 (usage.c: add BUG() function, 2017-05-12), a new macro was introduced to use for reporting bugs instead of die(). It was then subsequently used to convert one single caller in 588a538ae55 (setup_git_env: convert die("BUG") to BUG(), 2017-05-12). The cover letter of the pa

[PATCH 3/6] refs/*: report bugs using the BUG() macro

We just prepared t1406 to be okay with BUG reports resulting in SIGABRT instead of a regular exit code indicating failure. This commit now makes it so: by calling BUG() (which eventually calls `abort()`), we no longer exit with code 128 but instead throw that signal. This trick was performed

[PATCH 4/6] run-command: use BUG() to report bugs, not die()

The slightly misleading name die_bug() of the function intended to report a bug is actually called always, and only reports a bug if the passed-in parameter `err` is non-zero. It uses die_errno() to report the bug, to helpfully include the error message corresponding to `err`. However

[PATCH 2/6] t1406: prepare for the refs code to fail with BUG()

t1406 specifically verifies that certain code paths fail with a BUG: ... message. In the upcoming commit, we will convert that message to be generated via BUG() instead of die("BUG: ..."), which implies SIGABRT instead of a regular exit code. Signed-off-by: Johannes Schindelin <joh

[PATCH 0/6] Finish the conversion from die("BUG: ...") to BUG()

The BUG() macro was introduced in this patch series: https://public-inbox.org/git/20170513032414.mfrwabt4hovuj...@sigill.intra.peff.net The second patch in that series converted one caller from die("BUG: ") to use the BUG() macro. It seems that there was no concrete plan to addres

[PATCH v7 03/12] replace: avoid using die() to indicate a bug

We have the BUG() macro for that purpose. Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de> --- builtin/replace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/replace.c b/builtin/replace.c index 245d3f4164e..e345a5a0f1c 100644 --- a/builtin/rep

Re: Branch deletion question / possible bug?

sitive file system? What version of > > git? I thought I recalled seeing commits to help avoid creating > > branches of the same name with separate case when we know we're on a > > file system which is case-insensitive.. > > > > > Normally, it should have been impossibl

Re: [Bug] git log --show-signature print extra carriage return ^M

hannes Schindelin <johannes.schinde...@gmx.de>: > > Hi Larry, > > > > On Sun, 4 Mar 2018, Larry Hunter wrote: > > > >> There is bug using "git log --show-signature" in my installation > >> > >> git 2.16.2.windows.1 > &g

Re: Branch deletion question / possible bug?

the deletion left me in a weird state that took a while to dig out of. I know this was a user error, but I was also wondering if this was a bug. If we have not yet done this, I think we should. Long term this would be fixed by using a separate format to store refs than the filesystem, which

Re: Branch deletion question / possible bug?

they're on. And the deletion left me in a weird state that took a while to > dig out of. > > I know this was a user error, but I was also wondering if this was a bug. If we have not yet done this, I think we should. Long term this would be fixed by using a separate format to store refs th

Branch deletion question / possible bug?

was a user error, but I was also wondering if this was a bug. Thanks, Pik Tang

Re: BUG report: unicode normalization on APFS (Mac OS High Sierra)

On 2018-04-26 19:23, Elijah Newren wrote: On Thu, Apr 26, 2018 at 10:13 AM, Torsten Bögershausen wrote: Hm, thanks for the report. I don't have a high sierra box, but I can probably get one. t0050 -should- pass automagically, so I feel that I can do something. Unless someone

[PATCH v6 03/11] replace: avoid using die() to indicate a bug

We have the BUG() macro for that purpose. Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de> --- builtin/replace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/replace.c b/builtin/replace.c index 245d3f4164e..e345a5a0f1c 100644 --- a/builtin/rep

Re: BUG report: unicode normalization on APFS (Mac OS High Sierra)

On Thu, Apr 26, 2018 at 10:13 AM, Torsten Bögershausen wrote: > Hm, > thanks for the report. > I don't have a high sierra box, but I can probably get one. > t0050 -should- pass automagically, so I feel that I can do something. > Unless someone is faster of course. Sweet, thanks

Re: BUG report: unicode normalization on APFS (Mac OS High Sierra)

On 26.04.18 18:48, Elijah Newren wrote: > On HFS (which appears to be the default Mac filesystem prior to High > Sierra), unicode names are "normalized" before recording. Thus with a > script like: > > mkdir tmp > cd tmp > > auml=$(printf "\303\244") > aumlcdiar=$(printf

BUG report: unicode normalization on APFS (Mac OS High Sierra)

On HFS (which appears to be the default Mac filesystem prior to High Sierra), unicode names are "normalized" before recording. Thus with a script like: mkdir tmp cd tmp auml=$(printf "\303\244") aumlcdiar=$(printf "\141\314\210") >"$auml" echo "auml: " $(echo

[PATCH v5 03/11] replace: avoid using die() to indicate a bug

We have the BUG() macro for that purpose. Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de> --- builtin/replace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/replace.c b/builtin/replace.c index 245d3f4164e..e345a5a0f1c 100644 --- a/builtin/rep

[PATCH v4 03/11] replace: avoid using die() to indicate a bug

We have the BUG() macro for that purpose. Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de> --- builtin/replace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/replace.c b/builtin/replace.c index 245d3f4164e..e345a5a0f1c 100644 --- a/builtin/rep

[PATCH v3 03/11] replace: avoid using die() to indicate a bug

We have the BUG() macro for that purpose. Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de> --- builtin/replace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/replace.c b/builtin/replace.c index 245d3f4164e..e345a5a0f1c 100644 --- a/builtin/rep

Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

Hi Stefan, On Fri, 20 Apr 2018, Stefan Beller wrote: > > Funny thing is: I tested this with GETTEXT_POISON=1, and it succeeded. > > I actually wanted to review the code leading to this commit, and to find > where to start reviewing I had 'git grep "This is a combination of"' which > lead me to

Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

Hi Eric, On Fri, 20 Apr 2018, Eric Sunshine wrote: > On Fri, Apr 20, 2018 at 3:29 PM, Eric Sunshine > wrote: > > On Fri, Apr 20, 2018 at 8:17 AM, Johannes Schindelin > > wrote: > >> + test_must_fail env FAKE_LINES="1 fixup 2 fixup 4"

Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

Hi Johannes, > Funny thing is: I tested this with GETTEXT_POISON=1, and it succeeded. I actually wanted to review the code leading to this commit, and to find where to start reviewing I had 'git grep "This is a combination of"' which lead me to the translation files. s/grep/test_i18ngrep/

Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

Hi Stefan, On Fri, 20 Apr 2018, Johannes Schindelin wrote: > A brief test shows, however, that it is not quite as easy as > s/grep/test_i18ngrep/, something more seems to be broken. It seems that this week is my Rabbit Hole Week. Turns out that we have a really, really long-standing bug

Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

Hi Stefan, On Fri, 20 Apr 2018, Stefan Beller wrote: > On Fri, Apr 20, 2018 at 5:17 AM, Johannes Schindelin > wrote: > > When multiple fixup/squash commands are processed and the last one > > causes merge conflicts and is skipped, we leave the "This is a > >

Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

On Fri, Apr 20, 2018 at 3:29 PM, Eric Sunshine wrote: > On Fri, Apr 20, 2018 at 8:17 AM, Johannes Schindelin > wrote: >> + test_must_fail env FAKE_LINES="1 fixup 2 fixup 4" \ >> + git rebase -i HEAD~4 && >> + >> + :

Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

On Fri, Apr 20, 2018 at 8:17 AM, Johannes Schindelin wrote: > When multiple fixup/squash commands are processed and the last one > causes merge conflicts and is skipped, we leave the "This is a > combination of ..." comments in the commit message. > > Signed-off-by:

Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

On Fri, Apr 20, 2018 at 5:17 AM, Johannes Schindelin wrote: > When multiple fixup/squash commands are processed and the last one > causes merge conflicts and is skipped, we leave the "This is a > combination of ..." comments in the commit message. > > Noticed by Eric

RE: [BUG] Git fast-export with import marks file omits merge commits

To: Junio C Hamano <gits...@pobox.com> Cc: Isaac Chou <isaac.c...@microfocus.com>; Johannes Schindelin <johannes.schinde...@gmx.de>; Jonathan Tan <jonathanta...@google.com>; git@vger.kernel.org Subject: Re: [BUG] Git fast-export with import marks file omits merge commits O

[PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

When multiple fixup/squash commands are processed and the last one causes merge conflicts and is skipped, we leave the "This is a combination of ..." comments in the commit message. Noticed by Eric Sunshine. Signed-off-by: Johannes Schindelin ---

Re: Bug Report - Pull remote branch does not retrieve new tags

this has meant that tags are no longer being fetched. > > What _does_ seem to work is adding "--tags" on the end of the git pull. But > this isn't actually in the documentation[1], and I'm a bit nervous that this > is mid-deprecation. > > Is "--tags" going aw

RE: Bug Report - Pull remote branch does not retrieve new tags

seem to work is adding "--tags" on the end of the git pull. But this isn't actually in the documentation[1], and I'm a bit nervous that this is mid-deprecation. Is "--tags" going away shortly? Or are they ok to depend on this? The bug is at https://github.com/Micro

Re: [BUG] Git fast-export with import marks file omits merge commits

t is discarded too early by the call to object_array_pop() >> after only one of the two UNSHOWN parents is processed in the >> method handle_tail(). The poped merge commit still has one >> UNSHOWN parent, therefore it is not processed and is lost in the >> output. Can someo

Re: [BUG] Git fast-export with import marks file omits merge commits

rents is processed in the > method handle_tail(). The poped merge commit still has one > UNSHOWN parent, therefore it is not processed and is lost in the > output. Can someone advise me on how to submit a code change or > bug report in order to get the fix into the code base? > >

Re: [BUG] Git fast-export with import marks file omits merge commits

after only one of the two UNSHOWN parents is > processed in the method handle_tail(). The poped merge commit still has one > UNSHOWN parent, therefore it is not processed and is lost in the output. Can > someone advise me on how to submit a code change or bug report in order to >

Re: Bug Report - Pull remote branch does not retrieve new tags

hink should happen: > The "git pull origin master" should retrieve the tag. > > This is with 2.16.2.windows.1, but also occurred on my previously installed > version (2.12.2.windows.2) > > My understanding is that "git pull" and "git pull $repo $cu

RE: [BUG] Git fast-export with import marks file omits merge commits

still has one UNSHOWN parent, therefore it is not processed and is lost in the output. Can someone advise me on how to submit a code change or bug report in order to get the fix into the code base? Thanks, Isaac -Original Message- From: git-ow...@vger.kernel.org [mailto:git-ow

Bug Report - Pull remote branch does not retrieve new tags

(2.12.2.windows.2) My understanding is that "git pull" and "git pull $repo $currentbranch" should function identically. Is this a bug, or am I misunderstanding the manual page? Thanks, Andy Confidentiality - This email is confidential. Not meant for you? - If you don't th

Re: Bug: rebase -i creates committer time inversions on 'reword'

On 16/04/18 10:48, Phillip Wood wrote: > On 14/04/18 14:11, Johannes Schindelin wrote: >> Hi, >> >> On Sat, 14 Apr 2018, Phillip Wood wrote: >> >> FWIW I agree with Hannes' patch. >> >>> I think 'git am' probably gives all patches the same commit time as well >>> if the commit date is cached

Re: [BUG] git p4 clone fails when p4 sizes does not return 'fileSize' key

Just to be clear - git-p4 does not use the p4 "sizes" command anywhere AFAIK. We are just talking about the output from "p4 print" and the "fileSize" key, right? --> Correct. Does that happen with the 17.2 version of p4? -->Correct. print() probably makes more sense; can we try to use the

Re: [BUG] git p4 clone fails when p4 sizes does not return 'fileSize' key

On 17 April 2018 at 20:12, Thandesha VK wrote: > I have few cases where even p4 -G sizes (or p4 sizes) is not returning > the size value even with latest version of p4 (17.2). In that case, we > have to regenerate the digest for file save it - It mean something is > wrong with

Re: Bug: rebase -i creates committer time inversions on 'reword'

On 16/04/18 06:56, Johannes Sixt wrote: > > Am 15.04.2018 um 23:35 schrieb Junio C Hamano: >> Ah, do you mean we have an internal sequence like this, when "rebase >> --continue" wants to conclude an edit/reword? > > Yes, it's only 'reword' that is affected, because then subsequent picks > are

Re: [BUG] git p4 clone fails when p4 sizes does not return 'fileSize' key

I have few cases where even p4 -G sizes (or p4 sizes) is not returning the size value even with latest version of p4 (17.2). In that case, we have to regenerate the digest for file save it - It mean something is wrong with the file in perforce. Regarding, sys.stdout.write v/s print, I see script

Re: [BUG] git p4 clone fails when p4 sizes does not return 'fileSize' key

Does a missing "fileSize" actually mean that there is something wrong with the file? Because, for me, `p4 -G print` doesn't print "fileSize" for _any_ file. (which I attribute to our rather ancient (2007.2) Perforce server) I'm not an expert in Perforce, so don't know for sure. However, `p4 -G

Re: [BUG] git p4 clone fails when p4 sizes does not return 'fileSize' key

Sounds good. How about an enhanced version of fix from both of us. This will let us know that something is not right with the file but will not bark $ git diff diff --git a/git-p4.py b/git-p4.py index 7bb9cadc6..df901976f 100755 --- a/git-p4.py +++ b/git-p4.py @@ -2566,7 +2566,12 @@ class

Re: [BUG] git p4 clone fails when p4 sizes does not return 'fileSize' key

Sure, I totally agree. Sorry, I just wasn't clear enough in my previous email. I meant that your patch suppresses "%s --> %s (%i MB)" line in case "fileSize" is not available, while my patch suppresses just "(%i MB)" portion if the "fileSize" is not known. In other words, * if "fileSize" is

Re: [BUG] git p4 clone fails when p4 sizes does not return 'fileSize' key

*I* think keeping the filesize info is better with --verbose option as that gives some clue about the file we are working on. What do you think? Script has similar checks of key existence at other places where it is looking for fileSize. On Tue, Apr 17, 2018 at 9:22 AM, Andrey Mazo

Re: [BUG] git p4 clone fails when p4 sizes does not return 'fileSize' key

Huh, I actually have a slightly different fix for the same issue. It doesn't suppress the corresponding verbose output completely, but just removes the size information from it. I'll (try to) post it as a reply to this email. Also, I'd mention that the workaround is trivial -- simply omit the

Re: [BUG] git p4 clone fails when p4 sizes does not return 'fileSize' key

Huh, I actually have a slightly different fix for the same issue. It doesn't suppress the corresponding verbose output completely, but just removes the size information from it. Also, I'd mention that the workaround is trivial -- simply omit the "--verbose" option. Andrey Mazo (1): git-p4:

Re: Bug: rebase -i creates committer time inversions on 'reword'

Johannes Sixt writes: > Am 15.04.2018 um 23:35 schrieb Junio C Hamano: >> Ah, do you mean we have an internal sequence like this, when "rebase >> --continue" wants to conclude an edit/reword? > > Yes, it's only 'reword' that is affected, because then subsequent > picks are

[BUG] git p4 clone fails when p4 sizes does not return 'fileSize' key

git p4 clone fails when p4 sizes does not return 'fileSize' key. There are few cases when p4 sizes returens 0 size and with marshaled output, it doesn’t return the fileSize attribute. Here is the demonstration and potential fix $ cd /tmp/git/ $ git remote -v origin

Re: Bug: rebase -i creates committer time inversions on 'reword'

were made during the same second, > of course.) > > So while I cannot find anything in the code that disagrees with Hannes' > assessment, it looks on the surface as if I did not encounter the bug > here. > > Curious. That's strange (I'd have expected the picks after recreat

Re: Bug: rebase -i creates committer time inversions on 'reword'

Am 15.04.2018 um 23:35 schrieb Junio C Hamano: Ah, do you mean we have an internal sequence like this, when "rebase --continue" wants to conclude an edit/reword? Yes, it's only 'reword' that is affected, because then subsequent picks are processed by the original process. - we figure out

Re: Bug: rebase -i creates committer time inversions on 'reword'

Johannes Sixt writes: > I just noticed that all commits in a 70-commit branch have the same > committer timestamp. This is very unusual on Windows, where rebase -i of > such a long branch takes more than one second (but not more than 3 or > so thanks to the builtin nature of the

Re: Bug: rebase -i creates committer time inversions on 'reword'

-good `rebase-merges` sub-branch) shows that the commits have different-enough commit timestamps. (It is satisfying to see that multiple commits were made during the same second, of course.) So while I cannot find anything in the code that disagrees with Hannes' assessment, it looks on the surface as i

Re: Bug: rebase -i creates committer time inversions on 'reword'

On 13/04/18 17:52, Johannes Sixt wrote: > > I just noticed that all commits in a 70-commit branch have the same > committer timestamp. This is very unusual on Windows, where rebase -i of > such a long branch takes more than one second (but not more than 3 or > so thanks to the builtin nature of

Bug: rebase -i creates committer time inversions on 'reword'

I just noticed that all commits in a 70-commit branch have the same committer timestamp. This is very unusual on Windows, where rebase -i of such a long branch takes more than one second (but not more than 3 or so thanks to the builtin nature of the command!). And, in fact, if you mark some

[PATCH v3 08/15] t1300: `--unset-all` can leave an empty section behind (bug)

We already have a test demonstrating that removing the last entry from a config section fails to remove the section header of the now-empty section. The same can happen, of course, if we remove the last entries in one fell swoop. This is *also* a bug, and should be fixed at the same time. Signed

[PATCH v3 05/15] t1300: avoid relying on a bug

The test case 'unset with cont. lines' relied on a bug that is about to be fixed: it tests *explicitly* that removing the last entry from a config section leaves an *empty* section behind. Let's fix this test case not to rely on that behavior, simply by preventing the section from becoming empty

[PATCH v3 00/15] Assorted fixes for `git config` (including the "empty sections" bug)

This patch series originally only tried to help fixing that annoying bug that has been reported several times over the years, where `git config --unset` would leave empty sections behind, and `git config --add` would not reuse them. The first patch is somewhat of a "while at it" bug

Re: [PATCH v2 00/15] Assorted fixes for `git config` (including the "empty sections" bug)

Hi Peff, On Fri, 6 Apr 2018, Jeff King wrote: > On Tue, Apr 03, 2018 at 06:27:55PM +0200, Johannes Schindelin wrote: > > > I am very, very grateful for the time Peff spent on reviewing the > > previous iteration, and hope that he realizes just how much the > > elegance of the event-stream-based

Re: [PATCH v2 00/15] Assorted fixes for `git config` (including the "empty sections" bug)

On Tue, Apr 03, 2018 at 06:27:55PM +0200, Johannes Schindelin wrote: > I am very, very grateful for the time Peff spent on reviewing the previous > iteration, and hope that he realizes just how much the elegance of the > event-stream-based version is due to his excellent review. Unfortunately I

Re: [PATCH v2 00/15] Assorted fixes for `git config` (including the "empty sections" bug)

ace-all: avoid extra line breaks > t1300: avoid relying on a bug > t1300: remove unreasonable expectation from TODO > t1300: `--unset-all` can leave an empty section behind (bug) > config: introduce an optional event stream while parsing > config: avoid using the global varia

[PATCH v2 07/15] t1300: `--unset-all` can leave an empty section behind (bug)

We already have a test demonstrating that removing the last entry from a config section fails to remove the section header of the now-empty section. The same can happen, of course, if we remove the last entries in one fell swoop. This is *also* a bug, and should be fixed at the same time. Signed

[PATCH v2 05/15] t1300: avoid relying on a bug

The test case 'unset with cont. lines' relied on a bug that is about to be fixed: it tests *explicitly* that removing the last entry from a config section leaves an *empty* section behind. Let's fix this test case not to rely on that behavior, simply by preventing the section from becoming empty

[PATCH v2 00/15] Assorted fixes for `git config` (including the "empty sections" bug)

This patch series originally only tried to help fixing that annoying bug that has been reported several times over the years, where `git config --unset` would leave empty sections behind, and `git config --add` would not reuse them. The first patch is somewhat of a "while at it" bug

Re: Possible bug in git log with date ranges

On Mon, Apr 02 2018, David Hoyle wrote: > Hi, > > Hopefully I've read the readme file correctly for submitting something > that might be a bug. > > I've recently migrated projects from an old version control system > (JEDI VCS) to Git (which I really like BTW).

Possible bug in git log with date ranges

Hi, Hopefully I've read the readme file correctly for submitting something that might be a bug. I've recently migrated projects from an old version control system (JEDI VCS) to Git (which I really like BTW). The way this was done was by extracting the files from the original database and saving

Re: [PATCH 0/9] Assorted fixes for `git config` (including the "empty sections" bug)

Hi Ævar, On Fri, 30 Mar 2018, Ævar Arnfjörð Bjarmason wrote: > > On Thu, Mar 29 2018, Johannes Schindelin wrote: > > > Nonetheless, I would be confortable with this patch going into > > v2.17.0, even at this late stage. The final verdict is Junio's, of > > course. > > Thanks a lot for working

Re: [PATCH 0/9] Assorted fixes for `git config` (including the "empty sections" bug)

On Thu, Mar 29 2018, Johannes Schindelin wrote: > Nonetheless, I would be confortable with this patch going into v2.17.0, even > at > this late stage. The final verdict is Junio's, of course. Thanks a lot for working on this. I'm keen to stress test this, but won't have time in the next few

Re: [PATCH 3/9] t1300: avoid relying on a bug

Hi Peff, On Thu, 29 Mar 2018, Jeff King wrote: > On Thu, Mar 29, 2018 at 05:18:45PM +0200, Johannes Schindelin wrote: > > > The test case 'unset with cont. lines' relied on a bug that is about to > > be fixed: it tests *explicitly* that removing the last entry from a > &g

Re: [PATCH 0/9] Assorted fixes for `git config` (including the "empty sections" bug)

Hi Peff, On Thu, 29 Mar 2018, Jeff King wrote: > On Thu, Mar 29, 2018 at 05:18:30PM +0200, Johannes Schindelin wrote: > > > The first patch is somewhat of a "while at it" bug fix that I first > > thought would be a lot more critical than it actually is: It really &

Re: [PATCH 0/9] Assorted fixes for `git config` (including the "empty sections" bug)

out the key/value pair instead of deleting it. > It's called --unset, not --delete ;) That would open the door to new bug reports when a user starts with this concocted config: [section] # This is a comment about the `key` setting key = value and then

Re: [PATCH 5/9] t1300: `--unset-all` can leave an empty section behind (bug)

entries in one fell > swoop. This is *also* a bug, and should be fixed at the same time. Yep, makes sense, and the diff is obviously correct. -Peff

Re: [PATCH 3/9] t1300: avoid relying on a bug

On Thu, Mar 29, 2018 at 05:18:45PM +0200, Johannes Schindelin wrote: > The test case 'unset with cont. lines' relied on a bug that is about to > be fixed: it tests *explicitly* that removing the last entry from a > config section leaves an *empty* section behind. > > Let's fix

Re: [PATCH 0/9] Assorted fixes for `git config` (including the "empty sections" bug)

a "while at it" bug fix that I first thought > would be a lot more critical than it actually is: It really only affects > config > files that start with a section followed immediately (i.e. without a newline) > by a one-letter boolean setting (i.e. without a `= ` part). So while

Re: [PATCH 0/9] Assorted fixes for `git config` (including the "empty sections" bug)

On Thu, Mar 29, 2018 at 8:18 AM, Johannes Schindelin wrote: > So what is the argument against this extra care to detect comments? Well, if > you have something like this: > > [section] > ; Here we comment about the variable called snarf >

[PATCH 3/9] t1300: avoid relying on a bug

The test case 'unset with cont. lines' relied on a bug that is about to be fixed: it tests *explicitly* that removing the last entry from a config section leaves an *empty* section behind. Let's fix this test case not to rely on that behavior, simply by preventing the section from becoming empty

[PATCH 5/9] t1300: `--unset-all` can leave an empty section behind (bug)

We already have a test demonstrating that removing the last entry from a config section fails to remove the section header of the now-empty section. The same can happen, of course, if we remove the last entries in one fell swoop. This is *also* a bug, and should be fixed at the same time. Signed

[PATCH 0/9] Assorted fixes for `git config` (including the "empty sections" bug)

This patch series started out as a single patch trying to figure out what it takes to fix that annoying bug that has been reported several times over the years, where `git config --unset` would leave empty sections behind, and `git config --add` would not reuse them. Little did I know

Re: Apparent bug in credential tool running...

Quick note: I did submit the patch, look for subject line " [PATCH] credential: cred helper fast exit can cause SIGPIPE, crash". Thanks again Jeff, Erik 

Re: git submodule deinit resulting in BUG: builtin/submodule--helper.c:1045: module_list_compute should not choke on empty pathspec

On Wed, Mar 28, 2018 at 12:37 PM, Peter Oberndorfer wrote: >>> 2) Should "git submodule deinit" work on submodules that were removed by >> upstream already? >> >> To answer the question "Is this a submodule that upstream removed >> (recently)?" >> we'd have to put in some

Re: Apparent bug in credential tool running...

Sure, I can submit a patch if the change looks good to you (with my lack of experience in the git source and very rusty C I would, of course, defer to an expert in the area on exactly where to place the SIGPIPE ignore push and pop and such... but what's below seems to avoid the race for us

Re: git submodule deinit resulting in BUG: builtin/submodule--helper.c:1045: module_list_compute should not choke on empty pathspec

On 2018-03-28 00:56, Stefan Beller wrote: > On Tue, Mar 27, 2018 at 12:55 PM Peter Oberndorfer <kumbay...@arcor.de> > wrote: Hi, as expected your patch fixed the BUG output. Thanks! >> 2) Should "git submodule deinit" work on submodules that were removed by > u

Re: Apparent bug in credential tool running...

On Wed, Mar 28, 2018 at 06:26:08PM +, Erik Brady -X (brady - ROBERT HALF INTERNATIONAL INC at Cisco) wrote: > The location of the problem is in credential.c, run_credential_helper()... > this code: > >... > fp = xfdopen(helper.in, "w"); > credential_write(c, fp); >

Apparent bug in credential tool running...

Hi git Experts, I believe we've encountered a bug in git. I built the latest, git 2.16.3, and it still appears to be a problem. I'm not a git expert and my C is ridiculously rusty but I think a co-worker and I figured it out... apologies if we are incorrect in any assumptions (as I do

Re: Bug: duplicate sections in .git/config after remote removal

the user put > a valuable comment just after or before the '[branch "master"]' line?) > as well as (b) the way the parser/writer works (single pass, line by line) > > (b) specifically made it a "huge effort, but little return" bug, > so nobody got around for a proper

Re: Bug: duplicate sections in .git/config after remote removal

From: "Ævar Arnfjörð Bjarmason" <ava...@gmail.com> On Tue, Mar 27 2018, Jason Frey wrote: While the impact of this bug is minimal, and git itself is not affected, it can affect external tools that want to read the .git/config file, expecting unique section names. To r

Re: Bug: duplicate sections in .git/config after remote removal

From: "Ævar Arnfjörð Bjarmason" <ava...@gmail.com> On Tue, Mar 27 2018, Jason Frey wrote: While the impact of this bug is minimal, and git itself is not affected, it can affect external tools that want to read the .git/config file, expecting unique section names. To r

Re: Bug: duplicate sections in .git/config after remote removal

From: "Ævar Arnfjörð Bjarmason" <ava...@gmail.com> On Tue, Mar 27 2018, Jason Frey wrote: While the impact of this bug is minimal, and git itself is not affected, it can affect external tools that want to read the .git/config file, expecting unique section names. To r

Re: Bug: duplicate sections in .git/config after remote removal

From: "Ævar Arnfjörð Bjarmason" <ava...@gmail.com> On Tue, Mar 27 2018, Jason Frey wrote: While the impact of this bug is minimal, and git itself is not affected, it can affect external tools that want to read the .git/config file, expecting unique section names. To r

Re: git submodule deinit resulting in BUG: builtin/submodule--helper.c:1045: module_list_compute should not choke on empty pathspec

On Tue, Mar 27, 2018 at 12:55 PM Peter Oberndorfer <kumbay...@arcor.de> wrote: > Hi, > i tried to run "git submodule deinit xxx" > on a submodule that was recently removed from the Rust project. > But git responded with a BUG/Core dump (and also did not remove

Re: Bug: duplicate sections in .git/config after remote removal

On Tue, Mar 27 2018, Jason Frey wrote: > While the impact of this bug is minimal, and git itself is not > affected, it can affect external tools that want to read the > .git/config file, expecting unique section names. > > To reproduce: > > Given the following example .

Re: Bug: duplicate sections in .git/config after remote removal

efore the '[branch "master"]' line?) as well as (b) the way the parser/writer works (single pass, line by line) (b) specifically made it a "huge effort, but little return" bug, so nobody got around for a proper fix. Thanks, Stefan

<    1   2   3   4   5   6   7   8   9   10   >