Re: [PATCH] Fixes compile warning with -Wimplicit-fallthrough CFLAGS

mpiler attribute >> > when needed on switch case statement eliminating >> > the compile warning [-Werror=implicit-fallthrough=]. >> > It does this by means of a macro that takes into account >> > the versions of the compilers that include that attribute. >> > [..

Re: [PATCH] Fixes compile warning with -Wimplicit-fallthrough CFLAGS

On Mon, Jan 22, 2018 at 07:54:18PM -0500, Eric Sunshine wrote: > On Mon, Jan 22, 2018 at 6:51 PM, Elia Pinto <gitter.spi...@gmail.com> wrote: > > This patch add explicit fallthrough compiler attribute > > when needed on switch case statement eliminating > > the compil

Re: [PATCH] Fixes compile warning with -Wimplicit-fallthrough CFLAGS

On Mon, Jan 22, 2018 at 6:51 PM, Elia Pinto <gitter.spi...@gmail.com> wrote: > This patch add explicit fallthrough compiler attribute > when needed on switch case statement eliminating > the compile warning [-Werror=implicit-fallthrough=]. > It does this by means of a macro that

Re: [PATCH] Fixes compile warning with -Wimplicit-fallthrough CFLAGS

On Mon, Jan 22, 2018 at 11:51:18PM +, Elia Pinto wrote: > This patch add explicit fallthrough compiler attribute > when needed on switch case statement eliminating > the compile warning [-Werror=implicit-fallthrough=]. > It does this by means of a macro that takes into account &g

[PATCH] Fixes compile warning with -Wimplicit-fallthrough CFLAGS

This patch add explicit fallthrough compiler attribute when needed on switch case statement eliminating the compile warning [-Werror=implicit-fallthrough=]. It does this by means of a macro that takes into account the versions of the compilers that include that attribute. The fallthrough

RE: unused variable in hashmap.h [was: Re: [PATCH] Fixed pervasive enumeration warning in convert.h.]

> Sent: On January 13, 2018 12:13 PM, René Scharfe wrote: > Am 12.01.2018 um 20:52 schrieb Randall S. Becker: > > On a related too many warnings subject, hashmap.h has a variable > > unused (void *item). Is that addressed soon? If not, I can deal with > > it. > Here are the code lines containing

unused variable in hashmap.h [was: Re: [PATCH] Fixed pervasive enumeration warning in convert.h.]

Am 12.01.2018 um 20:52 schrieb Randall S. Becker: > On a related too many warnings subject, hashmap.h has a variable > unused (void *item). Is that addressed soon? If not, I can deal with > it. Here are the code lines containing the variable in question: void *item; while ((item =

RE: [PATCH] Fixed pervasive enumeration warning in convert.h.

> From: Junio C Hamano [mailto:gits...@pobox.com] On January 12, 2018 2:25 PM, Junio C Hamano wrote: > > From: "Randall S. Becker" > > { > > - return convert_to_git(istate, path, NULL, 0, NULL, 0); > > + return convert_to_git(istate, path, NULL, 0, NULL, >

Re: [PATCH] Fixed pervasive enumeration warning in convert.h.

randall.s.bec...@rogers.com writes: > From: "Randall S. Becker" <rsbec...@nexbridge.com> > > The actual enum value should be used rather than 0 and was causing > a warning in an inline proc. > > Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com> >

[PATCH] Fixed pervasive enumeration warning in convert.h.

From: "Randall S. Becker" <rsbec...@nexbridge.com> The actual enum value should be used rather than 0 and was causing a warning in an inline proc. Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com> --- convert.h | 2 +- 1 file changed, 1 insertion(+), 1 d

Re: [PATCH] repository: fix a sparse 'using integer as NULL pointer' warning

gt;> repository structure, without modifying the initializer of the 'the_repo' >> variable. This does not actually introduce a bug, since the '0' initializer >> for the 'ignore_env:1' bit-field is interpreted as a NULL pointer (hence >> the warning), and the final field (now with

Re: [PATCH] repository: fix a sparse 'using integer as NULL pointer' warning

lizer of the 'the_repo' > variable. This does not actually introduce a bug, since the '0' initializer > for the 'ignore_env:1' bit-field is interpreted as a NULL pointer (hence > the warning), and the final field (now with no initializer) receives a > default '0'. > > Signed-off-by: R

Re: [PATCH] repository: fix a sparse 'using integer as NULL pointer' warning

Ramsay Jones writes: > Hi Junio, > > I don't recall Brian doing a re-roll of the 'bc/hash-algo' branch[1], but > now that it has been merged into the 'next' branch, sparse is barking on > that branch too. This patch (slightly different to the last one) applies > on

[PATCH] repository: fix a sparse 'using integer as NULL pointer' warning

nitializer for the 'ignore_env:1' bit-field is interpreted as a NULL pointer (hence the warning), and the final field (now with no initializer) receives a default '0'. Signed-off-by: Ramsay Jones <ram...@ramsayjones.plus.com> --- Hi Junio, I don't recall Brian doing a re-roll of the 'bc/has

Re: core.safecrlf warning is confusing[improvement suggestion?]

On Wed, Nov 22, 2017 at 11:01:22AM +0900, Junio C Hamano wrote: > Torsten Bögershausen writes: > > >> I want to have LF line endings in the repository and CRLF endings in > >> the working copy. (Because I use windows-exclusive tools to develop.) > > > > Side note: If you ever want

Re: core.safecrlf warning is confusing[improvement suggestion?]

Torsten Bögershausen writes: >> I want to have LF line endings in the repository and CRLF endings in >> the working copy. (Because I use windows-exclusive tools to develop.) > > Side note: If you ever want to push your repository somewhere, > it would be good practice to have a

Re: core.safecrlf warning is confusing[improvement suggestion?]

ocedure). > > So I put the source in the working directory and tell git to make > > git diff --stat As Junio pointed out, it is probably not git diff saying this ? Typically "git add" gives the warning. > > and I see the (ambiguous) warnings: > > 'warning:

Re: core.safecrlf warning is confusing[improvement suggestion?]

Vladimir Nikishkin writes: > I want to have LF line endings in the repository and CRLF endings in > the working copy. (Because I use windows-exclusive tools to develop.) > > But for start I have my code with LF endings, because I got it from a > fellow developer, who

Re: core.safecrlf warning is confusing[improvement suggestion?]

Vladimir Nikishkin <lockyw...@gmail.com> writes: > So I put the source in the working directory and tell git to make > > git diff --stat > > and I see the (ambiguous) warnings: > > 'warning: LF will be replaced by CRLF in filename.m. > The file will have its origin

core.safecrlf warning is confusing[improvement suggestion?]

' have them converted to CRLF (since this is a checkout procedure). So I put the source in the working directory and tell git to make git diff --stat and I see the (ambiguous) warnings: 'warning: LF will be replaced by CRLF in filename.m. The file will have its original line endings in you working

[PATCH 3/4] branch: update warning message shown when copying a misnamed branch

the misnamed branch. This is not correct and may confuse the user. So, update the warning message shown to be more precise that only a copy of the misnamed branch has been created. It's better to show the warning message than not showing it at all as it makes the user aware of the presence of a misnamed branch. Si

Re: [PATCH] repository: fix a sparse 'using integer a NULL pointer' warning

René Scharfe writes: >> diff --git a/repository.c b/repository.c >> index 01af20dee..ceef73614 100644 >> --- a/repository.c >> +++ b/repository.c >> @@ -5,7 +5,7 @@ >> >> /* The main repository */ >> static struct repository the_repo = { >> -NULL, NULL, NULL, NULL, NULL,

Re: [PATCH] repository: fix a sparse 'using integer a NULL pointer' warning

f the 'the_repo' variable. This does not actually introduce a bug, > since the '0' initializer for the 'ignore_env:1' bit-field is > interpreted as a NULL pointer (hence the warning), and the final field > (now with no initializer) receives a default '0'. > > Signed-off-by: R

Re: [PATCH] repository: fix a sparse 'using integer a NULL pointer' warning

ifying the initializer > of the 'the_repo' variable. This does not actually introduce a bug, > since the '0' initializer for the 'ignore_env:1' bit-field is > interpreted as a NULL pointer (hence the warning), and the final field > (now with no initializer) receives a default '0'. >

[PATCH] repository: fix a sparse 'using integer a NULL pointer' warning

nce the '0' initializer for the 'ignore_env:1' bit-field is interpreted as a NULL pointer (hence the warning), and the final field (now with no initializer) receives a default '0'. Signed-off-by: Ramsay Jones <ram...@ramsayjones.plus.com> --- Hi Brian, If you need to re-roll your 'bc/hash-algo' b

[PATCH v2] stash: prevent warning about null bytes in input

sure `untracked_files` does not output null bytes when not required. This is achieved by adding a parameter to the `untracked_files` function to specify wither `-z` should be passed to ls-files or not. This warning is triggered when running git stash save -u resulting in two warnings: git

Re: [PATCH] stash: prevent warning about null bytes in input

Kevin Daudt writes: > On Mon, Aug 14, 2017 at 12:51:26PM -0700, Junio C Hamano wrote: >> Kevin Daudt writes: >> >> > The no_changes function calls the untracked_files function through >> > command substitution. untracked_files will return null bytes because it

Re: [PATCH] stash: prevent warning about null bytes in input

On Mon, Aug 14, 2017 at 12:51:26PM -0700, Junio C Hamano wrote: > Kevin Daudt writes: > > > The no_changes function calls the untracked_files function through > > command substitution. untracked_files will return null bytes because it > > runs ls-files with the '-z' option. > > >

Re: [PATCH] stash: prevent warning about null bytes in input

Kevin Daudt writes: > The no_changes function calls the untracked_files function through > command substitution. untracked_files will return null bytes because it > runs ls-files with the '-z' option. > > Bash since version 4.4 warns about these null bytes. As they are not >

[PATCH] stash: prevent warning about null bytes in input

bytes from the input. This warning is triggered when running git stash save -u resulting in two warnings: git-stash: line 43: warning: command substitution: ignored null byte in input Signed-off-by: Kevin Daudt <m...@ikke.info> --- git-stash.sh | 2 +- 1 file changed, 1 insertion

Re: Warning suggestion for git stash drop

Oh great, an answer 20 days later ... Sorry about this. I have been reading a bit on the topic and found that for Bash we should be using shell functions over aliases so I wrote this function to be simply added to the .bashrc: # 'git stash drop' confirm shell function git() { if [[ $@ ==

Re: [PATCH] status: suppress additional warning output in plumbing modes

ing a chance > to the brain to think things through. > sort of. > Surely the reported symptom may have only been about CRLF, but who > says that would be the only kind of warning that would be seen > during "status --porcelain" codepath? I was slightly worried about t

Re: [PATCH] status: suppress additional warning output in plumbing modes

> --- > > Maybe something like this? This looks to me like a stimulus having enough time to go to the spinal cord to induce a knee-jerk reaction, without giving a chance to the brain to think things through. Surely the reported symptom may have only been about CRLF, but who says that would be the

Re: [PATCH] status: suppress additional warning output in plumbing modes

On Fri, Jun 30 2017, Stefan Beller jotted: > When status is called with '--porcelain' (as implied by '-z'), we promise > to output only messages as described in the man page. > > Suppress CRLF warnings. > > Signed-off-by: Stefan Beller > --- > > Maybe something like this?

Re: [PATCH] status: suppress additional warning output in plumbing modes

>On 30/06/17 18:28, Stefan Beller wrote: The patch makes a lot of sense - thanks for the fast reply. A question: does the header correspond to the patch ? < [PATCH] status: suppress additional warning output in plumbing modes > [PATCH] status: suppress CRLF warnings in porcel

Re: Warning suggestion for git stash drop

Laurent Humblet writes: > Thank you for your feedback. > > I suppose that turning a hypothetical confirmation option 'on' would > impact a stash pop for instance as it automatically drops the stash if > it was applied without conflicts. > > What about a --confirm flag?

Re: Warning suggestion for git stash drop

; >>> Would it be possible to add an optional Yes/No when doing a 'git stash >>> drop'? Something similar as what happens when pushing on a remotely >>> checked out branch (with a config setting to turn the warning on/off). >>> >>> I know that you can alw

[PATCH] status: suppress additional warning output in plumbing modes

When status is called with '--porcelain' (as implied by '-z'), we promise to output only messages as described in the man page. Suppress CRLF warnings. Signed-off-by: Stefan Beller --- Maybe something like this? builtin/commit.c | 5 + 1 file changed, 5 insertions(+)

Re: Warning suggestion for git stash drop

g on a remotely >> checked out branch (with a config setting to turn the warning on/off). >> >> I know that you can always get your dropped stash back using git >> reflog but a small warning might be a useful feature to avoid unwanted >> stash drops on a regular basis. &

Re: Warning suggestion for git stash drop

Laurent Humblet <laurent.humb...@gmail.com> writes: > Would it be possible to add an optional Yes/No when doing a 'git stash > drop'? Something similar as what happens when pushing on a remotely > checked out branch (with a config setting to turn the warning on/off). > >

Warning suggestion for git stash drop

Hi all, Would it be possible to add an optional Yes/No when doing a 'git stash drop'? Something similar as what happens when pushing on a remotely checked out branch (with a config setting to turn the warning on/off). I know that you can always get your dropped stash back using git reflog

Re: Ambiguity warning printed twice ?

On Thu, 2017-06-22 at 10:23 -0400, Jeff King wrote: > It's not unreasonable for a complex command like git-status to need > to > resolve HEAD multiple times. You can see how we get to each case by > running: > >   gdb /path/to/git-status > > and then doing: > >   b

Re: Ambiguity warning printed twice ?

On Thu, Jun 22, 2017 at 06:16:21PM +0530, Kaartic Sivaraam wrote: > I accidentally noticed a weird behaviour of 'git status'. In a > repository I created a branch with the name 'HEAD' by chance. When I > run 'git status' in the repository it prints a warning about an > ambiguous ref

Ambiguity warning printed twice ?

Happy day everyone, I accidentally noticed a weird behaviour of 'git status'. In a repository I created a branch with the name 'HEAD' by chance. When I run 'git status' in the repository it prints a warning about an ambiguous reference about 'HEAD' which is expected but it prints it twice which

[PATCH v3 01/13] git_fopen: fix a sparse 'not declared' warning

From: Ramsay Jones <ram...@ramsayjones.plus.com> If git is built with the FREAD_READS_DIRECTORIES build variable set, this would cause sparse to issue a 'not declared, should it be static?' warning on Linux. This is a result of the method employed by 'compat/fopen.c' to suppress the (po

[PATCH v4 29/31] pack-objects: fix buggy warning about threads

Fix a buggy warning about threads under NO_PTHREADS=YesPlease. Due to re-using the delta_search_threads variable for both the state of the "pack.threads" config & the --threads option, setting "pack.threads" but not supplying --threads would trigger the warning for both &q

[PATCH v4 28/31] pack-objects & index-pack: add test for --threads warning

Add a test for the warning that's emitted when --threads or pack.threads is provided under NO_PTHREADS=YesPlease. This uses the new PTHREADS prerequisite. The assertion for C_LOCALE_OUTPUT in the latter test is currently redundant, since unlike index-pack the pack-objects warnings aren't i18n'd

[PATCH v3 27/30] pack-objects & index-pack: add test for --threads warning

Add a test for the warning that's emitted when --threads or pack.threads is provided under NO_PTHREADS=YesPlease. This uses the new PTHREADS prerequisite. The assertion for C_LOCALE_OUTPUT in the latter test is currently redundant, since unlike index-pack the pack-objects warnings aren't i18n'd

[PATCH v3 28/30] pack-objects: fix buggy warning about threads

Fix a buggy warning about threads under NO_PTHREADS=YesPlease. Due to re-using the delta_search_threads variable for both the state of the "pack.threads" config & the --threads option, setting "pack.threads" but not supplying --threads would trigger the warning for both &q

Re: [PATCH v2 27/29] pack-objects: fix buggy warning about threads

On Mon, May 15, 2017 at 10:59 AM, Junio C Hamano <gits...@pobox.com> wrote: > Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes: > >> Fix a buggy warning about threads under NO_PTHREADS=YesPlease. Due to >> re-using the delta_search_threads variable for both the

[PATCH 2/2] mingw: Suppress warning that :.gitattributes does not exist

On Windows, a file name containing a colon is illegal. We should therefore expect the corresponding errno when `fopen()` is called for a path of the form :.gitattributes. This fixes the symptom reported in https://github.com/git-for-windows/git/issues/255 Signed-off-by: Johannes

Re: [PATCH v2 27/29] pack-objects: fix buggy warning about threads

Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes: > Fix a buggy warning about threads under NO_PTHREADS=YesPlease. Due to > re-using the delta_search_threads variable for both the state of the > "pack.threads" config & the --threads option, setting "pack.thre

[PATCH v2 27/29] pack-objects: fix buggy warning about threads

Fix a buggy warning about threads under NO_PTHREADS=YesPlease. Due to re-using the delta_search_threads variable for both the state of the "pack.threads" config & the --threads option, setting "pack.threads" but not supplying --threads would trigger the warning for both &q

[PATCH v2 26/29] pack-objects & index-pack: add test for --threads warning

Add a test for the warning that's emitted when --threads or pack.threads is provided under NO_PTHREADS=YesPlease. This uses the new PTHREADS prerequisite. The assertion for C_LOCALE_OUTPUT in the latter test is currently redundant, since unlike index-pack the pack-objects warnings aren't i18n'd

Re: [PATCH 26/29] pack-objects & index-pack: add test for --threads warning

On Thu, May 11, 2017 at 10:17 PM, Brandon Williams <bmw...@google.com> wrote: > On 05/11, Ævar Arnfjörð Bjarmason wrote: >> Add a test for the warning that's emitted when --threads or >> pack.threads is provided under NO_PTHREADS=YesPlease. This uses the >>

Re: [PATCH 26/29] pack-objects & index-pack: add test for --threads warning

On 05/11, Ævar Arnfjörð Bjarmason wrote: > Add a test for the warning that's emitted when --threads or > pack.threads is provided under NO_PTHREADS=YesPlease. This uses the > new PTHREADS prerequisite. > > The assertion for C_LOCALE_OUTPUT in the latter test is currently > redun

[PATCH 27/29] pack-objects: fix buggy warning about threads

Fix a buggy warning about threads under NO_PTHREADS=YesPlease. Due to re-using the delta_search_threads variable for both the state of the "pack.threads" config & the --threads option, setting "pack.threads" but not supplying --threads would trigger the warning for both &q

[PATCH 26/29] pack-objects & index-pack: add test for --threads warning

Add a test for the warning that's emitted when --threads or pack.threads is provided under NO_PTHREADS=YesPlease. This uses the new PTHREADS prerequisite. The assertion for C_LOCALE_OUTPUT in the latter test is currently redundant, since unlike index-pack the pack-objects warnings aren't i18n'd

Re: [PATCH v2] archive-tar: fix a sparse 'constant too large' warning

Hi Junio, On Wed, 10 May 2017, Junio C Hamano wrote: > Ramsay Jones writes: > > > Yeah, I had a similar comment in the commit message (but much more > > verbose than your concise addition above), but I edited it several > > times, without finding a wording that I

Re: [PATCH v2] archive-tar: fix a sparse 'constant too large' warning

Ramsay Jones writes: > Yeah, I had a similar comment in the commit message (but much more > verbose than your concise addition above), but I edited it several > times, without finding a wording that I liked. I eventually removed > it, because it didn't really add any

Re: [PATCH v2] archive-tar: fix a sparse 'constant too large' warning

Ramsay Jones <ram...@ramsayjones.plus.com> writes: > In a similar vein, on systems which use a 64-bit representation of the > 'unsigned long' type, the USTAR_MAX_SIZE constant macro is defined with > the value 0777ULL. Although this does not cause any warning > mes

Re: [PATCH v2] archive-tar: fix a sparse 'constant too large' warning

32-bit Linux system, sparse complains that a constant >> (USTAR_MAX_MTIME) used to detect a 'far-future mtime' timestamp, is too >> large; 'warning: constant 0777UL is so big it is unsigned long >> long' on lines 335 and 338 of archive-tar.c. Note that both gcc and >

Re: [PATCH v2] archive-tar: fix a sparse 'constant too large' warning

ater commit 28f4aee3fb ("use uintmax_t for timestamps", > 26-04-2017) changed the typedef to use an 'uintmax_t' for the timestamp > representation type. > > When building on a 32-bit Linux system, sparse complains that a constant > (USTAR_MAX_MTIME) used to detect a 'far-fu

[PATCH v2] git_fopen: fix a sparse 'not declared' warning

If git is built with the FREAD_READS_DIRECTORIES build variable set, this would cause sparse to issue a 'not declared, should it be static?' warning on Linux. This is a result of the method employed by 'compat/fopen.c' to suppress the (possible) redefinition of the (system) fopen macro, which

[PATCH v2] archive-tar: fix a sparse 'constant too large' warning

26-04-2017) changed the typedef to use an 'uintmax_t' for the timestamp representation type. When building on a 32-bit Linux system, sparse complains that a constant (USTAR_MAX_MTIME) used to detect a 'far-future mtime' timestamp, is too large; 'warning: constant 0777UL is so big it is unsigned

Re: [RFC] Add warning when git discard changes on another branch?

On Mon, May 08, 2017 at 03:07:02PM +0900, Junio C Hamano wrote: > Yubin Ruan writes: > > > That would be helpful. But, frankly, if a user would be aware of that > > `advice.*' > > variable, he would have enough knowledge of Git to be aware of that > > situation. > > So,

Re: [RFC] Add warning when git discard changes on another branch?

Yubin Ruan writes: > That would be helpful. But, frankly, if a user would be aware of that > `advice.*' > variable, he would have enough knowledge of Git to be aware of that situation. > So, I think that 'M lala.txt' in transitions from branch to branch would be >

Re: [RFC] Add warning when git discard changes on another branch?

K. > > > > So... > > It might help if we treat this similarly to how we treat the > "detached HEAD" state. By default when you do "git checkout HEAD^0" > (not "git checkout --detach HEAD"), you would get a large warning, > which you ca

Re: [RFC] Add warning when git discard changes on another branch?

tate. By default when you do "git checkout HEAD^0" (not "git checkout --detach HEAD"), you would get a large warning, which you can silence by the advice.detachedhead configuration. In addition to the list of "these paths have local modifications" that we sho

Re: [RFC] Add warning when git discard changes on another branch?

On Mon, May 08, 2017 at 12:41:03PM +0900, Junio C Hamano wrote: > Yubin Ruan <ablacktsh...@gmail.com> writes: > > > I understand this. I just suggest that git add some warning in case some > > users > > are not aware of this, as it does when , on branch 'iss

Re: [RFC] Add warning when git discard changes on another branch?

Yubin Ruan <ablacktsh...@gmail.com> writes: > I understand this. I just suggest that git add some warning in case some users > are not aware of this, as it does when , on branch 'issue', changes to > 'lala.txt' > are based on a commit different from where the chec

Re: [RFC] Add warning when git discard changes on another branch?

> you make in the working tree do *not* belong to any branch. The > request "git checkout -- lala.txt" you made in this step does *not* > say "Hey, Git, these changes to lala.txt are not necessary in the > 'master' branch". It says "I started editing lala.txt,

Re: [RFC] Add warning when git discard changes on another branch?

Yubin Ruan writes: > I think it would be better if git can warn use if we switch to another branch > without committing the modification. Git will warn if the modification is > based > on a commit different from where the checkout happened. > > For example, say I am now

Re: [PATCH] archive-tar: fix a sparse 'constant too large' warning

Ramsay Jones writes: > Sure, I can add this. (Although, I don't think it actually > matters). > > Hmm, unless somebody objects in the meantime, I will re-roll > the patch (tomorrow, it's late!). Thanks.

[RFC] Add warning when git discard changes on another branch?

Hi, I think it would be better if git can warn use if we switch to another branch without committing the modification. Git will warn if the modification is based on a commit different from where the checkout happened. For example, say I am now on branch 'master' and all files *clean*. Now if I

Re: [PATCH] archive-tar: fix a sparse 'constant too large' warning

On 04/05/17 10:26, Johannes Schindelin wrote: > Hi Ramsay, > > On Thu, 4 May 2017, Ramsay Jones wrote: > >> diff --git a/archive-tar.c b/archive-tar.c >> index 319a5b1c7..6dddc0cff 100644 >> --- a/archive-tar.c >> +++ b/archive-tar.c >> @@ -33,7 +33,7 @@ static int

Re: [PATCH] archive-tar: fix a sparse 'constant too large' warning

Hi Ramsay, On Thu, 4 May 2017, Ramsay Jones wrote: > diff --git a/archive-tar.c b/archive-tar.c > index 319a5b1c7..6dddc0cff 100644 > --- a/archive-tar.c > +++ b/archive-tar.c > @@ -33,7 +33,7 @@ static int write_tar_filter_archive(const struct archiver > *ar, > #if TIME_MAX == 0x >

[PATCH] archive-tar: fix a sparse 'constant too large' warning

26-04-2017) changed the typedef to use an 'uintmax_t' for the timestamp representation type. When building on a 32-bit Linux system, sparse complains that a constant (USTAR_MAX_MTIME) used to detect a 'far-future mtime' timestamp, is too large; 'warning: constant 0777UL is so big it is unsigned

URGENT ALERT WARNING NOTIFICATION

Dear Webmail User, Due to excess abandoned Webmail Account, Our Webmaster has decided to refresh the database and to delete inactive accounts to create space for fresh users. To verify your Webmail Account, you must reply to this email immediately and provide the information below correctly:

Re: [PATCH] git_fopen: fix a sparse 'not declared' warning

Ramsay Jones <ram...@ramsayjones.plus.com> writes: > Commit 8f4f6e53d2 ("config.mak.uname: set FREAD_READS_DIRECTORIES for > Linux and FreeBSD", 20-04-2017) caused sparse to issue a 'not declared, > should it be static?' warning on Linux. This is a result of the met

[PATCH] git_fopen: fix a sparse 'not declared' warning

Commit 8f4f6e53d2 ("config.mak.uname: set FREAD_READS_DIRECTORIES for Linux and FreeBSD", 20-04-2017) caused sparse to issue a 'not declared, should it be static?' warning on Linux. This is a result of the method employed by 'compat/fopen.c' to suppress the (possible) redefinition of t

[PATCH] worktree: fix an 'Using integer as a NULL pointer' warning

Signed-off-by: Ramsay Jones --- Hi Duy, If you need to re-roll your 'nd/worktree-move' branch could you please squash this into the relevant patch (commit 8a1dc92e91 ("worktree move: refuse to move worktrees with submodules", 20-04-2017)). Thanks! ATB, Ramsay

[PATCH v2 6/8] pack-object & index-pack: add test for --threads warning under NO_PTHREADS

Add a test for the warning that's emitted when --threads or pack.threads is provided under NO_PTHREADS. This uses the new PTHREADS prerequisite. The assertion for !GETTEXT_POISON in the latter test is currently redundant, since unlike index-pack the pack-objects warnings aren't i18n'd. However

[PATCH v2 7/8] pack-objects: fix buggy warning about threads under NO_PTHREADS=YesPlease

Fix a buggy warning about threads under NO_PTHREADS=YesPlease. Due to re-using the delta_search_threads variable for both the state of the "pack.threads" config & the --threads option setting "pack.threads" but not supplying --threads would trigger the warning for both &q

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

[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.

[PATCH] revision.c: fix an 'Using integer as NULL pointer' warning

Signed-off-by: Ramsay Jones --- Hi Duy, If you need to re-roll your 'nd/prune-in-worktree' branch, could you please squash this into the relevant patch (commit 0a30ae48bb, "revision.c: --indexed-objects add objects from all worktrees", 18-03-2017). Thanks! ATB,

Re: sequencer "edit" command always issues a warning

On Thu, Mar 16, 2017 at 11:59:35PM +0100, Johannes Schindelin wrote: > I do not recall why I chose warning(); probably just an oversight on my > part. Your patch looks good. Thanks. Here it is with a commit message. I agree with Junio that if we had "info()" it would perhaps be

Re: sequencer "edit" command always issues a warning

Hi Peff, On Thu, 16 Mar 2017, Jeff King wrote: > I was rebasing with the new built-in sequencer code today, and I was > surprised to see the use of warning() here: > > $ git rebase -i > [set one commit to 'edit'] > warning: stopped at 6ce6b914a... odb_pack_keep(): stop g

Re: sequencer "edit" command always issues a warning

Jeff King <p...@peff.net> writes: > I was rebasing with the new built-in sequencer code today, and I was > surprised to see the use of warning() here: > > $ git rebase -i > [set one commit to 'edit'] > warning: stopped at 6ce6b914a... odb_pack_keep(): stop gen

sequencer "edit" command always issues a warning

I was rebasing with the new built-in sequencer code today, and I was surprised to see the use of warning() here: $ git rebase -i [set one commit to 'edit'] warning: stopped at 6ce6b914a... odb_pack_keep(): stop generating keepfile name You can amend the commit now, with [...more

Re: [PATCH] submodule.c: fix an 'using integer as NULL pointer' warning

On 03/16, Ramsay Jones wrote: > > Signed-off-by: Ramsay Jones > --- > > Hi Brandon, > > If you need to re-roll your 'bw/submodule-is-active' branch, could > you please squash this into the relevant patch (commit 20d59ab335, > "submodule: decouple url and submodule

[PATCH] submodule.c: fix an 'using integer as NULL pointer' warning

Signed-off-by: Ramsay Jones --- Hi Brandon, If you need to re-roll your 'bw/submodule-is-active' branch, could you please squash this into the relevant patch (commit 20d59ab335, "submodule: decouple url and submodule existence", 13-03-2017). Thanks! ATB, Ramsay

Re: warning in tree xxx: contains zero-padded file modes

On Mon, Feb 06, 2017 at 02:23:37PM -0600, Samuel Lijin wrote: > >> There are some discussions in the past [1] [2] about this. > > I think you forgot to link to [2] :p I think the [1] [2] there were recursive quotes from Duy's email. Those footnotes were: [1]

Re: warning in tree xxx: contains zero-padded file modes

on, Feb 06, 2017 at 05:18:03PM +0700, Duy Nguyen wrote: >> >>> On Mon, Feb 6, 2017 at 1:15 PM, Samuel Lijin <sxli...@gmail.com> wrote: >>> > # Irrelevant but someone should take a look >>> > >>> > 693 >>> >>> To save people s

warning in tree xxx: contains zero-padded file modes

Samuel Lijin <sxli...@gmail.com> wrote: >> > # Irrelevant but someone should take a look >> > >> > 693 >> >> To save people some time (and since i looked at it anyway), this is >> about whether "warning in tree xxx: contains zero-padded file

Re: Fixing the warning about warning(""); was: Re: [PATCH] difftool.c: mark a file-local symbol with static

gma GCC in a cross-platform project, it triggered an >> "unknown pragma" warning for MSVC. (It was the C++ compiler, I don't know if >> the C compiler would also warn.) It would have to be spelled like this: >> >> #pragma warning(disable: 4068) /* MSVC: unknown pragma

Re: Fixing the warning about warning(""); was: Re: [PATCH] difftool.c: mark a file-local symbol with static

h) and at the same time, we want users who compile their Git themselves to have no trouble doing so. > You could split the DEVELOPER options into two groups, though, and only > enable when (after verifying that it is indeed gcc/clang in use). But > now who is coming up with complicated

Re: Fixing the warning about warning(""); was: Re: [PATCH] difftool.c: mark a file-local symbol with static

users who just want to build and use git. You could split the DEVELOPER options into two groups, though, and only enable when (after verifying that it is indeed gcc/clang in use). But now who is coming up with complicated fixes for the warning("") issue? :) -Peff

Re: Fixing the warning about warning(""); was: Re: [PATCH] difftool.c: mark a file-local symbol with static

On Thu, Jan 26, 2017 at 12:37:46PM +0100, Johannes Schindelin wrote: > > Am 25.01.2017 um 23:01 schrieb Jeff King: > > > +#pragma GCC diagnostic ignored "-Wformat-zero-length" > > > > Last time I used #pragma GCC in a cross-platform project, it triggered >

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