* Git wiki down?
From: suvayu ali @ 2011-09-11 11:56 UTC (permalink / raw)
To: git
Is something wrong with the git wiki?
$ ping http://git.wiki.kernel.org/
ping: unknown host http://git.wiki.kernel.org/
On the browser I get redirected to the OpenDNS page when there is a
DNS problem for some site. The OpenDNS cache also says there is no
such site. Was the git wiki affected in the recent DNS hack?
--
Suvayu
Open source is the future. It sets us free.
^ permalink raw reply
* Re: Git wiki down?
From: Carlos Martín Nieto @ 2011-09-11 11:59 UTC (permalink / raw)
To: suvayu ali; +Cc: git
In-Reply-To: <CAMXnza1fwgup_YbbrvM7egpZnaUBBV935x4ib72MO=TmvHS3Bg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 519 bytes --]
On Sun, 2011-09-11 at 13:56 +0200, suvayu ali wrote:
> Is something wrong with the git wiki?
>
> $ ping http://git.wiki.kernel.org/
> ping: unknown host http://git.wiki.kernel.org/
>
> On the browser I get redirected to the OpenDNS page when there is a
> DNS problem for some site. The OpenDNS cache also says there is no
> such site. Was the git wiki affected in the recent DNS hack?
The kernel.org site and associated services are down for maintenance, as
it says on the main web page.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Git wiki down?
From: Suvayu Ali @ 2011-09-11 12:14 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <1315742361.4370.0.camel@centaur.lab.cmartin.tk>
On Sun, 11 Sep 2011 13:59:12 +0200
Carlos Martín Nieto <cmn@elego.de> wrote:
> The kernel.org site and associated services are down for maintenance,
> as it says on the main web page.
>
Thanks a lot Carlos. Sorry for not checking thoroughly.
> cmn
--
Suvayu
Open source is the future. It sets us free.
^ permalink raw reply
* [PATCH] SubmittingPathces: remove Cogito reference
From: Sverre Rabbelier @ 2011-09-11 12:38 UTC (permalink / raw)
To: Junio C Hamano, Git List; +Cc: Sverre Rabbelier
Removing Cogito leaves just git and StGit, which is a rather
incomplete list of git diff tools available. Sidestep the problem
of deciding what tools to mention by not mentioning any.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
Reading `git log -p --reverse Documentation/SubmittingPatches` [0]
I noticed the Cogito reference was never removed. In the light of
the recent discussion about removing Cogito from the GitSurvey I
figured now might be a good time to remove this reference as well.
[0] https://plus.google.com/115991361267198418069/posts/NPa7vQYeMnm
Documentation/SubmittingPatches | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 938eccf..0dbf2c9 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -134,8 +134,7 @@ Another thing: NULL pointers shall be written as NULL, not as 0.
(2) Generate your patch using git tools out of your commits.
-git based diff tools (git, Cogito, and StGIT included) generate
-unidiff which is the preferred format.
+git based diff tools generate unidiff which is the preferred format.
You do not have to be afraid to use -M option to "git diff" or
"git format-patch", if your patch involves file renames. The
--
1.7.6.1.724.g9519c
^ permalink raw reply related
* Re: "git archive" seems to be broken wrt zip files
From: Andreas Schwab @ 2011-09-11 13:14 UTC (permalink / raw)
To: Jeff King
Cc: Linus Torvalds, René Scharfe, Junio C Hamano,
Git Mailing List
In-Reply-To: <20110911062740.GA8018@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> IOW, the zip file looks right. I wonder if this is actually a bug in
> "unzip".
It is. This only happens if you have more then 16k entries and when one
of the 16k entry infos is reused it happend to be previously used for a
symlink entry.
Here's a patch for unzip60 for reference:
--- process.c
+++ process.c
@@ -1751,6 +1751,12 @@ int process_cdir_file_hdr(__G) /* ret
= (G.crec.general_purpose_bit_flag & (1 << 11)) == (1 << 11);
#endif
+#ifdef SYMLINKS
+ /* Initialize the symlink flag, may be set by the platform-specific
+ mapattr function. */
+ G.pInfo->symlink = 0;
+#endif
+
return PK_COOL;
} /* end function process_cdir_file_hdr() */
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: "git archive" seems to be broken wrt zip files
From: René Scharfe @ 2011-09-11 15:38 UTC (permalink / raw)
To: Andreas Schwab
Cc: Jeff King, Linus Torvalds, Junio C Hamano, Git Mailing List
In-Reply-To: <m239g3i5kz.fsf@igel.home>
Am 11.09.2011 15:14, schrieb Andreas Schwab:
> Jeff King <peff@peff.net> writes:
>
>> IOW, the zip file looks right. I wonder if this is actually a bug in
>> "unzip".
>
> It is. This only happens if you have more then 16k entries and when one
> of the 16k entry infos is reused it happend to be previously used for a
> symlink entry.
>
> Here's a patch for unzip60 for reference:
Oh, thanks, now I can stop scratching my head while trying to find my
way around unzip's source and its amazing OS compatibility code.
On Windows (the main target for ZIP file support in git archive), 7-Zip,
the unzip from msysgit and the native ZIP support extract the archive
without any issues (except for 13 files whose names only differ
upper/lower case of some chars to 13 other files), by the way. Since
they lack symlink support, the target path of
arch/microblaze/boot/dts/system.dts is simply written to a regular file,
though.
René
^ permalink raw reply
* [PATCH] Support empty blob in fsck --lost-found
From: BJ Hargrave @ 2011-09-11 15:40 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
fsck --lost-found died when attempting to write out the empty blob.
Avoid calling fwrite when the blob size is zero since the call to
fwrite returns 0 objects written which fails the check and caused
fsck to die.
Signed-off-by: BJ Hargrave <bj@bjhargrave.com>
---
builtin/fsck.c | 7 ++++---
t/t1420-lost-found.sh | 13 ++++++++-----
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/builtin/fsck.c b/builtin/fsck.c
index 5ae0366..ad6d713 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -232,9 +232,10 @@ static void check_unreachable_object(struct object *obj)
char *buf = read_sha1_file(obj->sha1,
&type, &size);
if (buf) {
- if (fwrite(buf, size, 1, f) != 1)
- die_errno("Could not write '%s'",
- filename);
+ if (size > 0)
+ if (fwrite(buf, size, 1, f) != 1)
+ die_errno("Could not write '%s'",
+ filename);
free(buf);
}
} else
diff --git a/t/t1420-lost-found.sh b/t/t1420-lost-found.sh
index dc9e402..02323c9 100755
--- a/t/t1420-lost-found.sh
+++ b/t/t1420-lost-found.sh
@@ -8,7 +8,7 @@ test_description='Test fsck --lost-found'
test_expect_success setup '
git config core.logAllRefUpdates 0 &&
- : > file1 &&
+ echo x > file1 &&
git add file1 &&
test_tick &&
git commit -m initial &&
@@ -18,18 +18,21 @@ test_expect_success setup '
test_tick &&
git commit -m second &&
echo 3 > file3 &&
- git add file3
+ : > file4 &&
+ git add file3 file4
'
test_expect_success 'lost and found something' '
git rev-parse HEAD > lost-commit &&
- git rev-parse :file3 > lost-other &&
+ git rev-parse :file3 > lost-other3 &&
+ git rev-parse :file4 > lost-other4 &&
test_tick &&
git reset --hard HEAD^ &&
git fsck --lost-found &&
- test 2 = $(ls .git/lost-found/*/* | wc -l) &&
+ test 3 = $(ls .git/lost-found/*/* | wc -l) &&
test -f .git/lost-found/commit/$(cat lost-commit) &&
- test -f .git/lost-found/other/$(cat lost-other)
+ test -f .git/lost-found/other/$(cat lost-other3) &&
+ test -f .git/lost-found/other/$(cat lost-other4)
'
test_done
--
1.7.6.2
^ permalink raw reply related
* Re: [PATCH v3 0/4] Signed push
From: Ted Ts'o @ 2011-09-11 15:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, git, Jeff King, Shawn O. Pearce
In-Reply-To: <7v4o0jq2fx.fsf@alter.siamese.dyndns.org>
On Sat, Sep 10, 2011 at 06:42:58PM -0700, Junio C Hamano wrote:
> Perhaps we shouldn't worry about tag namespace contamination to make
> things easier and simpler and stop using notes tree?
With the appropriate conventions, such as using a tag name such as
signed-<email>-<timestamp>" we can at least avoid name conflicts, at
least for all practical purposes.
There is the additional problem that "git tag -l" gets painful. At
least for me, though, it's already mostly useless:
% git tag -l | grep ^v[23] | wc -l
858
I can work around this with git aliases that filter out certain
prefixes that I normally don't care about, but maybe that's something
that should be directly supported in git-tag with some git-config
parameters.
The final issue that I'd worry about with using tags is performance.
If we have hundreds of thousands or millions of tags of the form
signed-<email>-<timestamp>, is this going to be a problem? This does
seem like something that could be worked around --- in the worst case
there could just be a locally maintained reverse index from git commit
id's to tag names. (Although as I recall Linus objected to having
something like this for time skews, so maybe he'd object to this too.)
- Ted
^ permalink raw reply
* Re: [PATCH] Support empty blob in fsck --lost-found
From: Sverre Rabbelier @ 2011-09-11 16:03 UTC (permalink / raw)
To: BJ Hargrave; +Cc: git, Junio C Hamano
In-Reply-To: <A3964281-B24B-46C0-AE73-0CCB4C12556F@bjhargrave.com>
Heya,
On Sun, Sep 11, 2011 at 17:40, BJ Hargrave <bj@bjhargrave.com> wrote:
> fsck --lost-found died when attempting to write out the empty blob.
> Avoid calling fwrite when the blob size is zero since the call to
> fwrite returns 0 objects written which fails the check and caused
> fsck to die.
Now we don't die at all if a 0-byte file couldn't be written.
Shouldn't we check errno or something?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Support empty blob in fsck --lost-found
From: BJ Hargrave @ 2011-09-11 16:20 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git, Junio C Hamano
In-Reply-To: <CAGdFq_hqfqdFyLY=KdA_QW5kH8Kjhx8Y18mHEga_Pdv8yzB2wg@mail.gmail.com>
On Sep 11, 2011, at 12:03 , Sverre Rabbelier wrote:
> Heya,
>
> On Sun, Sep 11, 2011 at 17:40, BJ Hargrave <bj@bjhargrave.com> wrote:
>> fsck --lost-found died when attempting to write out the empty blob.
>> Avoid calling fwrite when the blob size is zero since the call to
>> fwrite returns 0 objects written which fails the check and caused
>> fsck to die.
>
> Now we don't die at all if a 0-byte file couldn't be written.
> Shouldn't we check errno or something?
>
You don't need to write anything to the 0-byte file. Just create it and close it and there are checks already that verify the fopen and fclose do not fail. So I don't think we are missing any error conditions here.
> --
> Cheers,
>
> Sverre Rabbelier
--
BJ Hargrave
^ permalink raw reply
* Re: [PATCH] Support empty blob in fsck --lost-found
From: Sverre Rabbelier @ 2011-09-11 16:21 UTC (permalink / raw)
To: BJ Hargrave; +Cc: git, Junio C Hamano
In-Reply-To: <E6A02216-CA67-4B66-AA8F-6DDE8AF7DF3A@bjhargrave.com>
Heya,
On Sun, Sep 11, 2011 at 18:20, BJ Hargrave <bj@bjhargrave.com> wrote:
> You don't need to write anything to the 0-byte file. Just create it and
> close it and there are checks already that verify the fopen and fclose
> do not fail. So I don't think we are missing any error conditions here.
Works for me :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* How do I investigate apparently random git clone reports of "error: File ... has bad hash"?
From: Thorkil Naur @ 2011-09-11 19:03 UTC (permalink / raw)
To: git
Hello,
On a Mac OS X 10.5.8 with
> $ uname -a
> Darwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0:
Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
> $ git --version
> git version 1.7.4.1
> $
that I use as a so-called buildbot slave (http://trac.buildbot.net/) for GHC
(http://www.haskell.org/ghc/), git clone is used repeatedly to fetch the main
repository and several other (library) repositories on which the main repository
depends. In recent months, I have experienced apparently random failures in
which git clone reports, for example:
> $ git clone http://darcs.haskell.org/ghc.git/ build8
> Cloning into build8...
> error: File 42988feeeb76f5cb92b541e9dac277e073bcb3ef has bad hash
> error: Unable to find 42988feeeb76f5cb92b541e9dac277e073bcb3ef under
http://darcs.haskell.org/ghc.git
> Cannot obtain needed blob 42988feeeb76f5cb92b541e9dac277e073bcb3ef
> while processing commit ffb2e81c03a01e74825b3a0223e214df59241fab.
> error: Fetch failed.
There are variations of this, such as
> $ git clone http://darcs.haskell.org/ghc.git/ build6
> Cloning into build6...
> error: inflate: data stream error (incorrect header check)
> error: inflate: data stream error (incorrect header check)
> error: inflate: data stream error (incorrect header check)
> error: inflate: data stream error (incorrect header check)
> error: inflate: data stream error (incorrect header check)
> error: File 280db842d43e7e68c09bf01695434fc0f8fff796
(http://darcs.haskell.org/ghc.git/objects/c8/ba6e77a6202e7df588c3b1fa3ada5142482036)
corrupt
> error: Unable to find c8ba6e77a6202e7df588c3b1fa3ada5142482036 under
http://darcs.haskell.org/ghc.git
> Cannot obtain needed blob c8ba6e77a6202e7df588c3b1fa3ada5142482036
> while processing commit ffb2e81c03a01e74825b3a0223e214df59241fab.
> error: Fetch failed.
In most cases, the git clone succeeds, but failure nevertheless happens
sufficiently often to break most builds. See, for example
http://darcs.haskell.org/ghcBuilder/builders/tn23/437/3.html.
I tried the clone of the main repository on my Ubuntu Linux machine that says
> $ uname -a
> Linux tn24 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:08:37 UTC 2011 i686
GNU/Linux
> $ git --version
> git version 1.7.0.4
> $
(which is connected to the same network as the Mac) and was not able to
reproduce the error.
I have looked for git options (debug, verbosity) for increasing the amount of
information reported, but have not managed to find anything that seemed useful
in this situation. The apparent randomness of the failures points to some kind
of network problem, but I have not noticed other indications that my network
connection is unstable.
I am not a git expert at all, I am not using git for anything but GHC building.
I would very much appreciate some indication of how I might investigate this
problem.
Best regards
Thorkil
^ permalink raw reply
* Git new-feature-branch best practices
From: Zganyaiko Dmitry @ 2011-09-11 19:31 UTC (permalink / raw)
To: git
Hi all! I have a question about using branches.
For example, I make branch for some experimental feature. After some
time I have completed this feature. I'll checkout previous branch and
merge this new feature's branch to it.
And there is my question. If I know that this feature was implemented
very good and _will not be changed lately_, should I remove this new
feature branch (because it will be unused)?
Is there some best practice what to do in my case?
So, should I remove a branch for some new feature after its
implementation if I sure that I will not edit this feature's code later?
May be, there is answer for my question already and I missed it?
^ permalink raw reply
* Re: t5800-*.sh: Intermittent test failures
From: Ramsay Jones @ 2011-09-11 19:14 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Sverre Rabbelier, GIT Mailing-list,
Jonathan Nieder
In-Reply-To: <20110908182055.GA16500@sigill.intra.peff.net>
Jeff King wrote:
> On Thu, Sep 08, 2011 at 06:42:11PM +0100, Ramsay Jones wrote:
>
>> When I run the tests with "make test >test-out", I see a failure rate of about
>> 1 in 10. If I then set the debug environment variables (GIT_TRANSPORT_HELPER_DEBUG,
>> GIT_TRANSLOOP_DEBUG and GIT_DEBUG_TESTGIT) and run the test script directly (-v),
>> then the failure rate goes up to about 1 in 3.
>
> Hmm. I can't reproduce a failure here, but I do get some weirdness. My
> recipe is:
Ah, sorry, ... I didn't make myself clear then, because ...
> -- >8 --
> cat >foo.sh <<\EOF
> #!/bin/sh
>
> exec >$1.out 2>&1
>
> n=0
> while test $n -lt 100; do
> n=$(($n+1))
> GIT_TRANSPORT_HELPER_DEBUG=1 \
> GIT_TRANSLOOP_DEBUG=1 \
> GIT_DEBUG_TESTGIT=1 \
> ./t5800-remote-helpers.sh --root=/run/shm/git-tests-$1 -v || {
> echo FAIL $n
> exit 1
> }
> echo OK $n
> done
> EOF
>
> # try to keep an 8-core machine busy
> for i in `seq 1 16`; do
> sh foo.sh $i &
> done
> -- 8< --
>
> I never see a test failure, but a few of the 16 end up hanging. The
> process tree for the hanged tests look like:
>
> t5800-remote-helper
> git push
> git-remote-testgit
> git fast-import
> git-fast-import
>
> All of them are blocked on wait(), except for the final fast-import,
> which is blocked trying to read() from stdin.
... these hangs *are* the failures of which I speak! Yes, the script
doesn't get to declare a failure, but AFAIAC a hanging test (and it
isn't the same test # each time) is a failing test. :-D
ATB,
Ramsay Jones
^ permalink raw reply
* [PATCH 0/2] spare warnings on master
From: Ramsay Jones @ 2011-09-11 19:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
Hi Junio,
These patches fix some sparse warnings on the master branch
(from repo.or.cz) @ 3793ac56b4c4f9bf0bddc306a0cec21118683728
[PATCH 1/2] sparse: Fix an "Using plain integer as NULL pointer"
[PATCH 2/2] obstack.c: Fix some sparse warnings
They could be squashed into one commit, if you prefer. The second
patch is not required on Linux, because *all* of the code in obstack.c
is #ifdef'd out, but it fixes things up on cygwin and MinGW.
ATB,
Ramsay Jones
^ permalink raw reply
* [PATCH 1/2] sparse: Fix an "Using plain integer as NULL pointer" warning
From: Ramsay Jones @ 2011-09-11 19:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
kwset.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kwset.c b/kwset.c
index 956ae72..51b2ab6 100644
--- a/kwset.c
+++ b/kwset.c
@@ -674,7 +674,7 @@ cwexec (kwset_t kws, char const *text, size_t len, struct kwsmatch *kwsmatch)
copy of the preceding main search loops. */
if (lim - mch > kwset->maxd)
lim = mch + kwset->maxd;
- lmch = 0;
+ lmch = NULL;
d = 1;
while (lim - end >= d)
{
--
1.7.6
^ permalink raw reply related
* [PATCH 2/2] obstack.c: Fix some sparse warnings
From: Ramsay Jones @ 2011-09-11 19:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
In particular, sparse issues the following warnings:
compat/obstack.c:176:17: warning: Using plain integer as NULL pointer
compat/obstack.c:224:17: warning: Using plain integer as NULL pointer
compat/obstack.c:324:16: warning: Using plain integer as NULL pointer
compat/obstack.c:329:16: warning: Using plain integer as NULL pointer
compat/obstack.c:347:16: warning: Using plain integer as NULL pointer
compat/obstack.c:362:19: warning: Using plain integer as NULL pointer
compat/obstack.c:379:29: warning: Using plain integer as NULL pointer
compat/obstack.c:399:1: error: symbol 'print_and_abort' redeclared with \
different type (originally declared at compat/obstack.c:95) \
- different modifiers
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
compat/obstack.c | 15 +++++++--------
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/compat/obstack.c b/compat/obstack.c
index a89ab5b..e276ccd 100644
--- a/compat/obstack.c
+++ b/compat/obstack.c
@@ -173,7 +173,7 @@ _obstack_begin (struct obstack *h,
alignment - 1);
h->chunk_limit = chunk->limit
= (char *) chunk + h->chunk_size;
- chunk->prev = 0;
+ chunk->prev = NULL;
/* The initial chunk now contains no empty object. */
h->maybe_empty_object = 0;
h->alloc_failed = 0;
@@ -221,7 +221,7 @@ _obstack_begin_1 (struct obstack *h, int size, int alignment,
alignment - 1);
h->chunk_limit = chunk->limit
= (char *) chunk + h->chunk_size;
- chunk->prev = 0;
+ chunk->prev = NULL;
/* The initial chunk now contains no empty object. */
h->maybe_empty_object = 0;
h->alloc_failed = 0;
@@ -321,12 +321,12 @@ _obstack_allocated_p (struct obstack *h, void *obj)
/* We use >= rather than > since the object cannot be exactly at
the beginning of the chunk but might be an empty object exactly
at the end of an adjacent chunk. */
- while (lp != 0 && ((void *) lp >= obj || (void *) (lp)->limit < obj))
+ while (lp != NULL && ((void *) lp >= obj || (void *) (lp)->limit < obj))
{
plp = lp->prev;
lp = plp;
}
- return lp != 0;
+ return lp != NULL;
}
\f
/* Free objects in obstack H, including OBJ and everything allocate
@@ -344,7 +344,7 @@ obstack_free (struct obstack *h, void *obj)
/* We use >= because there cannot be an object at the beginning of a chunk.
But there can be an empty object at that address
at the end of another chunk. */
- while (lp != 0 && ((void *) lp >= obj || (void *) (lp)->limit < obj))
+ while (lp != NULL && ((void *) lp >= obj || (void *) (lp)->limit < obj))
{
plp = lp->prev;
CALL_FREEFUN (h, lp);
@@ -359,7 +359,7 @@ obstack_free (struct obstack *h, void *obj)
h->chunk_limit = lp->limit;
h->chunk = lp;
}
- else if (obj != 0)
+ else if (obj != NULL)
/* obj is not in any of the chunks! */
abort ();
}
@@ -376,7 +376,7 @@ _obstack_memory_used (struct obstack *h)
register struct _obstack_chunk* lp;
register int nbytes = 0;
- for (lp = h->chunk; lp != 0; lp = lp->prev)
+ for (lp = h->chunk; lp != NULL; lp = lp->prev)
{
nbytes += lp->limit - (char *) lp;
}
@@ -395,7 +395,6 @@ _obstack_memory_used (struct obstack *h)
# endif
static void
-__attribute__ ((noreturn))
print_and_abort (void)
{
/* Don't change any of these strings. Yes, it would be possible to add
--
1.7.6
^ permalink raw reply related
* [PATCH 0/3] misc patches on next branch
From: Ramsay Jones @ 2011-09-11 19:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
Hi Junio,
These patches are built on the next branch (from repo.or.cz)
@ 12850bec0c24b529c9a9df6a95ad4bdeea39373e
[PATCH 1/3] sparse: Fix some "symbol not declared" warnings
[PATCH 2/3] Fix some "variable might be used uninitialized" warnings
[PATCH 3/3] Makefile: Make dependency directory creation less noisy
Note that the next branch does not build on MinGW at the moment due
to the credentials-cache[--daemon] additions; rather the use of unix
sockets to be more precise. I had intended to fix this up by now (one
option being to emulate unix sockets with win32 named pipes) but I
haven't had time - sorry!
ATB,
Ramsay Jones
^ permalink raw reply
* [PATCH 1/3] sparse: Fix some "symbol not declared" warnings
From: Ramsay Jones @ 2011-09-11 19:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
In particular, sparse issues the "symbol 'a_symbol' was not declared.
Should it be static?" warning for the following symbols:
submodule.c:321:5: 'submodule_needs_pushing'
submodule.c:355:5: 'push_submodule'
builtin/revert.c:662:20: 'commit_list_append'
These symbols only require file scope, so we simply add the static
modifier to their declarations.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
builtin/revert.c | 4 ++--
submodule.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index 5e97622..5f1cee8 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -659,8 +659,8 @@ static void read_and_refresh_cache(struct replay_opts *opts)
* assert(commit_list_count(list) == 2);
* return list;
*/
-struct commit_list **commit_list_append(struct commit *commit,
- struct commit_list **next)
+static struct commit_list **commit_list_append(struct commit *commit,
+ struct commit_list **next)
{
struct commit_list *new = xmalloc(sizeof(struct commit_list));
new->item = commit;
diff --git a/submodule.c b/submodule.c
index 38d9877..5a02890 100644
--- a/submodule.c
+++ b/submodule.c
@@ -318,7 +318,7 @@ static int has_remote(const char *refname, const unsigned char *sha1, int flags,
return 1;
}
-int submodule_needs_pushing(const char *path, const unsigned char sha1[20], void *data)
+static int submodule_needs_pushing(const char *path, const unsigned char sha1[20], void *data)
{
int *needs_pushing = data;
@@ -352,7 +352,7 @@ int submodule_needs_pushing(const char *path, const unsigned char sha1[20], void
return 1;
}
-int push_submodule(const char *path, const unsigned char sha1[20], void *data)
+static int push_submodule(const char *path, const unsigned char sha1[20], void *data)
{
if (add_submodule_odb(path) || !lookup_commit_reference(sha1))
return 1;
--
1.7.6
^ permalink raw reply related
* [PATCH 2/3] Fix some "variable might be used uninitialized" warnings
From: Ramsay Jones @ 2011-09-11 19:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
In particular, gcc complains as follows:
CC tree-walk.o
tree-walk.c: In function `traverse_trees':
tree-walk.c:347: warning: 'e' might be used uninitialized in this \
function
CC builtin/revert.o
builtin/revert.c: In function `verify_opt_mutually_compatible':
builtin/revert.c:113: warning: 'opt2' might be used uninitialized in \
this function
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
builtin/revert.c | 2 +-
tree-walk.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index 5f1cee8..30538a1 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -110,7 +110,7 @@ static void verify_opt_compatible(const char *me, const char *base_opt, ...)
static void verify_opt_mutually_compatible(const char *me, ...)
{
- const char *opt1, *opt2;
+ const char *opt1, *opt2 = NULL;
va_list ap;
va_start(ap, me);
diff --git a/tree-walk.c b/tree-walk.c
index 808bb55..a8d8a66 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -344,7 +344,7 @@ int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
unsigned long mask, dirmask;
const char *first = NULL;
int first_len = 0;
- struct name_entry *e;
+ struct name_entry *e = NULL;
int len;
for (i = 0; i < n; i++) {
--
1.7.6
^ permalink raw reply related
* [PATCH 3/3] Makefile: Make dependency directory creation less noisy
From: Ramsay Jones @ 2011-09-11 19:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 0ea1a2b..a0f0faf 100644
--- a/Makefile
+++ b/Makefile
@@ -1909,7 +1909,7 @@ dep_dirs := $(addsuffix .depend,$(sort $(dir $(OBJECTS))))
ifdef COMPUTE_HEADER_DEPENDENCIES
$(dep_dirs):
- mkdir -p $@
+ @mkdir -p $@
missing_dep_dirs := $(filter-out $(wildcard $(dep_dirs)),$(dep_dirs))
dep_file = $(dir $@).depend/$(notdir $@).d
--
1.7.6
^ permalink raw reply related
* Re: How do I investigate apparently random git clone reports of "error: File ... has bad hash"?
From: Andreas Schwab @ 2011-09-11 19:59 UTC (permalink / raw)
To: Thorkil Naur; +Cc: git
In-Reply-To: <loom.20110911T210035-693@post.gmane.org>
Thorkil Naur <naur@post11.tele.dk> writes:
>> $ git clone http://darcs.haskell.org/ghc.git/ build8
>> Cloning into build8...
>> error: File 42988feeeb76f5cb92b541e9dac277e073bcb3ef has bad hash
>> error: Unable to find 42988feeeb76f5cb92b541e9dac277e073bcb3ef under
> http://darcs.haskell.org/ghc.git
>> Cannot obtain needed blob 42988feeeb76f5cb92b541e9dac277e073bcb3ef
>> while processing commit ffb2e81c03a01e74825b3a0223e214df59241fab.
>> error: Fetch failed.
I just tried to clone it and got this error:
$ git clone http://darcs.haskell.org/ghc.git
Cloning into ghc...
error: Recv failure: Connection reset by peer (curl_result = 56, http_code = 0, sha1 = be6810bb027643bf0697b3d237426110f064aba1)
error: Unable to find be6810bb027643bf0697b3d237426110f064aba1 under http://darcs.haskell.org/ghc.git
Cannot obtain needed commit be6810bb027643bf0697b3d237426110f064aba1
while processing commit 6942b112082fbcdff5c66f06f56fdd336861da47.
error: Fetch failed.
It looks like this is just a network problem.
Btw, the repo is rather strange. It's not a bare repo, but does not
contain a .git directory. Instead the files that are normally under
.git are placed directly in the working tree.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: How do I investigate apparently random git clone reports of "error: File ... has bad hash"?
From: Andreas Schwab @ 2011-09-11 20:13 UTC (permalink / raw)
To: Thorkil Naur; +Cc: git
In-Reply-To: <loom.20110911T210035-693@post.gmane.org>
Thorkil Naur <naur@post11.tele.dk> writes:
> I have looked for git options (debug, verbosity) for increasing the amount of
> information reported, but have not managed to find anything that seemed useful
> in this situation.
Try adding -v -v when cloning. That also shows you that the server does
not support smart-http, which is suboptimal.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] Support empty blob in fsck --lost-found
From: Junio C Hamano @ 2011-09-11 20:43 UTC (permalink / raw)
To: BJ Hargrave; +Cc: git
In-Reply-To: <A3964281-B24B-46C0-AE73-0CCB4C12556F@bjhargrave.com>
BJ Hargrave <bj@bjhargrave.com> writes:
> diff --git a/builtin/fsck.c b/builtin/fsck.c
> index 5ae0366..ad6d713 100644
> --- a/builtin/fsck.c
> +++ b/builtin/fsck.c
> @@ -232,9 +232,10 @@ static void check_unreachable_object(struct object *obj)
> char *buf = read_sha1_file(obj->sha1,
> &type, &size);
> if (buf) {
> - if (fwrite(buf, size, 1, f) != 1)
> - die_errno("Could not write '%s'",
> - filename);
> + if (size > 0)
> + if (fwrite(buf, size, 1, f) != 1)
> + die_errno("Could not write '%s'",
> + filename);
Funny.
I am sure we fixed a similar breakage elsewhere a few years ago, by
swapping the size and nmemb to the calls (i.e. instead of writing one
block of "size" bytes, you could write "size" blocks of 1-byte) and making
sure fwrite() reports the number of items. IOW
if (buf && fwrite(buf, 1, size, f) != size)
die_errno("Could not write '%s'", filename);
^ permalink raw reply
* Re: [PATCH 2/3] Fix some "variable might be used uninitialized" warnings
From: Junio C Hamano @ 2011-09-11 20:48 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list
In-Reply-To: <4E6D0E74.1020801@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> In particular, gcc complains as follows:
>
> CC tree-walk.o
> tree-walk.c: In function `traverse_trees':
> tree-walk.c:347: warning: 'e' might be used uninitialized in this \
> function
>
> CC builtin/revert.o
> builtin/revert.c: In function `verify_opt_mutually_compatible':
> builtin/revert.c:113: warning: 'opt2' might be used uninitialized in \
> this function
Could you also add something to this effect to the commit log message:
but I have verified that these are gcc being not careful
enough and they are never used uninitialized.
If that is what you indeed have done, that is.
Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox