threads / announce / 2985

[ANNOUNCE] GIT 1.0.7

Subject: [ANNOUNCE] GIT 1.0.7

## tl;dr

11 messages between Jan 7, 2006 and Jan 7, 2006.

replies: 10people: 5as markdown or json

Junio C Hamano· Jan 7, 2006, 07:01 UTC · lore
GIT 1.0.7 is available at http://www.kernel.org/pub/software/scm/git/

Just bunch of cleanups, documentation formatting and spelling fixes, among them notable are:

 - git-format-patch and git-commit now handles author names with
   ' (ASCII 0x27, single quote) character in them properly.
 - approxidate parser does not get confused when we say "10 days
   ago" immediately after new year.

The master branch has accumulated enough enhancements, and I plan to do GIT 1.1.0 (and start 1.1.X maintenance series) over the weekend. What will be there are listed here, but those who have been running the "master" branch must be familiar with most of them.

Johannes Schindelin:
      git-clone: Support changing the origin branch with -o
      Introduce core.sharedrepository
      git-init-db: initialize shared repositories with --shared
John Ellson:
      Make GIT-VERSION-GEN tolerate missing git describe command
Junio C Hamano:
      Versioning scheme changes.
      merge-recursive: conflicting rename case.
      whatchanged: customize diff-tree output
      rev-parse: --show-cdup
      check_packed_git_idx(): check integrity of the idx file itself.
      checkout: sometimes work from a subdirectory.
      ls-tree: chomp leading directories when run from a subdirectory
      git-clone: do not special case dumb http.
      Tutorial: mention shared repository management.
      git-describe: really prefer tags only.
      git-describe: use find_unique_abbrev()
      git-describe: --tags and --abbrev
      git-describe: still prefer annotated tag under --all and --tags
      git-describe: documentation.
      Makefile: use git-describe to mark the git version.
      send-pack/receive-pack: allow errors to be reported back to pusher.
Linus Torvalds:
      Add a "git-describe" command
Lukas Sandstrom:
      git-pack-redundant: speed and memory usage improvements
YOSHIFUJI Hideaki:
      GIT: Support [address] in URLs
YOSHIFUJI Hideaki / 吉藤英明· Jan 7, 2006, 08:16 UTC · re: Junio C Hamano · lore

Re: [ANNOUNCE] GIT 1.0.7

In article <7vhd8go71t.fsf@assigned-by-dhcp.cox.net> (at Fri, 06 Jan 2006 23:01:34 -0800), Junio C Hamano <junkio@cox.net> says:
> GIT 1.0.7 is available at http://www.kernel.org/pub/software/scm/git/

Allow compilation w/ gcc 2.95.4. (Or, it is okay to replace path[] with path[0].)

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
diff --git a/describe.c b/describe.c
index 84d96b5..3688c4a 100644
--- a/describe.c
+++ b/describe.c
@@ -17,8 +17,8 @@ static int abbrev = DEFAULT_ABBREV;
 static int names = 0, allocs = 0;
 static struct commit_name {
 	const struct commit *commit;
+	char *path;
 	int prio; /* annotated tag = 2, tag = 1, head = 0 */
-	char path[];
 } **name_array = NULL;
 
 static struct commit_name *match(struct commit *cmit)
@@ -43,6 +43,7 @@ static void add_to_known_names(const cha
 	struct commit_name *name = xmalloc(sizeof(struct commit_name) + len);
 
 	name->commit = commit;
+	name->path = sizeof(*name);
 	name->prio = prio; 
 	memcpy(name->path, path, len);
 	idx = names;
-- 
YOSHIFUJI Hideaki @ USAGI Project  <yoshfuji@linux-ipv6.org>
GPG-FP  : 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
David S. Miller· Jan 7, 2006, 08:29 UTC · re: YOSHIFUJI Hideaki / 吉藤英明 · lore

Re: [ANNOUNCE] GIT 1.0.7

From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Sat, 07 Jan 2006 02:16:14 -0600 (CST)
Show 8 quoted lines
> @@ -43,6 +43,7 @@ static void add_to_known_names(const cha
>  	struct commit_name *name = xmalloc(sizeof(struct commit_name) + len);
>  
>  	name->commit = commit;
> +	name->path = sizeof(*name);
>  	name->prio = prio; 
>  	memcpy(name->path, path, len);
>  	idx = names;

Why are you assigning an integer to a pointer? :-) Probably you meant something like:

	struct commit_name *name = xmalloc(sizeof(struct commit_name) + len);
	...
	name->path = xmalloc(len);
	...
YOSHIFUJI Hideaki / 吉藤英明· Jan 7, 2006, 08:33 UTC · re: David S. Miller · lore

Re: [ANNOUNCE] GIT 1.0.7

In article <20060107.002904.87767885.davem@davemloft.net> (at Sat, 07 Jan 2006 00:29:04 -0800 (PST)), "David S. Miller" <davem@davemloft.net> says:
> >  	name->commit = commit;
> > +	name->path = sizeof(*name);
> >  	name->prio = prio; 
Show 8 quoted lines
> Why are you assigning an integer to a pointer? :-)
> Probably you meant something like:
> 
> 	struct commit_name *name = xmalloc(sizeof(struct commit_name) + len);
> 
> 	...
> 	name->path = xmalloc(len);
> 	...
oops.... you're right...
--yoshfuji @ about to fly
Junio C Hamano· Jan 7, 2006, 08:43 UTC · re: YOSHIFUJI Hideaki / 吉藤英明 · lore

Re: [ANNOUNCE] GIT 1.0.7

[Yoshifuji-san, you will see this message twice but everybody else would not --- I removed your Japanese name from the body of the message, to pass mail filter at kernel.org]

YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> writes:
> Allow compilation w/ gcc 2.95.4.
> (Or, it is okay to replace path[] with path[0].)

This is unfortunate; path[] is the correct C (and path[0] is not---it is an gcc extension), and we have quite a few of them. Last time somebody wanted to change all of them to path[] we found out gcc 2.95 did not like it, and ended up doing path[0] form. So I'd say change it to path[0] for now.

Junio C Hamano· Jan 7, 2006, 09:56 UTC · re: Junio C Hamano · lore

Re: [ANNOUNCE] GIT 1.0.7

Junio C Hamano <junkio@cox.net> writes:
Show 10 quoted lines
> YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> writes:
>
>> Allow compilation w/ gcc 2.95.4.
>> (Or, it is okay to replace path[] with path[0].)
>
> This is unfortunate; path[] is the correct C (and path[0] is
> not---it is an gcc extension), and we have quite a few of them.
> Last time somebody wanted to change all of them to path[] we
> found out gcc 2.95 did not like it, and ended up doing path[0]
> form.  So I'd say change it to path[0] for now.

Here is what I am planning to merge into the master/maint. The patch is for maint which does not ship with describe, but the problematic path[] can be updated to path[FLEX_ARRAY] as others when merging it to the master branch.

-- >8 --
Subject: [PATCH] Compilation: zero-length array declaration.

ISO C99 (and GCC 3.x or later) lets you write a flexible array at the end of a structure, like this:

	struct frotz {
		int xyzzy;
		char nitfol[]; /* more */
	};

GCC 2.95 lets you to do this with "char nitfol[0]"; unfortunately this is not allowed by ISO C90.

This declares such construct like this:
	struct frotz {
		int xyzzy;
		char nitfol[FLEX_ARRAY]; /* more */
	};

and git-compat-util.h defines FLEX_ARRAY to 0 for gcc 2.95 and empty for others.

Although I have not tried this myself, if you are using a C90 C compiler, you should be able to override this with CFLAGS=-DFLEX_ARRAY=1 from the command line of "make".

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 blob.c            |    2 +-
 cache.h           |    9 +++++----
 commit.c          |    2 +-
 git-compat-util.h |    8 ++++++++
 ls-files.c        |    2 +-
 object.c          |    2 +-
 object.h          |    2 +-
 receive-pack.c    |    2 +-
 tag.c             |    2 +-
 tree.c            |    2 +-
 10 files changed, 21 insertions(+), 12 deletions(-)
33751f1c4e23e928f18a019292cb8562cd7c7f76
diff --git a/blob.c b/blob.c
index ea52ad5..84ec121 100644
--- a/blob.c
+++ b/blob.c
@@ -1,5 +1,5 @@
-#include "blob.h"
 #include "cache.h"
+#include "blob.h"
 #include <stdlib.h>
 
 const char *blob_type = "blob";
diff --git a/cache.h b/cache.h
index cb87bec..5fd2687 100644
--- a/cache.h
+++ b/cache.h
@@ -81,7 +81,7 @@ struct cache_entry {
 	unsigned int ce_size;
 	unsigned char sha1[20];
 	unsigned short ce_flags;
-	char name[0];
+	char name[FLEX_ARRAY]; /* more */
 };
 
 #define CE_NAMEMASK  (0x0fff)
@@ -257,7 +257,7 @@ extern int checkout_entry(struct cache_e
 extern struct alternate_object_database {
 	struct alternate_object_database *next;
 	char *name;
-	char base[0]; /* more */
+	char base[FLEX_ARRAY]; /* more */
 } *alt_odb_list;
 extern void prepare_alt_odb(void);
 
@@ -271,7 +271,8 @@ extern struct packed_git {
 	unsigned int pack_use_cnt;
 	int pack_local;
 	unsigned char sha1[20];
-	char pack_name[0]; /* something like ".git/objects/pack/xxxxx.pack" */
+	/* something like ".git/objects/pack/xxxxx.pack" */
+	char pack_name[FLEX_ARRAY]; /* more */
 } *packed_git;
 
 struct pack_entry {
@@ -286,7 +287,7 @@ struct ref {
 	unsigned char new_sha1[20];
 	unsigned char force;
 	struct ref *peer_ref; /* when renaming */
-	char name[0];
+	char name[FLEX_ARRAY]; /* more */
 };
 
 extern int git_connect(int fd[2], char *url, const char *prog);
diff --git a/commit.c b/commit.c
index edd4ded..fb02ba6 100644
--- a/commit.c
+++ b/commit.c
@@ -1,6 +1,6 @@
+#include "cache.h"
 #include "tag.h"
 #include "commit.h"
-#include "cache.h"
 
 int save_commit_buffer = 1;
 
diff --git a/git-compat-util.h b/git-compat-util.h
index c353b27..1a263a6 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -1,6 +1,14 @@
 #ifndef GIT_COMPAT_UTIL_H
 #define GIT_COMPAT_UTIL_H
 
+#ifndef FLEX_ARRAY
+#if (__GNUC__ == 2) && (__GNUC_MINOR__ == 95)
+#define FLEX_ARRAY 0
+#else
+#define FLEX_ARRAY /* empty */
+#endif
+#endif
+
 #include <unistd.h>
 #include <stdio.h>
 #include <sys/stat.h>
diff --git a/ls-files.c b/ls-files.c
index cd87430..74ec8c0 100644
--- a/ls-files.c
+++ b/ls-files.c
@@ -208,7 +208,7 @@ static int excluded(const char *pathname
 
 struct nond_on_fs {
 	int len;
-	char name[0];
+	char name[FLEX_ARRAY]; /* more */
 };
 
 static struct nond_on_fs **dir;
diff --git a/object.c b/object.c
index cf5931a..1577f74 100644
--- a/object.c
+++ b/object.c
@@ -1,8 +1,8 @@
+#include "cache.h"
 #include "object.h"
 #include "blob.h"
 #include "tree.h"
 #include "commit.h"
-#include "cache.h"
 #include "tag.h"
 
 struct object **objs;
diff --git a/object.h b/object.h
index 336d986..0e76182 100644
--- a/object.h
+++ b/object.h
@@ -9,7 +9,7 @@ struct object_list {
 
 struct object_refs {
 	unsigned count;
-	struct object *ref[0];
+	struct object *ref[FLEX_ARRAY]; /* more */
 };
 
 struct object {
diff --git a/receive-pack.c b/receive-pack.c
index 92878ec..ce986fe 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -24,7 +24,7 @@ struct command {
 	unsigned char updated;
 	unsigned char old_sha1[20];
 	unsigned char new_sha1[20];
-	char ref_name[0];
+	char ref_name[FLEX_ARRAY]; /* more */
 };
 
 static struct command *commands = NULL;
diff --git a/tag.c b/tag.c
index 61ac434..ac0e573 100644
--- a/tag.c
+++ b/tag.c
@@ -1,5 +1,5 @@
-#include "tag.h"
 #include "cache.h"
+#include "tag.h"
 
 const char *tag_type = "tag";
 
diff --git a/tree.c b/tree.c
index e7a7b71..dc1c41e 100644
--- a/tree.c
+++ b/tree.c
@@ -1,8 +1,8 @@
+#include "cache.h"
 #include "tree.h"
 #include "blob.h"
 #include "commit.h"
 #include "tag.h"
-#include "cache.h"
 #include <stdlib.h>
 
 const char *tree_type = "tree";
-- 
1.0.7-g0263
Sergey Vlasov· Jan 7, 2006, 12:12 UTC · re: Junio C Hamano · lore

Re: [ANNOUNCE] GIT 1.0.7

On Sat, 07 Jan 2006 01:56:41 -0800 Junio C Hamano wrote:
Show 5 quoted lines
> +#if (__GNUC__ == 2) && (__GNUC_MINOR__ == 95)
> +#define FLEX_ARRAY 0
> +#else
> +#define FLEX_ARRAY /* empty */
> +#endif

There is also gcc 2.96, which also does not understand the C99 syntax. So we should use something like this instead:

#if defined(__GNUC__) && (__GNUC__ < 3) #define FLEX_ARRAY 0 #else #define FLEX_ARRAY /* empty */ #endif

(and be prepared to get complaints from users of other compilers).
Junio C Hamano· Jan 7, 2006, 18:27 UTC · re: Sergey Vlasov · lore

Re: [ANNOUNCE] GIT 1.0.7

Sergey Vlasov <vsu@altlinux.ru> writes:
Show 10 quoted lines
> There is also gcc 2.96, which also does not understand the C99 syntax.
> So we should use something like this instead:
>
> #if defined(__GNUC__) && (__GNUC__ < 3)
> #define FLEX_ARRAY 0
> #else
> #define FLEX_ARRAY /* empty */
> #endif
>
> (and be prepared to get complaints from users of other compilers).
Thanks.
H. Peter Anvin· Jan 7, 2006, 20:47 UTC · re: Junio C Hamano · lore

Re: [ANNOUNCE] GIT 1.0.7

Junio C Hamano wrote:
Show 34 quoted lines
> 
> Here is what I am planning to merge into the master/maint.  The
> patch is for maint which does not ship with describe, but the
> problematic path[] can be updated to path[FLEX_ARRAY] as others
> when merging it to the master branch.
> 
> -- >8 --
> Subject: [PATCH] Compilation: zero-length array declaration.
> 
> ISO C99 (and GCC 3.x or later) lets you write a flexible array
> at the end of a structure, like this:
> 
> 	struct frotz {
> 		int xyzzy;
> 		char nitfol[]; /* more */
> 	};
> 
> GCC 2.95 lets you to do this with "char nitfol[0]";
> unfortunately this is not allowed by ISO C90.
> 
> This declares such construct like this:
> 
> 	struct frotz {
> 		int xyzzy;
> 		char nitfol[FLEX_ARRAY]; /* more */
> 	};
> 
> and git-compat-util.h defines FLEX_ARRAY to 0 for gcc 2.95 and
> empty for others.
> 
> Although I have not tried this myself, if you are using a C90 C
> compiler, you should be able to override this with
> CFLAGS=-DFLEX_ARRAY=1 from the command line of "make".
> 
Any reason to not just do:
  	struct frotz {
  		int xyzzy;
  		char nitfol[1]; /* more */
  	};
... which should work on all compilers?
	-hpa
Junio C Hamano· Jan 7, 2006, 21:12 UTC · re: H. Peter Anvin · lore

Re: [ANNOUNCE] GIT 1.0.7

"H. Peter Anvin" <hpa@zytor.com> writes:
Show 8 quoted lines
> Any reason to not just do:
>
>  	struct frotz {
>  		int xyzzy;
>  		char nitfol[1]; /* more */
>  	};
>
> ... which should work on all compilers?

Laziness, especially to avoid having to deal with comments like "your xmalloc(sizeof(struct frotz) + strlen(nitfol) + 1) should be xmalloc(sizeof(struct frotz) + strlen(nitfol)), because you have already one byte for nitfol element."

H. Peter Anvin· Jan 7, 2006, 21:30 UTC · re: Junio C Hamano · lore

Re: [ANNOUNCE] GIT 1.0.7

Junio C Hamano wrote:
Show 17 quoted lines
> "H. Peter Anvin" <hpa@zytor.com> writes:
> 
> 
>>Any reason to not just do:
>>
>> 	struct frotz {
>> 		int xyzzy;
>> 		char nitfol[1]; /* more */
>> 	};
>>
>>... which should work on all compilers?
> 
> Laziness, especially to avoid having to deal with comments like
> "your xmalloc(sizeof(struct frotz) + strlen(nitfol) + 1) should be
> xmalloc(sizeof(struct frotz) + strlen(nitfol)), because you
> have already one byte for nitfol element."
> 

In the case of strings, that's probably a blessing (already accounted for the null byte).

	-hpa

← back to recent threads