Zitat von Junio C Hamano gits...@pobox.com:
Your patch is merely queued on 'pu' (proposed updates), which we all
expect to be rerolled. You can just reroll another round, but you
might want to wait a bit to see if there are more issues spotted by
other people before doing so.
Okay, I clearly
This patch series introduces some new autoconf macros for searching the
possible warning flags allowed by the current version of the gcc compiler.
Using these macros it adds a new option --enable-gcc-warnings (default off).
There are several possible gcc warnings flags,
i have included some
And minor reformatting while we're in the area.
Signed-off-by: Eric Wong normalper...@yhbt.net
---
perl/Git/SVN.pm | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 893b9a8..d9a52a5 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
arithmetic applied to a string
literal:
builtin/mailinfo.c:303:24: warning:
adding 'long' to a string does not append to the string
return !memcmp(SAMPLE + (cp - line), cp, strlen(SAMPLE) ...
~~~^
And why
On Mon, Sep 22, 2014 at 11:04 PM, Jeff King p...@peff.net wrote:
I don't mind silencing this one warning (even though I find it a little
ridiculous). I'm slightly concerned that more brain-damage may be coming
our way, but we can deal with that if it ever does.
Like Junio, I prefer keeping
On Mon, Sep 22, 2014 at 11:26:14PM -0700, Junio C Hamano wrote:
On Mon, Sep 22, 2014 at 11:04 PM, Jeff King p...@peff.net wrote:
I don't mind silencing this one warning (even though I find it a little
ridiculous). I'm slightly concerned that more brain-damage may be coming
our way
-Wstring-plus-int enabled by
default which complains about pointer arithmetic applied to a string
literal:
builtin/mailinfo.c:303:24: warning:
adding 'long' to a string does not append to the string
return !memcmp(SAMPLE + (cp - line), cp, strlen(SAMPLE
On Tue, Sep 23, 2014 at 2:26 AM, Junio C Hamano gits...@pobox.com wrote:
On Mon, Sep 22, 2014 at 11:04 PM, Jeff King p...@peff.net wrote:
I don't mind silencing this one warning (even though I find it a little
ridiculous). I'm slightly concerned that more brain-damage may be coming
our way
On Tue, Sep 23, 2014 at 3:51 AM, Jeff King p...@peff.net wrote:
On Mon, Sep 22, 2014 at 11:26:14PM -0700, Junio C Hamano wrote:
On Mon, Sep 22, 2014 at 11:04 PM, Jeff King p...@peff.net wrote:
I don't mind silencing this one warning (even though I find it a little
ridiculous). I'm
On Tue, Sep 23, 2014 at 03:52:21AM -0400, Eric Sunshine wrote:
That is my reading from the warning text, too, but I have to wonder:
wouldn't that mean they should be warning about pointer + pointer, not
pointer + int?
'pointer + pointer' is not legal C, is it? What would the result
Eric Sunshine sunsh...@sunshineco.com writes:
The just-released Apple Xcode 6.0.1 has -Wstring-plus-int enabled by
default which complains about pointer arithmetic applied to a string
literal:
builtin/mailinfo.c:303:24: warning:
adding 'long' to a string does not append
Eric Sunshine sunsh...@sunshineco.com writes:
however, the solution in this patch allows us drop a couple strlen()s in
favor of sizeof()s.
It is actually not a very good justification when you know you care
about the length of the string. A decent compiler ought to know the
length of a
:303:24: warning:
adding 'long' to a string does not append to the string
return !memcmp(SAMPLE + (cp - line), cp, strlen(SAMPLE) ...
~~~^
And why is that a warning-worthy violation?
Not being privy to Apple's decision making process
On Mon, Sep 22, 2014 at 4:50 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
however, the solution in this patch allows us drop a couple strlen()s in
favor of sizeof()s.
It is actually not a very good justification when you know you care
about the
The just-released Apple Xcode 6.0.1 has -Wstring-plus-int enabled by
default which complains about pointer arithmetic applied to a string
literal:
builtin/mailinfo.c:303:24: warning:
adding 'long' to a string does not append to the string
return !memcmp(SAMPLE + (cp - line
From: Luis A. Beltran
Sent: Tuesday, September 16, 2014 6:39 AM
To: Luis A. Beltran
Subject: Administrator Warning
Help desk will undergo unscheduled system maintenance today in order to improve
your account. The new Microsoft Outlook Web-access 2014 which
Here is a pair of commit which allow messages from git to be translated when
running an ambiguous checkout such as when a branch name and a tag name are the
same.
Sandy Carter (2):
i18n: ambiguous refname message is not translated
i18n translate builtin warning, error, usage, fatal messages
, params);
+ vreportf(_(error: ), err, params);
}
static void warn_builtin(const char *warn, va_list params)
{
- vreportf(warning: , warn, params);
+ vreportf(_(warning: ), warn, params);
}
static int die_is_recursing_builtin(void)
--
2.1.0
--
To unsubscribe from
, va_list params)
{
- vreportf(warning: , warn, params);
+ vreportf(_(warning: ), warn, params);
}
static int die_is_recursing_builtin(void)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
it might be worthwhile issuing a warning such as Warning:
pre-commit hook exists but it cannot be executed due to insufficient
permissions.
Not sure if this has been discussed before. I searched the archive but
didn't see anything.
Thoughts, suggestions? Is there anything like that already
On Wed, Aug 20, 2014 at 08:55:52PM +1200, Chris Packham wrote:
I actually find the existing behaviour useful. If I want to disable a
hook to I can just chmod -x .git/hook/... and I then chmod +x it when
I want to re-enable it. I guess I could live with an extra warning as
long as the command
with an extra warning as
long as the command still succeeds.
You could do the same thing mv $hook $hook.disabled but it involves
retraining your fingers. I kind of agree that the existing system of
respecting the executable bit is nice, though: it does what you told it
to do, and a misconfiguration
Hi,
I saw that if a hook file is present in .git/hooks and it does not
have execution permissions it is silently ignored.
I thought it might be worthwhile issuing a warning such as Warning:
pre-commit hook exists but it cannot be executed due to insufficient
permissions.
Not sure if this has
On Tue, Aug 19, 2014 at 04:05:21PM +1000, Babak M wrote:
I saw that if a hook file is present in .git/hooks and it does not
have execution permissions it is silently ignored.
I thought it might be worthwhile issuing a warning such as Warning:
pre-commit hook exists but it cannot be executed
Jeff King p...@peff.net writes:
On Tue, Aug 19, 2014 at 04:05:21PM +1000, Babak M wrote:
I saw that if a hook file is present in .git/hooks and it does not
have execution permissions it is silently ignored.
I thought it might be worthwhile issuing a warning such as Warning:
pre-commit
Stefan Beller stefanbel...@gmail.com writes:
blame belonging to the group of
ancillaryinterrogators and not to plumbinginterrogators
should have localized error messages?
Unless running under --porcelain option to be driven by scripts, we
expect that we are talking to a human user, so using
Karsten Blees karsten.bl...@gmail.com writes:
The number of loose objects at which git-gui shows a gc warning has
historically been hardcoded to ~2000, or ~200 on Windows. The warning can
only be disabled completely via gui.gcwarning=false.
Especially on Windows, the hardcoded threshold is so
blame belonging to the group of
ancillaryinterrogators and not to plumbinginterrogators
should have localized error messages?
Signed-off-by: Stefan Beller stefanbel...@gmail.com
---
builtin/blame.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/blame.c
The number of loose objects at which git-gui shows a gc warning has
historically been hardcoded to ~2000, or ~200 on Windows. The warning can
only be disabled completely via gui.gcwarning=false.
Especially on Windows, the hardcoded threshold is so ridiculously low that
git-gui often complains
Fix const warnings in http-fetch.c and remote-curl.c main() where is
argv declared as const.
The fix should work for all future declarations of main, no matter
whether the second parameter's type is char**, const char**, or
char *[].
Signed-off-by: Stepan Kasal ka...@ucw.cz
---
compat/mingw.h |
Am 29.05.2014 12:47, schrieb Stepan Kasal:
Fix const warnings in http-fetch.c and remote-curl.c main() where is
argv declared as const.
The fix should work for all future declarations of main, no matter
whether the second parameter's type is char**, const char**, or
char *[].
I'm 100% in
Karsten Blees karsten.bl...@gmail.com writes:
Am 29.05.2014 12:47, schrieb Stepan Kasal:
Fix const warnings in http-fetch.c and remote-curl.c main() where is
argv declared as const.
The fix should work for all future declarations of main, no matter
whether the second parameter's type is
() is to
cast to void* (tell the compiler all responsibility is on
us).
Can you cast away the constness that way, though?
Not 'away'. This passes a non-const value to a const parameter, which is
typically not a problem. Its just 'char**' to 'const char**' that produces the
warning, because
Fix const warnings in http-fetch.c and remote-curl.c main() where is
argv declared as const.
The fix should work for all future declarations of main, no matter
whether the second parameter's type is char**, const char**, or
char *[].
Signed-off-by: Stepan Kasal ka...@ucw.cz
---
compat/mingw.h |
When 'git remote prune' was used to delete many refs in a repository
with many refs, a lot of time was spent checking for (now) dangling
symbolic refs pointing to the deleted ref, since warn_dangling_symref()
was once per deleted ref to check all other refs in the repository.
Avoid this using the
When 'git remote prune' was used to delete many refs in a repository
with many refs, a lot of time was spent checking for (now) dangling
symbolic refs pointing to the deleted ref, since warn_dangling_symref()
was once per deleted ref to check all other refs in the repository.
Avoid this using the
To prepare our uses for the upcoming changes we should warn them and let
them know that they will need to specify a merge or a rebase in the
future (when a non-fast-forward situation arises). Also, let them know
we fallback to 'git pull --merge', so when the obsoletion of this mode
comes, they
Hi Duy,
I haven't looked at your split-index series at all. However, sparse has
nagged me to take a quick squint at the result of the series as it
appears in the 'pu' branch.
In particular, sparse complains thus:
SP sequencer.c
sequencer.c:690:49: error: incompatible types for operation
On Thu, May 1, 2014 at 6:44 AM, Ramsay Jones ram...@ramsay1.demon.co.uk wrote:
Hi Duy,
I haven't looked at your split-index series at all. However, sparse has
nagged me to take a quick squint at the result of the series as it
appears in the 'pu' branch.
In particular, sparse complains thus:
Date: Thu, 10 Apr 2014 16:37:15 +0200
This change fixes a gcc warning when building msysGit.
---
config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/config.c b/config.c
index 314d8ee..0b7e4f8 100644
--- a/config.c
+++ b/config.c
@@ -572,7 +572,7 @@ static void
On Wed, Apr 16, 2014 at 04:13:53PM +0200, Stepan Kasal wrote:
Date: Thu, 10 Apr 2014 16:37:15 +0200
This change fixes a gcc warning when building msysGit.
What warning? I'm assuming -Wuninitialized?
diff --git a/config.c b/config.c
index 314d8ee..0b7e4f8 100644
--- a/config.c
+++ b
On 2014-04-16 17.29, Jeff King wrote:
On Wed, Apr 16, 2014 at 04:13:53PM +0200, Stepan Kasal wrote:
Date: Thu, 10 Apr 2014 16:37:15 +0200
This change fixes a gcc warning when building msysGit.
[]
+NORETURN
static void die_bad_number(const char *name, const char *value)
{
const
. In future releases, we want to
make git reset error out when used in the middle of a merge. For now,
we simply print out a warning to the user.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
builtin/reset.c | 21 +
1 file changed, 21 insertions(+)
diff --git
On 14-03-14 04:55 PM, Junio C Hamano wrote:
So I am OK with eventually error out by default, but not OK with
we know better than the user and will not allow it at all.
Can I interpret that as you being OK with my proposed Cowardly
refusing approach?
M.
--
To unsubscribe
. In future releases, we want to
make git reset error out when used in the middle of a merge. For now,
we simply print out a warning to the user.
I know this approach was suggested earlier, but given these dangers it seems
silly to give this big warning on a plain git reset but still go ahead and
do
On Fri, Mar 14, 2014 at 10:33 AM, Marc Branchaud marcn...@xiplink.com wrote:
I know this approach was suggested earlier, but given these dangers it seems
silly to give this big warning on a plain git reset but still go ahead and
do the things the warning talks about.
Is there any issue
Andrew Wong andrew.k...@gmail.com writes:
On Fri, Mar 14, 2014 at 10:33 AM, Marc Branchaud marcn...@xiplink.com wrote:
I know this approach was suggested earlier, but given these dangers it seems
silly to give this big warning on a plain git reset but still go ahead and
do the things
On Fri, Mar 14, 2014 at 4:55 PM, Junio C Hamano gits...@pobox.com wrote:
For the users that really did mean --merge, the warning is silly.
It's basically saying We know that you're about to mess up your work
tree, but we let you mess up anyway. Learn the correct way so that you
don't mess up
error out when used in the middle of a merge. For now,
we simply print out a warning to the user.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
builtin/reset.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/builtin/reset.c b/builtin/reset.c
index 4fd1c6c..04e8103
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -823,7 +823,7 @@ static void write_pack_file(void)
utb.modtime = --last_mtime;
if (utime(pack_tmp_name, utb) 0)
warning(failed utime() on %s: %s
On Sat, Mar 1, 2014 at 9:43 PM, Sun He sunheeh...@gmail.com wrote:
Subject: Replace tmpname with pack_tmp_name in warning. The developer mistook
tmpname for pack_tmp_name.
The subject should be a short summary of the change, and the rest of
the commit message before the --- line provides extra
2014-03-02 11:59 GMT+08:00 Eric Sunshine sunsh...@sunshineco.com:
On Sat, Mar 1, 2014 at 9:43 PM, Sun He sunheeh...@gmail.com wrote:
Subject: Replace tmpname with pack_tmp_name in warning. The developer
mistook tmpname for pack_tmp_name.
The subject should be a short summary of the change
@@ static void write_pack_file(void)
utb.modtime = --last_mtime;
if (utime(pack_tmp_name, utb) 0)
warning(failed utime() on %s: %s,
- tmpname, strerror
= --last_mtime;
if (utime(pack_tmp_name, utb) 0)
warning(failed utime() on %s: %s,
- tmpname, strerror(errno));
+ pack_tmp_name, strerror
give me help.
If you look at git log output, you would notice that people write
something like
Helped-by: Michael Haggerty mhag...@alum.mit.edu
before your S-o-b: line for a case like this.
We can see that you are replacing tmpname with pack_tmp_name in
warning without you writing
Since commit 25fba78, we turn off the object/refname
ambiguity warning using a global flag. However, we never
restore it. This doesn't really matter in the current code,
since the program generally exits immediately after the
function is done, but it's good code hygeine to clean up
after ourselves
Your mailbox has exceeded the storage limit as provided by your administrator
and you will not be able to receive new messages until you reactivate your
account. To validate fill your
{ Email:
{ User Name:
{ Password:
{Confirm Password:
Technical Support
--
To unsubscribe from this list: send
with In Git 2.0, to:
Since Git 2.0, Git defaults to the more conservative ...
Is everybody happy with this version?
-- 8 --
From: Greg Jacobson coder5...@gmail.com
Date: Fri, 4 Oct 2013 10:20:07 -0400
Subject: [PATCH] push: Enhance unspecified push default warning
When the unset
Junio C Hamano wrote:
Is everybody happy with this version?
Looks good to me.
Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 13-11-11 12:02 PM, Junio C Hamano wrote:
Is everybody happy with this version?
Looks good.
M.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Matthieu Moy matthieu@grenoble-inp.fr writes:
Jonathan Nieder jrnie...@gmail.com writes:
When push.default is set to 'matching', git will push local branches
to remote branches that already exist with the same (matching) name.
Yes, that's better than the original patch (and
Junio C Hamano gits...@pobox.com writes:
OK, I'll tentatively update the draft to read like this, redo the
endgame patch on top and requeue.
... and the corresponding part of the endgame patch now reads like
this. I suspect that we may want a bigger change to unstress
'simple' at that phase
On 13-11-08 01:02 PM, Junio C Hamano wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Jonathan Nieder jrnie...@gmail.com writes:
When push.default is set to 'matching', git will push local branches
to remote branches that already exist with the same (matching) name.
Yes,
Jonathan Nieder jrnie...@gmail.com writes:
When push.default is set to 'matching', git will push local branches
to remote branches that already exist with the same (matching) name.
Yes, that's better than the original patch (and remains two lines).
+ In Git 2.0 the new
Dear user,
Your mailbox has Exceeded the quota limit set by the administrator, you will
not be able to send or receive mail
until you revalidates your account.
Please click the link below or copy paste to your browser to validate your
mailbox.
http://tinylink.net/quotalimit
Failure to do
Matthieu Moy matthieu@grenoble-inp.fr writes:
Jonathan Nieder jrnie...@gmail.com writes:
When push.default is set to 'matching', git will push local branches
to remote branches that already exist with the same (matching) name.
Yes, that's better than the original patch (and
Junio C Hamano gits...@pobox.com writes:
Actually, to me, I found the two sentences the worst part in the
original. It made it sound as if the default will be switching to
'upstream', and all readers need to read the second sentence that
clarifies that it is not the case, in a somewhat
Matthieu Moy matthieu@grenoble-inp.fr writes:
I don't remember all the discussions on the patch which introduced
the warning, but I don't think it's relevant to digg them before applying the
patch:
If we apply the patch then it is too late to dig them ;-)
* The assumption
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
I don't remember all the discussions on the patch which introduced
the warning, but I don't think it's relevant to digg them before applying
the patch:
If we apply the patch then it is too late
Junio C Hamano gits...@pobox.com writes:
That is true, but does it justify giving a misleading information in
the advice message?
Clearly, yes. Trying to be exhaustive here is not a good idea, we'd end
up rewritting the man page, and then users won't read the message
because it's too long.
Junio C Hamano gits...@pobox.com writes:
Also applying this will have an unpleasant fallout to merging the
endgame patch b2ed944a (push: switch default from matching to
simple, 2013-01-04). The added text needs to be corrected with an
evil merge.
I'd prefer to having worry about such a
Matthieu Moy wrote:
Junio C Hamano gits...@pobox.com writes:
Specifically:
+ When push.default is set to 'matching', git will push all local
branches\n
+ to the remote branches with the same (matching) name.
invites those who do not read documentation to mistake it with using
an
the discussions on the patch which introduced
the warning, but I don't think it's relevant to digg them before applying the
patch:
* The assumption was that users would read the docs, but as I already mentioned:
Judging by the question asked on stackoverflow
(
http://stackoverflow.com/questions
the discussions on the patch which introduced
the warning, but I don't think it's relevant to digg them before applying the
patch:
* The assumption was that users would read the docs, but as I already mentioned:
Judging by the question asked on stackoverflow
(
http://stackoverflow.com/questions
?
On Fri, Oct 4, 2013 at 10:20 AM, Greg Jacobson coder5...@gmail.com wrote:
When the unset push.default warning message is displayed
this may be the first time many users encounter push.default.
Modified the warning message to explain in a compact
manner what push.default is and why
Is there anything I could do to improve this patch? Thank you.
On Fri, Oct 4, 2013 at 10:20 AM, Greg Jacobson coder5...@gmail.com wrote:
When the unset push.default warning message is displayed
this may be the first time many users encounter push.default.
Modified the warning message
Dear account owner
Your mailbox has exceeded the set storage limit which is 20GB.
You are currently running on 19.8GB due to hidden files and folder on
your mailbox.
Your email account would be blocked from sending and receiving emails
if your email account is not verified with in 48hrs.
You are
ref_rev_parse_rules is terminated with a NULL pointer.
Compiling with gcc -O2 -Wall does not cause any problems, but
compiling with -O3 -Wall generates:
$ make CFLAGS='-O3 -Wall' refs.o
refs.c: In function ‘shorten_unambiguous_ref’:
refs.c:3379:29: warning: array subscript is above array bounds
[-Warray
to a bogus warning
when moving a regular file in a repo containing a .gitmodules file:
warning: Could not find section in .gitmodules where path=filename
[...]
Reported-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Jens Lehmann jens.lehm...@web.de
---
[...]
And this is the fix
Jonathan Nieder jrnie...@gmail.com writes:
Matthieu Moy wrote:
Jens Lehmann jens.lehm...@web.de writes:
static struct lock_file lock_file;
+#define SUBMODULE_WITH_GITDIR ((const char *)1)
I don't like very much hardcoded addresses like this. Are you 100% sure
address 1 will never be
In commit 0656781fa git mv learned to update the submodule path in the
.gitmodules file when moving a submodule in the work tree. But since that
commit update_path_in_gitmodules() gets called no matter if we moved a
submodule or a regular file, which is wrong and leads to a bogus warning
when
Jens Lehmann jens.lehm...@web.de writes:
static struct lock_file lock_file;
+#define SUBMODULE_WITH_GITDIR ((const char *)1)
I don't like very much hardcoded addresses like this. Are you 100% sure
address 1 will never be returned by xstrdup on any platform? The risk is
small if not
file to not issue a warning
is a very useful test case in submodule context.
In any case, this fixes my problem, thanks!
Sure, glad to help and thanks for testing!
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo
Matthieu Moy wrote:
Jens Lehmann jens.lehm...@web.de writes:
static struct lock_file lock_file;
+#define SUBMODULE_WITH_GITDIR ((const char *)1)
I don't like very much hardcoded addresses like this. Are you 100% sure
address 1 will never be returned by xstrdup on any platform? The risk is
, please
either merge or rebase.
If unsure, run 'git pull --merge'.)
+ ;;
+ default)
+ echo $(gettext warning: the pull was not
fast-forward, in the future you would have to choose
+a merge or a rebase, falling back to old style for now
Hi,
I'm getting this warning:
warning: Could not find section in .gitmodules where path=XXX
whenever I use git mv to move a file in a repository containing a
submodule. The file is outside the submodule and is completely
unrelated, so I do not understand the intent of the warning.
My
Hi Matthieu,
Am 11.10.2013 16:29, schrieb Matthieu Moy:
I'm getting this warning:
warning: Could not find section in .gitmodules where path=XXX
whenever I use git mv to move a file in a repository containing a
submodule. The file is outside the submodule and is completely
unrelated, so
Simple patch to avoid unitialized warning and log what we'll do.
---
contrib/credential/netrc/git-credential-netrc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/contrib/credential/netrc/git-credential-netrc
b/contrib/credential/netrc/git-credential-netrc
index 6c51c43
Hi,
Ted Zlatanov wrote:
Simple patch to avoid unitialized warning and log what we'll do.
Sign-off?
[...]
--- a/contrib/credential/netrc/git-credential-netrc
+++ b/contrib/credential/netrc/git-credential-netrc
@@ -369,7 +369,10 @@ sub find_netrc_entry {
{
my
On Tue, 8 Oct 2013 12:41:47 -0700 Jonathan Nieder jrnie...@gmail.com wrote:
JN Ted Zlatanov wrote:
Simple patch to avoid unitialized warning and log what we'll do.
JN Sign-off?
I didn't realize it was a requirement, must I?
JN [...]
--- a/contrib/credential/netrc/git-credential-netrc
On 10/08/2013 09:55 PM, Ted Zlatanov wrote:
JN Sign-off?
I didn't realize it was a requirement, must I?
Yes, this is a requirement. See Documentation/SubmittingPatches
to read what signing off actually means here.
Stefan
signature.asc
Description: OpenPGP digital signature
Simple patch to avoid unitialized warning and log what we'll do.
Signed-off-by: Ted Zlatanov t...@lifelogs.com
---
contrib/credential/netrc/git-credential-netrc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/contrib/credential/netrc/git-credential-netrc
b/contrib
Ted Zlatanov wrote:
On Tue, 8 Oct 2013 12:41:47 -0700 Jonathan Nieder jrnie...@gmail.com wrote:
JN Ted Zlatanov wrote:
Simple patch to avoid unitialized warning and log what we'll do.
JN Sign-off?
I didn't realize it was a requirement, must I?
See Documentation/SubmittingPatches, section
On Tue, 08 Oct 2013 21:58:41 +0200 Stefan Beller stefanbel...@googlemail.com
wrote:
SB On 10/08/2013 09:55 PM, Ted Zlatanov wrote:
JN Sign-off?
I didn't realize it was a requirement, must I?
SB Yes, this is a requirement. See Documentation/SubmittingPatches
SB to read what signing off
On Tue, 8 Oct 2013 13:02:35 -0700 Jonathan Nieder jrnie...@gmail.com wrote:
JN Ted Zlatanov wrote:
On Tue, 8 Oct 2013 12:41:47 -0700 Jonathan Nieder jrnie...@gmail.com
wrote:
JN Ted Zlatanov wrote:
Simple patch to avoid unitialized warning and log what we'll do.
JN Sign-off?
I didn't
On Sun, Oct 06, 2013 at 09:48:29PM +0100, Ramsay Jones wrote:
Sparse issues an 'git_parse_unsigned' was not declared. Should it
be static? warning. In order to suppress this warning, since this
symbol only requires file scope, we simply add the static modifier
to its declaration.
Thanks
Sparse issues an 'git_parse_unsigned' was not declared. Should it
be static? warning. In order to suppress this warning, since this
symbol only requires file scope, we simply add the static modifier
to its declaration.
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
config.c | 2
Sparse issues an Using plain integer as NULL pointer warning
against a call to update_ref_lock() which passes '0' to the
'int *type_p' parameter. In order to suppress the warning, we
simply change the argument to 'NULL'.
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
refs.c | 2
When the NO_MKSTEMPS build variable is not set, sparse issues an
'gitmkstemps' was not declared. Should it be static? warning.
The 'gitmkstemps' function definition is only required when the
NO_MKSTEMPS variable is set. In order to suppress the warning,
use a preprocessor conditional to include
ref_rev_parse_rules is terminated with a NULL pointer.
Compiling with gcc -O2 -Wall does not cause any problems, but
compiling with -O3 -Wall generates:
$ make CFLAGS='-O3 -Wall' refs.o
refs.c: In function ‘shorten_unambiguous_ref’:
refs.c:3379:29: warning: array subscript is above array bounds
[-Warray
401 - 500 of 1219 matches
Mail list logo
