BUG: sequencer.c:795: root commit without message -- when rewording root commit

Hi Johannes, I was splitting a repository tonight and ran 'rebase -i --root' to reword the initial commit. Then git died with 'BUG: sequencer.c:795: root commit without message.' A simple test case to show the failure: -- >8 -- diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-reb

Re: (Bug report + fix) gitk "IgnCase" search doesn't ignore case

nly the "ignore case" item; it does not implement "regexp" functionality, so it could be considered incomplete. A more complete fix would also disable the "regexp" item to avoid misleading users, and to head off future bug reports similar to this one saying that "reg

Re: BUG: submodule code prints '(null)'

On Thu, Jun 14, 2018 at 5:15 PM Heiko Voigt wrote: > ... > Would you want to update your patch? Or should I put one on top? I think it's better that you make a proper patch. You can provide explanation and all. I am more like a bug reporter :) -- Duy

Re: BUG: submodule code prints '(null)'

On Mon, Jun 11, 2018 at 03:56:16PM -0700, Stefan Beller wrote: > On Sat, Jun 9, 2018 at 4:04 AM Duy Nguyen wrote: > > > > On Tue, Jun 05, 2018 at 05:31:41PM +0200, Duy Nguyen wrote: > > > I do not know how to reproduce this (and didn't bother to look deeply > > > into it after I found it was not

(Bug report + fix) gitk "IgnCase" search doesn't ignore case

Hi, this question was originally posted on the Google Groups list, trying to get help (https://groups.google.com/d/topic/git-users/QAFKOQU4eUo/discussion). Now that it's confirmed as a bug and I have a proposed solution, I'm posting here. Gitk "find commit" search function does

Re: BUG: submodule code prints '(null)'

On Sat, Jun 9, 2018 at 4:04 AM Duy Nguyen wrote: > > On Tue, Jun 05, 2018 at 05:31:41PM +0200, Duy Nguyen wrote: > > I do not know how to reproduce this (and didn't bother to look deeply > > into it after I found it was not a trivial fix) but one of my "git > > fetch" showed > > > > warning:

Re: [BUG] git-rebase: reword squashes commits in case of merge-conflicts

On Mon, Jun 11, 2018 at 06:06:11PM +0200, ch wrote: > After the rebase the 'stuff' branch only has a single commit even though I'd > expect there to be two according to the instructions that were passed to > git-rebase. It works as expected if there's either no merge-conflict at the > reword or

Re: BUG: submodule code prints '(null)'

On Sat, Jun 9, 2018 at 4:04 AM Duy Nguyen wrote: > > On Tue, Jun 05, 2018 at 05:31:41PM +0200, Duy Nguyen wrote: > > I do not know how to reproduce this (and didn't bother to look deeply > > into it after I found it was not a trivial fix) but one of my "git > > fetch" showed > > > > warning:

[BUG] git-rebase: reword squashes commits in case of merge-conflicts

Hi all! During a recent rebase operation on one of my repositories a number of commits unexpectedly ended up getting squashed into other commits. After some experiments it turned out that the 'reword' instruction seems to squash the referenced commit into the preceding commit if there's a

Re: BUG: submodule code prints '(null)'

On Tue, Jun 05, 2018 at 05:31:41PM +0200, Duy Nguyen wrote: > I do not know how to reproduce this (and didn't bother to look deeply > into it after I found it was not a trivial fix) but one of my "git > fetch" showed > > warning: Submodule in commit be2db96a6c506464525f588da59cade0cedddb5e > at

[PATCH 06/20] blame: fix a bug, core.abbrev should work like --abbrev

on length to account for the boundary commit. This was changed in 91229834c2 ("blame: fix alignment with --abbrev=40", 2017-01-05) first released with v2.11.1. That change had a bug which I'm fixing here. It didn't account for the abbreviation length also being set via core.abbrev, not just via th

BUG: Merge commits are displayed by `--cherry-pick` despite on they introduce same change

The `--cherry-pick` option states: >Omit any commit that introduces the same change as another commit on the >“other side” For next git command I see next tree: $ git log --graph --decorate --pretty=oneline --abbrev-commit --cherry-mark --boundary --left-right < bc2820d

Re: git rm bug

On Wed, Jun 06 2018, Timothy Rice wrote: >> It does seem like something which could be noted in the git >> rm docs. Perhaps you'd care to take a stab at a patch to >> add a note to Documentation/git-rm.txt Thomas? Maybe a note >> at the end of the DISCUSSION section? > > That same

Re: git rm bug

On Wed, Jun 06 2018, Thomas Fischer wrote: > I agree that the entire chain of empty directories should not be > tracked, as git tracks content, not files. > > However, when I run 'rm path/to/some/file', I expect path/to/some/ to > still exist. > > Similarly, when I run 'git rm

Re: git rm bug

On Thu, 7 Jun 2018, Timothy Rice wrote: > > It does seem like something which could be noted in the git > > rm docs. Perhaps you'd care to take a stab at a patch to > > add a note to Documentation/git-rm.txt Thomas? Maybe a note > > at the end of the DISCUSSION section? > > That same

Re: git rm bug

> It does seem like something which could be noted in the git > rm docs. Perhaps you'd care to take a stab at a patch to > add a note to Documentation/git-rm.txt Thomas? Maybe a note > at the end of the DISCUSSION section? That same documentation could mention a common workaround for when

Re: git rm bug

On Wed, Jun 06, 2018 at 04:01:38PM -0400, Todd Zullinger wrote: > Thomas Fischer wrote: > > I agree that the entire chain of empty directories should not be tracked, > > as git tracks content, not files. > > > > However, when I run 'rm path/to/some/file', I expect path/to/some/ to still > >

Re: git rm bug

Thomas Fischer wrote: > I agree that the entire chain of empty directories should not be tracked, as > git tracks content, not files. > > However, when I run 'rm path/to/some/file', I expect path/to/some/ to still > exist. > > Similarly, when I run 'git rm path/to/some/file', I expect

Re: git rm bug

On Wed, Jun 6, 2018 at 9:32 PM, Thomas Fischer wrote: > OVERVIEW > > "git rm" will remove more files than specified. This is either a bug or > undocumented behavior (not in the man pages). The behavior is intended, with a question mark. This change is introduced in d9b814

Re: git rm bug

On Wed, 6 Jun 2018, Thomas Fischer wrote: > I agree that the entire chain of empty directories should not be > tracked, as git tracks content, not files. > > However, when I run 'rm path/to/some/file', I expect path/to/some/ > to still exist. why? > Similarly, when I run 'git rm

Re: git rm bug

; > > > "git rm" will remove more files than specified. This is either a bug or > > undocumented behavior (not in the man pages). > > > > SETUP > > > > 1. In a git repository, create an empty directory OR a chain of empty > > directories &g

Re: git rm bug

On Wed, 6 Jun 2018, Thomas Fischer wrote: > OVERVIEW > > "git rm" will remove more files than specified. This is either a bug or > undocumented behavior (not in the man pages). > > SETUP > > 1. In a git repository, create an empty directory OR a chain of empty

git rm bug

OVERVIEW "git rm" will remove more files than specified. This is either a bug or undocumented behavior (not in the man pages). SETUP 1. In a git repository, create an empty directory OR a chain of empty directories $ mkdir -p path/to/some/ 2. Create a file in the deepest directo

Re: BUG: submodule code prints '(null)'

On Tuesday 05 June 2018 09:01 PM, Duy Nguyen wrote: > I'll leave it to submodule people to fix this :) > I'm Ccing the only one I know to gain attention. -- Sivaraam QUOTE: “The three principal virtues of a programmer are Laziness, Impatience, and Hubris.” - Camel book Sivaraam?

BUG: submodule code prints '(null)'

I do not know how to reproduce this (and didn't bother to look deeply into it after I found it was not a trivial fix) but one of my "git fetch" showed warning: Submodule in commit be2db96a6c506464525f588da59cade0cedddb5e at path: '(null)' collides with a submodule named the same. Skipping it. I

Re: [PATCH/RFC/BUG] unpack-trees.c: do not use "the_index"

On 06/02, Elijah Newren wrote: > On Fri, Jun 1, 2018 at 10:03 PM, Duy Nguyen wrote: > > On Fri, Jun 1, 2018 at 8:34 PM, Elijah Newren wrote: > >> On Fri, Jun 1, 2018 at 9:11 AM, Nguyễn Thái Ngọc Duy > >> wrote: > >>> This is more of a bug report

Re: [PATCH/RFC/BUG] unpack-trees.c: do not use "the_index"

On Fri, Jun 1, 2018 at 10:03 PM, Duy Nguyen wrote: > On Fri, Jun 1, 2018 at 8:34 PM, Elijah Newren wrote: >> On Fri, Jun 1, 2018 at 9:11 AM, Nguyễn Thái Ngọc Duy >> wrote: >>> This is more of a bug report than an actual fix because I'm not sure >>> if &qu

Re: [PATCH/RFC/BUG] unpack-trees.c: do not use "the_index"

ot;the_index" while some other times "the_index" >> is the global variable because the function just does not have a >> parameter of the same name! The only subtle difference is that the >> function parameter is a pointer while the global one is not. >>

Re: [PATCH/RFC/BUG] unpack-trees.c: do not use "the_index"

On Fri, Jun 1, 2018 at 8:51 PM, Stefan Beller wrote: > On Fri, Jun 1, 2018 at 11:34 AM, Elijah Newren wrote: > >>> +/* Do not use the_index here, you probably want o->src_index */ >>> +#define the_index the_index_should_not_be_used here >> >> Good call. > > Is the space instead of the underscore

Re: [PATCH/RFC/BUG] unpack-trees.c: do not use "the_index"

On Fri, Jun 1, 2018 at 11:34 AM, Elijah Newren wrote: >> +/* Do not use the_index here, you probably want o->src_index */ >> +#define the_index the_index_should_not_be_used here > > Good call. Is the space instead of the underscore between the last two words intentional?

Re: [PATCH/RFC/BUG] unpack-trees.c: do not use "the_index"

e the function just does not have a > parameter of the same name! The only subtle difference is that the > function parameter is a pointer while the global one is not. > > This is more of a bug report than an actual fix because I'm not sure > if "o->src_index" is always

[PATCH/RFC/BUG] unpack-trees.c: do not use "the_index"

rameter is a pointer while the global one is not. This is more of a bug report than an actual fix because I'm not sure if "o->src_index" is always the correct answer instead of "the_index" here. But this is very similar to 7db118303a (unpack_trees: fix breakage when o->src

Re: Is origin/HEAD only being created on clone a bug? #leftoverbits

On Wed, May 30, 2018 at 11:46:16AM +0900, Junio C Hamano wrote: > Junio C Hamano writes: > > > - When we fetch from a remote that has refs/remotes/$name/HEAD, and > >if the protocol notices that their HEAD today is pointing to a > >branch different from what our side has, should we

Re: Bug: Install from .tar.xz fails without write permission on /usr/local/share/man/man3

On Thu, May 31, 2018 at 06:30:18PM +0200, ml...@posteo.de wrote: > I was trying to build git 2.9.5 as a normal user, as I have no root access > on a cluster with outdated software. > > The build fails, unless I change the PREFIX=/usr/local line in > per/perl.mak:80 to a folder where I have write

Re: Is origin/HEAD only being created on clone a bug? #leftoverbits

Ævar Arnfjörð Bjarmason writes: > We already have to deal with this special case of origin/HEAD > being re-pointed in a repository that we "clone", so we would just > do whatever happens to a repository that's cloned. OK. Not visiting that issue while we discuss this "origin/HEAD is useful, so

Re: Bug: Install from .tar.xz fails without write permission on /usr/local/share/man/man3

Hi, On Thu, May 31, 2018 at 6:30 PM, wrote: > > I was trying to build git 2.9.5 as a normal user, as I have no root access > on a cluster with outdated software. > > The build fails, unless I change the PREFIX=/usr/local line in > per/perl.mak:80 to a folder where I have write permission. >

Bug: Install from .tar.xz fails without write permission on /usr/local/share/man/man3

Hi, I was trying to build git 2.9.5 as a normal user, as I have no root access on a cluster with outdated software. The build fails, unless I change the PREFIX=/usr/local line in per/perl.mak:80 to a folder where I have write permission. Apparently, perl.mak does not honour the --prefix=

Re: Is origin/HEAD only being created on clone a bug? #leftoverbits

add origin", it >does count in this category), should we get a remote-tracking >symref $name/HEAD so that we can say "log $name.."? > >We absolutely should. We (eh, rather, those who added "remote >add"; this was not my itch and I am using &

Re: [bug-ish] [convenience] fatal: only [12] (reference)s? expected, [12] given

On Wed, May 30, 2018 at 1:12 AM, mana vortex wrote: > Hello git folks, > I’m writing about something that annoys me since forever: The reference > handling is not consistent between commands. For example, I do > > git checkout origin master $ git checkout origin master error: pathspec

[bug-ish] [convenience] fatal: only [12] (reference)s? expected, [12] given

Hello git folks, I’m writing about something that annoys me since forever: The reference handling is not consistent between commands. For example, I do git checkout origin master but I do git reset —hard origin/master I always get it wrong the first time. Is there a convenience option that

Re: Is origin/HEAD only being created on clone a bug? #leftoverbits

Junio C Hamano writes: > - When we fetch from a remote that has refs/remotes/$name/HEAD, and >if the protocol notices that their HEAD today is pointing to a >branch different from what our side has, should we repoint ours >to match? > >I am leaning against doing this, but

Re: Is origin/HEAD only being created on clone a bug? #leftoverbits

e absolutely should. We (eh, rather, those who added "remote add"; this was not my itch and I am using "royal we" in this sentence) just did not bother to and I think it is a bug that you cannot say "log $name.." Of course, it is just a "git symbolic-ref"

Re: Is origin/HEAD only being created on clone a bug? #leftoverbits

ss_remote_head() > etc. in builtin/clone.c. I.e. this is special-cased as part of the > "clone". > > Can anyone thing of a reason for why this shouldn't be fixed as a bug? > I've tried searching the archives but "origin/HEAD" comes up with t

Is origin/HEAD only being created on clone a bug? #leftoverbits

ted accordingly, but from the repo you pushed from & the one you did init+fetch instead of clone you'll never see it. Some code spelunking reveals remote_head_points_at, guess_remote_head() etc. in builtin/clone.c. I.e. this is special-cased as part of the "clone". Can anyone thing

Re: BUG: No way to set fsck. when cloning

On Thu, May 24 2018, Thomas Braun wrote: > Am 24.05.2018 um 17:25 schrieb Ævar Arnfjörð Bjarmason: >> When I do: >> >> git -c fetch.fsckObjects=true clone >> g...@github.com:robbyrussell/oh-my-zsh.git >> >> I get: >> >> error: object 2b7227859263b6aabcc28355b0b994995b7148b6: >>

Re: Wrong -dirty suffix set by setlocalversion (was: BUG in git diff-index)

ke prepare # Simulate a copy of the tree but with just one file rsync --perms --times README README.mtime_backup rm README rsync --perms --times README.mtime_backup README stat README README.mtime_backup # Demo the BUG fixed by Mike ./scripts/setlocalversion # -dirty BUG! because spuriou

Re: Wrong -dirty suffix set by setlocalversion (was: BUG in git diff-index)

How about something like this? It ignores attributes that should have no bearing on whether the kernel is considered dirty. Copied trees with no other changes would no longer be marked with -dirty. Plus it works on read-only media since no index updating is required. Would this also be considered

BUG: No way to set fsck. when cloning

Am 24.05.2018 um 17:25 schrieb Ævar Arnfjörð Bjarmason: > When I do: > > git -c fetch.fsckObjects=true clone > g...@github.com:robbyrussell/oh-my-zsh.git > > I get: > > error: object 2b7227859263b6aabcc28355b0b994995b7148b6: > zeroPaddedFilemode: contains zero-padded file modes >

Re: BUG: No way to set fsck. when cloning

On Thu, May 24, 2018 at 07:04:04PM +0200, Ævar Arnfjörð Bjarmason wrote: > That doesn't work, because that's for the server-side, but I need the > fetch.fsck.* that doesn't exist. This works (I'll send a better patch > with tests / docs etc. soon): Yeah, I think this is the right direction. >

Re: BUG: No way to set fsck. when cloning

On Thu, May 24, 2018 at 05:25:29PM +0200, Ævar Arnfjörð Bjarmason wrote: > When I do: > > git -c fetch.fsckObjects=true clone > g...@github.com:robbyrussell/oh-my-zsh.git > > I get: > > error: object 2b7227859263b6aabcc28355b0b994995b7148b6: > zeroPaddedFilemode: contains zero-padded

Re: BUG: No way to set fsck. when cloning

On Thu, May 24 2018, Kevin Daudt wrote: > On Thu, May 24, 2018 at 05:25:29PM +0200, Ævar Arnfjörð Bjarmason wrote: >> When I do: >> >> git -c fetch.fsckObjects=true clone >> g...@github.com:robbyrussell/oh-my-zsh.git >> >> I get: >> >> error: object

Re: BUG: No way to set fsck. when cloning

On Thu, May 24, 2018 at 05:25:29PM +0200, Ævar Arnfjörð Bjarmason wrote: > When I do: > > git -c fetch.fsckObjects=true clone > g...@github.com:robbyrussell/oh-my-zsh.git > > I get: > > error: object 2b7227859263b6aabcc28355b0b994995b7148b6: > zeroPaddedFilemode: contains zero-padded

BUG: No way to set fsck. when cloning

When I do: git -c fetch.fsckObjects=true clone g...@github.com:robbyrussell/oh-my-zsh.git I get: error: object 2b7227859263b6aabcc28355b0b994995b7148b6: zeroPaddedFilemode: contains zero-padded file modes fatal: Error in object fatal: index-pack failed The docs

Re: BUG: rev-parse segfault with invalid input

Hi, Elijah Newren wrote: > Thanks for the detailed report. This apparently goes back to > git-1.6.0 with commit 2122f8b963d4 ("rev-parse: Add support for the ^! > and ^@ syntax", 2008-07-26). We aren't checking that the commit from > lookup_commit_reference() is non-NULL before proceeding.

Re: BUG: rev-parse segfault with invalid input

://bugzilla.redhat.com/1581678 > > Simple reproduction recipe and analysis, from the bug: > > $ git init > Initialized empty Git repository in /tmp/t/.git/ > $ git rev-parse ^@ > Segmentation fault (core dumped) > >

BUG: rev-parse segfault with invalid input

Hi, Certain invalid input causes git rev-parse to crash rather than return a 'fatal: ambiguous argument ...' error. This was reported against the Fedora git package: https://bugzilla.redhat.com/1581678 Simple reproduction recipe and analysis, from the bug: $ git init Initialized

Re: bug: --shallow-since misbehaves on old branch heads

I probably can't look into this until the weekend. Just wanted to let you know that I've seen this mail and, being the one who introduced --shallow-since, I will look into it soon (unless someone beats me to it of course). -- Duy

bug: --shallow-since misbehaves on old branch heads

Hi everybody, I think I have discovered a problem with clone/fetch --shallow-since: When a ref that is fetches has a head that is already older than the 'since' time, then the entire branch is fetched, instead of just the current commit. Repro: rm -rf tmp out deep git init tmp for i in

Bug in update-index man page

I've noticed the following text in the documentation pages for the `update-index` command: Files to act on. Note that files beginning with . are discarded. This includes ./file and dir/./file. If you don't want this, then use cleaner names. The same applies to

Re: [PATCH 1/2] get_main_ref_store: BUG() when outside a repository

dir(), and outside a repository that would > trigger a BUG(). After that commit, though, we directly use > the_repository->git_dir; if it's NULL we'll just segfault. > > Let's catch this case and restore the BUG() behavior. > Obviously we don't ever want to hit this code, but a BUG() > is a

[PATCH 1/2] get_main_ref_store: BUG() when outside a repository

If we don't have a repository, then we can't initialize the ref store. Prior to 64a741619d (refs: store the main ref store inside the repository struct, 2018-04-11), we'd try to access get_git_dir(), and outside a repository that would trigger a BUG(). After that commit, though, we directly use

[PATCH 1/1] config: a user-provided invalid section is not a BUG

cf->var.len - 1] != '.') - BUG("Invalid section name '%s'", cf->var.buf); + return error("invalid section name '%s'", cf->var.buf); /* Is this the section we were looking for? */ store->is_keys_section = -- 2.17.0.windows.1.42.gaba71d8cd65

Re: Git log range reverse bug

Am 16.05.2018 um 20:19 schrieb Mehdi Zeinali: Git Version: Version: 2.14.2 When reversing a range in git log, it does not start from the expected commit: --reverse does not change the meaning A..B to B..A or something. For a particular A..B specification, the set of commits selected when

Re: Git log range reverse bug

Hi Mendi, On 5/16/2018 2:19 PM, Mehdi Zeinali wrote: Git Version: Version: 2.14.2 When reversing a range in git log, it does not start from the expected commit: $ git show 8e11b4a41ec21e47fb0bf8b76e1edba739f57a9b commit 8e11b4a41ec21e47fb0bf8b76e1edba739f57a9b Author: Some Name

Git log range reverse bug

Git Version: Version: 2.14.2 When reversing a range in git log, it does not start from the expected commit: $ git show 8e11b4a41ec21e47fb0bf8b76e1edba739f57a9b commit 8e11b4a41ec21e47fb0bf8b76e1edba739f57a9b Author: Some Name Date: Mon Nov 3 19:01:53 2014 + . . .

Re: [BUG] git send-email: incorrectly parses email address with comma

On 05/12/2018 11:48 AM, Jeff King wrote: > On Sat, May 12, 2018 at 10:21:46AM +0200, Heinrich Schuchardt wrote: > >> Git send-email allows to combine multiple email addresses in one >> parameter, e.g. >> >> --to="a...@example.com, b...@example.com" >> >> But email addresses may contain commas

Re: [BUG] git send-email: incorrectly parses email address with comma

On Sat, May 12, 2018 at 10:21:46AM +0200, Heinrich Schuchardt wrote: > Git send-email allows to combine multiple email addresses in one > parameter, e.g. > > --to="a...@example.com, b...@example.com" > > But email addresses may contain commas themselves: > > --to="LASTNAME, firstname

Re: Bug report for git push

On Fri, May 11, 2018 at 09:44:54PM -0400, Surenkumar Nihalani wrote: > Push summary: [remote rejected] (cannot lock ref 'refs/heads/master': is at > cf2cc0c147d8215ec87d3ddaf32f0b2c58630423 but expected > fdda486ad43a6e6b5dc5f2795ce27124e0686752) This generally indicates that somebody was

[BUG] git send-email: incorrectly parses email address with comma

Git send-email allows to combine multiple email addresses in one parameter, e.g. --to="a...@example.com, b...@example.com" But email addresses may contain commas themselves: --to="LASTNAME, firstname " This may lead to an error: $ git send-email

Bug report for git push

Hi everyone! I am facing this spurious issue (not easily reproducible and usually a retry fixes it) with git push: Warning: Permanently added 'github.com,192.30.255.112' (RSA) to the list of known hosts. Counting objects: 8, done. Delta compression using up to 2 threads. Compressing objects:

Re: Git case-sensitivity bug

Hey Cliff, On Thu, May 10, 2018 at 12:46 PM Cliff <miliw...@gmail.com> wrote: > I believe I have discovered a bug with git tools. > If you create a git branch, you can refer to that branch with > case-insensitive alterations and it will track as the same branch. This comes

Git case-sensitivity bug

I believe I have discovered a bug with git tools. If you create a git branch, you can refer to that branch with case-insensitive alterations and it will track as the same branch. If I create branch "test" I cannot then create branch "Test" because the same name is already

Bug: Untracked file deleted by git-stash

can tell). The following steps can be used to reproduce: $ mkdir /tmp/bug; cd /tmp/bug $ git init Initialized empty Git repository in /tmp/bug/.git/ $ echo 'original file' > entry $ git add entry $ git commit -m 'entry added' [master (root-commit) 483319e] entry added 1 file changed, 1 insert

Re: bug: SHA1 calculation on PPC machines when built with gcc older than 4.6

at the primary test: > > #if defined(__BYTE_ORDER__) && defined(__ORDER_BIG_ENDIAN__) > > only works as of gcc-4.6 and newer, so the code is built as LITTLE_ENDIAN on > PPC with older gcc versions. > > > Issue report: > > <https://github.com/cr-marcstevens/

bug: SHA1 calculation on PPC machines when built with gcc older than 4.6

PPC with older gcc versions. Issue report: <https://github.com/cr-marcstevens/sha1collisiondetection/issues/40> MacPorts bug report: <https://trac.macports.org/ticket/54602> The included patch to git fixes the issue on our testing. Thanks for git! Ken Cunningham ===

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

On Wed, May 02, 2018 at 11:38:31AM +0200, Johannes Schindelin wrote: > 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

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

On Wed, May 02, 2018 at 11:38:13AM +0200, Johannes Schindelin wrote: > 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("

Re: [bug] Multiline value should error if the next line is section

> On Sun, 6 May 2018 22:03:10 +0200 > Martin Ågren wrote: > > On 6 May 2018 at 21:03, Shulhan wrote: > > > [alias] > > > tree = --no-pager log --graph \ > > > -n 20 \ > > > [user] > > > name = Shulhan > > > > > > (2) Run

Re: [bug] Multiline value should error if the next line is section

On Sun, 6 May 2018 22:03:10 +0200 Martin Ågren wrote: > Hi Shulhan > > Thank you for your report. I'm abbreviating a bit: > > On 6 May 2018 at 21:03, Shulhan wrote: > > [alias] > > tree = --no-pager log --graph \ > > -n 20 \ >

Re: [bug] Multiline value should error if the next line is section

On Sun, May 06, 2018 at 10:03:10PM +0200, Martin Ågren wrote: > This behavior looks correct to me, though. It seems very hard to me to > second-guess what the user meant. For example, what if that third line > contained a "="? Like: > > [alias] > huh = !dd \ > bs=1024 ... >

Re: [bug] Multiline value should error if the next line is section

Hi Shulhan Thank you for your report. I'm abbreviating a bit: On 6 May 2018 at 21:03, Shulhan wrote: > [alias] > tree = --no-pager log --graph \ > -n 20 \ > [user] > name = Shulhan > > (2) Run `git config -f git.config -l` > > The command print

[bug] Multiline value should error if the next line is section

## Environment OS: Arch Linux Git version: git@next d54016d9e ## Reproduction Steps (1) Create the following `git.config`, ``` [alias] tree = --no-pager log --graph \ --date=format:'%Y-%m-%d' \ --pretty=format:'%C(auto,dim)%ad %<(7,trunc) %an %Creset%m

Re: [PATCH v2 1/4] test-tool: help verifying BUG() code paths

Hi Duy, On Wed, 2 May 2018, Duy Nguyen wrote: > On Wed, May 2, 2018 at 11:38 AM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: > > When we call BUG(), we signal via SIGABRT that something bad happened, > > dumping cores if so configured. In som

Re: git update-ref fails to create reference. (bug)

Thanks Martin for the quick fix. On Fri, May 04, 2018 at 08:26:46PM +0200, Martin �gren wrote: > Anyway, that's not where I'm stuck... Regardless of how I try to write > tests (in t1400), they just pass beautifully even before this patch. I > might be able to look into that more on the weekend.

Re: git update-ref fails to create reference. (bug)

Hi Rafael, On 4 May 2018 at 18:28, Rafael Ascensão wrote: > While trying to create a pseudo reference named REF pointing to the > empty tree iff it doesn't exist, I stumbled on the following: > > I assume both are valid ways to create such reference: > a) $ echo -e

git update-ref fails to create reference. (bug)

While trying to create a pseudo reference named REF pointing to the empty tree iff it doesn't exist, I stumbled on the following: I assume both are valid ways to create such reference: a) $ echo -e option no-deref\\nupdate REF $(git hash-object -t tree /dev/null)

Re: [PATCH v2 1/4] test-tool: help verifying BUG() code paths

On Wed, May 2, 2018 at 11:38 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > When we call BUG(), we signal via SIGABRT that something bad happened, > dumping cores if so configured. In some setups these coredumps are > redirected to some central place such as /

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

Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> As discussed in this thread, tests that use t/helper/ executables >> that try to trickle BUG() codepath to ensure that these "should >> never happen" conditions are caught do need to deal with it.

[PATCH v2 0/4] 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 v2 2/4] 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 v2 3/4] 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 v2 4/4] Convert remaining die*(BUG) messages

These were not caught by the previous commit, as they did not match the regular expression. While at it, remove the localization from one instance: we never want BUG() messages to be translated, as they target Git developers, not the end user (hence it would be quite unhelpful to not only burden

[PATCH v2 1/4] test-tool: help verifying BUG() code paths

When we call BUG(), we signal via SIGABRT that something bad happened, dumping cores if so configured. In some setups these coredumps are redirected to some central place such as /proc/sys/kernel/core_pattern, which is a good thing. However, when we try to verify in our test suite that bugs

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

Hi, On Wed, 2 May 2018, Junio C Hamano wrote: > Duy Nguyen <pclo...@gmail.com> writes: > > > On Mon, Apr 30, 2018 at 12:17 AM, Johannes Schindelin > > <johannes.schinde...@gmx.de> wrote: > >> t1406 specifically verifies that certain code

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

Duy Nguyen <pclo...@gmail.com> writes: > On Mon, Apr 30, 2018 at 12:17 AM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: >> t1406 specifically verifies that certain code paths fail with a BUG: ... >> message. >> >> In the upcoming commit, we

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

On Mon, Apr 30, 2018 at 12:17 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > 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 d

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

On Tue, May 1, 2018 at 1:04 PM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: >> If SIGABRT occurs as a result of BUG(), and we know that this happens for >> certain cases, it means we have an unfixed bug. > > Not in this case: The code in question is in > http

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

Hi Hannes, On Mon, 30 Apr 2018, Johannes Sixt wrote: > Am 30.04.2018 um 00:17 schrieb Johannes Schindelin: > > t1406 specifically verifies that certain code paths fail with a BUG: ... > > message. > > > > In the upcoming commit, we will convert that message to be gene

RE: Branch deletion question / possible bug?

ect: Re: Branch deletion question / possible bug? Hi, On Sat, 28 Apr 2018, Philip Oakley wrote: > From: "Jacob Keller" <jacob.kel...@gmail.com> > > On Fri, Apr 27, 2018 at 5:29 PM, Tang (US), Pik S > > <pik.s.t...@boeing.com> > > wrote: > > >

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

Am 30.04.2018 um 00:17 schrieb Johannes Schindelin: 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

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