* Ignore version update changes on git show report?
From: Preben Liland Madsen @ 2013-02-26 19:53 UTC (permalink / raw)
To: git
Hello,
I'm trying to investigate some what changes have been done between two versions of a software with the name IP.Board.
This proves more troublesome than I thought, since their release builder appearantly updates the version number automatically in all files.
This causes a lot of files to have this as the only change:
- * IP.Board v3.4.2
+ * IP.Board v3.4.3
Which is quite annoying to have to go through and therefor is responsible for more than 800 files being changed.
Is there some sort of git command or command I can combine together with git show that will ignore files with only these changes? Something along the lines of ignoring files where the only change matches this change or ignore files that've only gotten 1 line removed and 1 line added?
Best regards, Preben
^ permalink raw reply
* [PATCH 2/4] config: drop file pointer validity check in get_next_char()
From: Heiko Voigt @ 2013-02-26 19:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann, Jeff King
In-Reply-To: <20130226193050.GA22756@sandbox-ub>
The only location where cf is set in this file is in do_config_from().
This function has only one callsite which is config_from_file(). In
config_from_file() its ensured that the f member is set to non-zero.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/config.c b/config.c
index 2c299dc..f55c43d 100644
--- a/config.c
+++ b/config.c
@@ -169,10 +169,10 @@ int git_config_from_parameters(config_fn_t fn, void *data)
static int get_next_char(void)
{
int c;
- FILE *f;
c = '\n';
- if (cf && ((f = cf->f) != NULL)) {
+ if (cf) {
+ FILE *f = cf->f;
c = fgetc(f);
if (c == '\r') {
/* DOS like systems */
--
1.8.2.rc0.26.gf7384c5
^ permalink raw reply related
* [PATCH 4/4] teach config parsing to read from strbuf
From: Heiko Voigt @ 2013-02-26 19:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann, Jeff King
In-Reply-To: <20130226193050.GA22756@sandbox-ub>
This can be used to read configuration values directly from gits
database.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
.gitignore | 1 +
Makefile | 1 +
cache.h | 1 +
config.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
t/t1300-repo-config.sh | 4 ++++
test-config.c | 41 +++++++++++++++++++++++++++++++++++++++++
6 files changed, 95 insertions(+)
create mode 100644 test-config.c
diff --git a/.gitignore b/.gitignore
index 6669bf0..386b7f2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -178,6 +178,7 @@
/gitweb/static/gitweb.min.*
/test-chmtime
/test-ctype
+/test-config
/test-date
/test-delta
/test-dump-cache-tree
diff --git a/Makefile b/Makefile
index ba8e243..98da708 100644
--- a/Makefile
+++ b/Makefile
@@ -543,6 +543,7 @@ PROGRAMS += $(patsubst %.o,git-%$X,$(PROGRAM_OBJS))
TEST_PROGRAMS_NEED_X += test-chmtime
TEST_PROGRAMS_NEED_X += test-ctype
+TEST_PROGRAMS_NEED_X += test-config
TEST_PROGRAMS_NEED_X += test-date
TEST_PROGRAMS_NEED_X += test-delta
TEST_PROGRAMS_NEED_X += test-dump-cache-tree
diff --git a/cache.h b/cache.h
index e493563..ada2362 100644
--- a/cache.h
+++ b/cache.h
@@ -1128,6 +1128,7 @@ extern int update_server_info(int);
typedef int (*config_fn_t)(const char *, const char *, void *);
extern int git_default_config(const char *, const char *, void *);
extern int git_config_from_file(config_fn_t fn, const char *, void *);
+extern int git_config_from_strbuf(config_fn_t fn, struct strbuf *strbuf, void *data);
extern void git_config_push_parameter(const char *text);
extern int git_config_from_parameters(config_fn_t fn, void *data);
extern int git_config(config_fn_t fn, void *);
diff --git a/config.c b/config.c
index 19aa205..492873a 100644
--- a/config.c
+++ b/config.c
@@ -46,6 +46,37 @@ static long config_file_ftell(struct config *conf)
return ftell(f);
}
+struct config_strbuf {
+ struct strbuf *strbuf;
+ int pos;
+};
+
+static int config_strbuf_fgetc(struct config *conf)
+{
+ struct config_strbuf *str = conf->data;
+
+ if (str->pos < str->strbuf->len)
+ return str->strbuf->buf[str->pos++];
+
+ return EOF;
+}
+
+static int config_strbuf_ungetc(int c, struct config *conf)
+{
+ struct config_strbuf *str = conf->data;
+
+ if (str->pos > 0)
+ return str->strbuf->buf[--str->pos];
+
+ return EOF;
+}
+
+static long config_strbuf_ftell(struct config *conf)
+{
+ struct config_strbuf *str = conf->data;
+ return str->pos;
+}
+
#define MAX_INCLUDE_DEPTH 10
static const char include_depth_advice[] =
"exceeded maximum include depth (%d) while including\n"
@@ -961,6 +992,22 @@ int git_config_from_file(config_fn_t fn, const char *filename, void *data)
return ret;
}
+int git_config_from_strbuf(config_fn_t fn, struct strbuf *strbuf, void *data)
+{
+ struct config top;
+ struct config_strbuf str;
+
+ str.strbuf = strbuf;
+ str.pos = 0;
+
+ top.data = &str;
+ top.fgetc = config_strbuf_fgetc;
+ top.ungetc = config_strbuf_ungetc;
+ top.ftell = config_strbuf_ftell;
+
+ return do_config_from(&top, fn, data);
+}
+
const char *git_etc_gitconfig(void)
{
static const char *system_wide;
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 3c96fda..3304bcd 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -1087,4 +1087,8 @@ test_expect_success 'barf on incomplete string' '
grep " line 3 " error
'
+test_expect_success 'reading config from strbuf' '
+ test-config strbuf
+'
+
test_done
diff --git a/test-config.c b/test-config.c
new file mode 100644
index 0000000..7a4103c
--- /dev/null
+++ b/test-config.c
@@ -0,0 +1,41 @@
+#include "cache.h"
+
+static const char *config_string = "[some]\n"
+ " value = content\n";
+
+static int config_strbuf(const char *var, const char *value, void *data)
+{
+ int *success = data;
+ if (!strcmp(var, "some.value") && !strcmp(value, "content"))
+ *success = 0;
+
+ printf("var: %s, value: %s\n", var, value);
+
+ return 1;
+}
+
+static void die_usage(int argc, char **argv)
+{
+ fprintf(stderr, "Usage: %s strbuf\n", argv[0]);
+ exit(1);
+}
+
+int main(int argc, char **argv)
+{
+ if (argc < 2)
+ die_usage(argc, argv);
+
+ if (!strcmp(argv[1], "strbuf")) {
+ int success = 1;
+ struct strbuf buf = STRBUF_INIT;
+
+ strbuf_addstr(&buf, config_string);
+ git_config_from_strbuf(config_strbuf, &buf, &success);
+
+ return success;
+ }
+
+ die_usage(argc, argv);
+
+ return 1;
+}
--
1.8.2.rc0.26.gf7384c5
^ permalink raw reply related
* [PATCH 3/4] config: make parsing stack struct independent from actual data source
From: Heiko Voigt @ 2013-02-26 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann, Jeff King
In-Reply-To: <20130226193050.GA22756@sandbox-ub>
To simplify adding other sources we extract all functions needed for
parsing into a list of callbacks. We implement those callbacks for the
current file parsing. A new source can implement its own set of callbacks.
Instead of storing the concrete FILE pointer for parsing we store a void
pointer. A new source can use this to store its custom data.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
config.c | 57 ++++++++++++++++++++++++++++++++++++++++-----------------
1 file changed, 40 insertions(+), 17 deletions(-)
diff --git a/config.c b/config.c
index f55c43d..19aa205 100644
--- a/config.c
+++ b/config.c
@@ -10,20 +10,42 @@
#include "strbuf.h"
#include "quote.h"
-typedef struct config_file {
- struct config_file *prev;
- FILE *f;
+struct config {
+ struct config *prev;
+ void *data;
const char *name;
int linenr;
int eof;
struct strbuf value;
struct strbuf var;
-} config_file;
-static config_file *cf;
+ int (*fgetc)(struct config *c);
+ int (*ungetc)(int c, struct config *conf);
+ long (*ftell)(struct config *c);
+};
+
+static struct config *cf;
static int zlib_compression_seen;
+static int config_file_fgetc(struct config *conf)
+{
+ FILE *f = conf->data;
+ return fgetc(f);
+}
+
+static int config_file_ungetc(int c, struct config *conf)
+{
+ FILE *f = conf->data;
+ return ungetc(c, f);
+}
+
+static long config_file_ftell(struct config *conf)
+{
+ FILE *f = conf->data;
+ return ftell(f);
+}
+
#define MAX_INCLUDE_DEPTH 10
static const char include_depth_advice[] =
"exceeded maximum include depth (%d) while including\n"
@@ -172,13 +194,12 @@ static int get_next_char(void)
c = '\n';
if (cf) {
- FILE *f = cf->f;
- c = fgetc(f);
+ c = cf->fgetc(cf);
if (c == '\r') {
/* DOS like systems */
- c = fgetc(f);
+ c = cf->fgetc(cf);
if (c != '\n') {
- ungetc(c, f);
+ cf->ungetc(c, cf);
c = '\r';
}
}
@@ -896,7 +917,7 @@ int git_default_config(const char *var, const char *value, void *dummy)
return 0;
}
-static int do_config_from(struct config_file *top, config_fn_t fn, void *data)
+static int do_config_from(struct config *top, config_fn_t fn, void *data)
{
int ret;
@@ -925,10 +946,13 @@ int git_config_from_file(config_fn_t fn, const char *filename, void *data)
ret = -1;
if (f) {
- config_file top;
+ struct config top;
- top.f = f;
+ top.data = f;
top.name = filename;
+ top.fgetc = config_file_fgetc;
+ top.ungetc = config_file_ungetc;
+ top.ftell = config_file_ftell;
ret = do_config_from(&top, fn, data);
@@ -1063,7 +1087,6 @@ static int store_aux(const char *key, const char *value, void *cb)
{
const char *ep;
size_t section_len;
- FILE *f = cf->f;
switch (store.state) {
case KEY_SEEN:
@@ -1075,7 +1098,7 @@ static int store_aux(const char *key, const char *value, void *cb)
return 1;
}
- store.offset[store.seen] = ftell(f);
+ store.offset[store.seen] = cf->ftell(cf);
store.seen++;
}
break;
@@ -1102,19 +1125,19 @@ static int store_aux(const char *key, const char *value, void *cb)
* Do not increment matches: this is no match, but we
* just made sure we are in the desired section.
*/
- store.offset[store.seen] = ftell(f);
+ store.offset[store.seen] = cf->ftell(cf);
/* fallthru */
case SECTION_END_SEEN:
case START:
if (matches(key, value)) {
- store.offset[store.seen] = ftell(f);
+ store.offset[store.seen] = cf->ftell(cf);
store.state = KEY_SEEN;
store.seen++;
} else {
if (strrchr(key, '.') - key == store.baselen &&
!strncmp(key, store.key, store.baselen)) {
store.state = SECTION_SEEN;
- store.offset[store.seen] = ftell(f);
+ store.offset[store.seen] = cf->ftell(cf);
}
}
}
--
1.8.2.rc0.26.gf7384c5
^ permalink raw reply related
* [PATCH 1/4] config: factor out config file stack management
From: Heiko Voigt @ 2013-02-26 19:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann, Jeff King
In-Reply-To: <20130226193050.GA22756@sandbox-ub>
Because a config callback may start parsing a new file, the
global context regarding the current config file is stored
as a stack. Currently we only need to manage that stack from
git_config_from_file. Let's factor it out to allow new
sources of config data.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
Peff, I hope you do not mind that I totally copied your commit message
here. The patch takes a different approach though. If you like we can
add a
Commit-Message-by: Jeff King <peff@peff.net>
here :-)
Cheers Heiko
config.c | 38 ++++++++++++++++++++++++--------------
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/config.c b/config.c
index aefd80b..2c299dc 100644
--- a/config.c
+++ b/config.c
@@ -896,6 +896,28 @@ int git_default_config(const char *var, const char *value, void *dummy)
return 0;
}
+static int do_config_from(struct config_file *top, config_fn_t fn, void *data)
+{
+ int ret;
+
+ /* push config-file parsing state stack */
+ top->prev = cf;
+ top->linenr = 1;
+ top->eof = 0;
+ strbuf_init(&top->value, 1024);
+ strbuf_init(&top->var, 1024);
+ cf = top;
+
+ ret = git_parse_file(fn, data);
+
+ /* pop config-file parsing state stack */
+ strbuf_release(&top->value);
+ strbuf_release(&top->var);
+ cf = top->prev;
+
+ return ret;
+}
+
int git_config_from_file(config_fn_t fn, const char *filename, void *data)
{
int ret;
@@ -905,22 +927,10 @@ int git_config_from_file(config_fn_t fn, const char *filename, void *data)
if (f) {
config_file top;
- /* push config-file parsing state stack */
- top.prev = cf;
top.f = f;
top.name = filename;
- top.linenr = 1;
- top.eof = 0;
- strbuf_init(&top.value, 1024);
- strbuf_init(&top.var, 1024);
- cf = ⊤
-
- ret = git_parse_file(fn, data);
-
- /* pop config-file parsing state stack */
- strbuf_release(&top.value);
- strbuf_release(&top.var);
- cf = top.prev;
+
+ ret = do_config_from(&top, fn, data);
fclose(f);
}
--
1.8.2.rc0.26.gf7384c5
^ permalink raw reply related
* [PATCH 0/4] allow more sources for config values
From: Heiko Voigt @ 2013-02-26 19:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann, Jeff King
In-Reply-To: <7v4nh13plo.fsf@alter.siamese.dyndns.org>
Hi,
On Sun, Feb 24, 2013 at 09:54:43PM -0800, Junio C Hamano wrote:
> The idea to allow more kinds of sources specified for "config_file"
> structure is not bad per-se, but whenever you design an enhancement
> to something that currently supports only on thing to allow taking
> another kind, please consider what needs to be done by the next
> person who adds the third kind. That would help catch design
> mistakes early. For example, will the "string-list" (I am not
> saying use of string-list makes sense as the third kind; just as an
> example off the top of my head) source patch add
>
> int is_string_list;
> struct string_list *string_list_contents;
>
> fields to this structure? Sounds insane for at least two reasons:
>
> * if both is_strbuf and is_string_list are true, what should
> happen?
>
> * is there a good reason to waste storage for the three fields your
> patch adds when sring_list strage (or FILE * storage for that
> matter) is used?
>
> The helper functions like config_fgetc() and config_ftell() sounds
> like you are going in the right direction but may want to do the
> OO-in-C in a similar way transport.c does, keeping a pointer to a
> structure of methods, but I didn't read the remainder of this patch
> very carefully enough to comment further.
I split up my config-from-strings patch from the "fetch moved submodules
on-demand" series[1] for nicer reviewability. Since Peff almost needed it
and the recursive submodule checkout will definitely[2] need it: How
about making it a seperate topic and implement this infrastructure
first?
Junio I incorporated your comments this seems like a result ready for
inclusion.
[1] http://article.gmane.org/gmane.comp.version-control.git/217018
[2] http://article.gmane.org/gmane.comp.version-control.git/217155
Heiko Voigt (4):
config: factor out config file stack management
config: drop file pointer validity check in get_next_char()
config: make parsing stack struct independent from actual data source
teach config parsing to read from strbuf
.gitignore | 1 +
Makefile | 1 +
cache.h | 1 +
config.c | 140 ++++++++++++++++++++++++++++++++++++++-----------
t/t1300-repo-config.sh | 4 ++
test-config.c | 41 +++++++++++++++
6 files changed, 158 insertions(+), 30 deletions(-)
create mode 100644 test-config.c
--
1.8.2.rc0.26.gf7384c5
^ permalink raw reply
* Re: [PATCH 0/5] Fix msvc build
From: Ramsay Jones @ 2013-02-26 19:06 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, GIT Mailing-list, Erik Faye-Lund, Jonathan Nieder,
Johannes Schindelin
In-Reply-To: <512B2003.804@viscovery.net>
Johannes Sixt wrote:
> Am 2/25/2013 7:54, schrieb Junio C Hamano:
>> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
>>
>>> As I mentioned recently, while discussing a cygwin specific patch
>>> (see "Version 1.8.1 does not compile on Cygwin 1.7.14" thread), the
>>> MSVC build is broken for me.
>>>
>>> The first 4 patches fix the MSVC build for me. The final patch is
>>> not really related to fixing the build, but it removed some make
>>> warnings which were quite irritating ...
>>>
>>> Note that I used the Makefile, with the Visual C++ 2008 command
>>> line compiler on Windows XP (SP3), to build a vanilla git on MinGW.
>>> I'm not subscribed to the msysgit mailing list, nor do I follow the
>>> msysgit fork of git, so these patches may conflict with commits in
>>> their repository.
>>
>> Did anything further happen to this topic in the Windows land?
>
> I successfully built with MSVC with these patches (but I am not using the
> result anywhere nor did I attempt to run the test suite).
>
> More importantly, I'm using git on Windows ("MinGW flavor") with these
> patches in production, so there are no obvious regressions.
>
> Feel free to add my
>
> Tested-by: Johannes Sixt <j6t@kdbg.org>
Johannes, thank you for taking the time to test these patches.
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH] pkt-line: Fix sparse errors and warnings
From: Ramsay Jones @ 2013-02-26 18:52 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <20130223223134.GA2504@sigill.intra.peff.net>
Jeff King wrote:
> Thanks for the report. Clearly I should start running "make sparse" more
> often (the reason I don't is that it produces dozens of complaints about
> constants in /usr/include/bits/xopen_lim.h, which I could obviously care
> less about; I should look into suppressing that).
Hmm, I'm guessing you are on an 64bit system; if so, and you are running
the release version of sparse (v0.4.4 Nov 2011), I would clone the sparse
repo [1] and build from source. There have been many improvements to the
64bit support since the last release (I hear it was unusable). [Note: I
can't confirm that - I'm currently stuck on 32bits!]
ATB,
Ramsay Jones
[1] git://git.kernel.org/pub/scm/devel/sparse/sparse.git (which had been
dormant for quite some time, but sprang to life again last week).
^ permalink raw reply
* Re: [PATCH] pkt-line: Fix sparse errors and warnings
From: Ramsay Jones @ 2013-02-26 19:02 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <20130223223700.GB2504@sigill.intra.peff.net>
Jeff King wrote:
> On Sat, Feb 23, 2013 at 05:31:34PM -0500, Jeff King wrote:
>
>> On Sat, Feb 23, 2013 at 06:44:04PM +0000, Ramsay Jones wrote:
>>
>>> Sparse issues the following error and warnings:
>>>
>>> pkt-line.c:209:51: warning: Using plain integer as NULL pointer
>>> sideband.c:41:52: warning: Using plain integer as NULL pointer
>>> daemon.c:615:39: warning: Using plain integer as NULL pointer
>>> remote-curl.c:220:75: error: incompatible types for operation (>)
>>> remote-curl.c:220:75: left side has type char *
>>> remote-curl.c:220:75: right side has type int
>>> remote-curl.c:291:53: warning: Using plain integer as NULL pointer
>>> remote-curl.c:408:43: warning: Using plain integer as NULL pointer
>>> remote-curl.c:562:47: warning: Using plain integer as NULL pointer
>>>
>>> All of these complaints "blame" to commit 17243606 ("pkt-line: share
>>> buffer/descriptor reading implementation", 20-02-2013).
>>>
>>> In order to suppress the warnings, we simply replace the integer
>>> constant 0 with NULL.
>> [...]
>> Oddly, you seemed to miss the one in connect.c (which my sparse does
>> detect).
>
> Ah, I saw why as soon as I finished off the rebase: that (NULL, 0) goes
> away in the very next patch, and you probably ran sparse just on the tip
> of the topic (via pu).
Yes, sorry I should have mentioned that! Ahem, *blush* [Having created and
tested the patch (including running "make test") on the tip of pu, I applied
the patch directly to commit 17243606 (using git-am). Since it applied
cleanly and git-show looked OK, I said to myself "yep, that's OK, send it" ;-) ]
> I still think it's worth fixing since we are
> squashing anyway. Junio, it will give you a trivial conflict on patch
> 16, but you can just resolve in favor of what patch 16 does. If it's
> easier, here's the revised patch 16:
So, sorry for being a bit sloppy guys!
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH 1/1] Fix date checking in case if time was not initialized.
From: Mike Gorchak @ 2013-02-26 18:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4nh0oxnv.fsf@alter.siamese.dyndns.org>
> The test does _not_ fail. That if condition does return -1 on Linux
> and BSD, and making tm_to_time_t() return a failure, but the caller
> goes on, ending up with the right values in year/month/date in the
> tm struct, which is the primary thing the function is used for.
I said it wrong, test itself is not failed, but numerous is_date()
checks are failed due to incomplete time.
^ permalink raw reply
* Re: [PATCH] Improve QNX support in GIT
From: Mike Gorchak @ 2013-02-26 18:54 UTC (permalink / raw)
To: git
In-Reply-To: <20130226172504.GA2271@ftbfs.org>
> I don't think it's a good idea to just enable thread support. On QNX,
> once a process creates a thread, fork stops working. This breaks
> commands that create threads and then try to run other programs, such
> as "git fetch" with an https remote. If threads are enabled, I think
> that the uses of fork need to be audited and, if they can be called
> after a thread is created, fixed.
I did a quick look into the run-command.c and transport-helper.c
modules, they use pthread OR fork for external command spawning
depending on NO_PTHREAD declaration. Another fork() occurence in the
module daemon.c for daemonization and I know that it works.
^ permalink raw reply
* Re: [PATCH 1/1] Add pthread support in QNX. Do not declare NO_ macros if they can be autodetected.
From: Mike Gorchak @ 2013-02-26 18:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matt Kraai
In-Reply-To: <7vbob7lzsk.fsf@alter.siamese.dyndns.org>
> I saw Matt has comment on this patch, so I'll keep the patch out of
> 'next' for now and let you two figure it out.
Anyway in current form this patch is broken. Junio, may I ask you
about the rest patches in a separate posts, have you applied any of
them?
Thanks.
^ permalink raw reply
* Re: [PATCH] Improve QNX support in GIT
From: Mike Gorchak @ 2013-02-26 18:36 UTC (permalink / raw)
To: git
In-Reply-To: <20130226172504.GA2271@ftbfs.org>
> Is there a point to the version checking? I don't know that anyone
> has tried to build Git on QNX 4, so adding a case for it seems
> misleading.
getpagesize() was introduced in QNX 6.4.1, it is present in QNX 6.5.0
also. So at least for this version checking is requied.
> I didn't realize that QNX 6.3.2 provided getpagesize. Its header
> files don't provide a prototype, so when I saw the warning, I assumed
> it wasn't available. Since NO_GETPAGESIZE is only used by QNX, if
> it's OK to reintroduce the warning, NO_GETPAGESIZE might as well be
> removed entirely.
David asked to leave NO_GETPAGESIZE for other platform.
> I don't think it's a good idea to just enable thread support. On QNX,
> once a process creates a thread, fork stops working. This breaks
> commands that create threads and then try to run other programs, such
> as "git fetch" with an https remote. If threads are enabled, I think
> that the uses of fork need to be audited and, if they can be called
> after a thread is created, fixed.
Do you have a testcase for this (without using git codebase)? I wrote
numerous resource managers since QNX 6.0 using threads and fork()s for
daemonization in different order and never experienced a problems.
There can be issues with pipes in case of external command run.
^ permalink raw reply
* Re: state of the art with moving submodules
From: Jens Lehmann @ 2013-02-26 18:25 UTC (permalink / raw)
To: Chris Packham; +Cc: git@vger.kernel.org, Junio C Hamano, Heiko Voigt
In-Reply-To: <512C6DD2.4000208@gmail.com>
Am 26.02.2013 09:09, schrieb Chris Packham:
> At $dayjob we were discussing a potential re-org of our super-projects
> to introduce a bit of hierarchy to the submodules (at the moment it's
> fairly flat). One downside of this is the potential loss of locally
> committed work. There is also a cost in terms of additional fetching but
> we think that will be OK (fetches from local servers with smallish repos).
Local commits will be preserved iff the submodules use gitfiles, also
extra fetches won't happen in that case. This holds true as long as you
only change the path and not the name of the submodules in .gitmodules
(Which I'd strongly advise to do and is just what my upcoming "git mv"
patch will be doing, my plan is to post that as RFC rather soon).
> I was just wondering where things were at with git detecting submodule
> moving/renaming? Will our developers be able to keep any local commits
> when they happen to pull in the super-project commit that moves a commit.
Current Git detects that, but won't move the submodules work tree.
Instead you'll have the old work tree of a moved submodule still lying
around and need to call "git submodule update" to create the submodule's
work tree in the new location. Also switching back to a commit where the
submodule is still in the old location won't work at first because of
the now outdated core.worktree setting in the Git repo of the submodule,
still pointing to the new location. You'd have to delete the old
submodule work tree and use "git submodule update" to recreate it again
with proper settings. That'll somehow work while at the same time is not
terribly user friendly (but don't even think about replacing an existing
directory with tracked files with a submodule or vice versa with current
Git!).
The solution for all that is my recursive submodule update series, and
finishing that it is next on my todo list after "git mv <submodule>".
Also Heiko's recently posted "fetch moved submodules on-demand" series
is necessary for that (and the work he does about parsing a config file
from a blob is essential to create a submodule which doesn't have the
correct path in the .gitmodules file of the current work tree, this is
the major thing that doesn't work as expected in my current code).
> I think some people with older clones will suffer without the newer
> .git/modules layout but those can be manually fixed prior to the re-org.
Or maybe someone could step up to add a "to-gitfile" command to "git
submodule" which converts older submodules ;-) I'll be happy to help
and review such a patch but will concentrate on materializing recursive
submodule update for the next time.
> FYI our current stock workstation install uses git version 1.7.9.5 but
> I'm recommending we update to 1.8.x before this re-org to pick up some
> of the recent submodule improvements.
I think the stuff you need to make this transition painless (unless you
are ok with a flag day or the manual steps described above to make that
work) will not hit master that soon. While recursive update is working
for me (except for creating a submodule not in the current .gitmodules)
it still needs the config options and a ton of tests. My plan is to
bring recursive submodule update into a shape others can test and
comment on before the Git Merge in May, let's see how that plan works
out.
^ permalink raw reply
* Re: [PATCH] Improve QNX support in GIT
From: David Michael @ 2013-02-26 18:09 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: Mike Gorchak, kraai
In-Reply-To: <20130226172504.GA2271@ftbfs.org>
Hi,
On Tue, Feb 26, 2013 at 12:25 PM, Matt Kraai <kraai@ftbfs.org> wrote:
> I didn't realize that QNX 6.3.2 provided getpagesize. Its header
> files don't provide a prototype, so when I saw the warning, I assumed
> it wasn't available. Since NO_GETPAGESIZE is only used by QNX, if
> it's OK to reintroduce the warning, NO_GETPAGESIZE might as well be
> removed entirely.
I have been using this feature locally for building on z/OS USS. IBM
decided to drop the getpagesize definition by default, as it was
removed from SUSv3. There is a way to re-enable the withdrawn legacy
functions, but I'd rather this option for using sysconf(_SC_PAGESIZE)
since that is apparently the preferred method now anyway.
So, if it's not being too much trouble, I'd vote for keeping this feature.
Thanks.
David
^ permalink raw reply
* Re: [PATCH 1/1] Add pthread support in QNX. Do not declare NO_ macros if they can be autodetected.
From: Junio C Hamano @ 2013-02-26 18:01 UTC (permalink / raw)
To: Mike Gorchak; +Cc: git, Matt Kraai
In-Reply-To: <CAHXAxrO8c8=d+og7rJexY4MKyKMYrWAzFYLMLRKVqtoaB6DUdQ@mail.gmail.com>
Mike Gorchak <mike.gorchak.qnx@gmail.com> writes:
>> Also, please leave the "autodetection" out. If it is common to have
>> strcasestr (or any other) on a newer QNX, then not defining the
>> symbol NO_STRCASESTR in this file may still be the right thing to
>> do, but the justification for such a change should not be because we
>> rely on "autodetection". The defaults given in config.mak.uname is
>> primarily for people who do not use the optional ./configure script,
>> so pick the default to help the most common configuration for the
>> platform.
>
> I see. I thought configure is the only legal way to build the git and
> config.mak.uname is used to override settings produced by configure.
> But it works vice versa configure settings override config.mak.uname
> settings. Please do not commit this patch. This patch brokes QNX 6.3.2
> build.
>
>> I'd rewrite the patch like the attached, and tentatively queue the
>> patch to 'pu', but I do not use or have access to QNX myself, so you
>> may have to adjust the default set of symbols and the log message
>> and in such a case, please do re-submit a fixed version.
>
> I will re-do the patch.
>
>> Specifically, I do not know if "... and others are also supported"
>> is universally true with QNX 6; if not, we need to define NO_* for
>> them to help people who build without using the ./configure script.
>
> Ok.
I saw Matt has comment on this patch, so I'll keep the patch out of
'next' for now and let you two figure it out.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 0/2] improve-wincred-compatibility
From: Junio C Hamano @ 2013-02-26 17:29 UTC (permalink / raw)
To: kusmabite
Cc: Karsten Blees, git, msysgit, Jeff King, patthoyts,
Johannes.Schindelin
In-Reply-To: <CABPQNSZSv71_W6Y5rxo0nSBAemiiuTOyB=1Ag6txLy56BEbMFQ@mail.gmail.com>
Thanks.
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: [PATCH] Improve QNX support in GIT
From: Matt Kraai @ 2013-02-26 17:25 UTC (permalink / raw)
To: Mike Gorchak; +Cc: git
Hi Mike,
Mike Gorchak wrote:
> diff --git a/config.mak.uname b/config.mak.uname
> index 8743a6d..2d42ffe 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -527,14 +527,21 @@ ifeq ($(uname_S),QNX)
> HAVE_STRINGS_H = YesPlease
> NEEDS_SOCKET = YesPlease
> NO_FNMATCH_CASEFOLD = YesPlease
> - NO_GETPAGESIZE = YesPlease
> NO_ICONV = YesPlease
> NO_MEMMEM = YesPlease
> - NO_MKDTEMP = YesPlease
> - NO_MKSTEMPS = YesPlease
> NO_NSEC = YesPlease
> - NO_PTHREADS = YesPlease
> NO_R_TO_GCC_LINKER = YesPlease
> - NO_STRCASESTR = YesPlease
> NO_STRLCPY = YesPlease
> + # All QNX 6.x versions have pthread functions in libc
> + # and getpagesize. Leave mkstemps/mkdtemp/strcasestr for
> + # autodetection.
> + ifeq ($(shell expr "$(uname_R)" : '6\.[0-9]\.[0-9]'),5)
> + PTHREAD_LIBS = ""
> + else
> + NO_PTHREADS = YesPlease
> + NO_GETPAGESIZE = YesPlease
> + NO_STRCASESTR = YesPlease
> + NO_MKSTEMPS = YesPlease
> + NO_MKDTEMP = YesPlease
> + endif
> endif
Is there a point to the version checking? I don't know that anyone
has tried to build Git on QNX 4, so adding a case for it seems
misleading.
I didn't realize that QNX 6.3.2 provided getpagesize. Its header
files don't provide a prototype, so when I saw the warning, I assumed
it wasn't available. Since NO_GETPAGESIZE is only used by QNX, if
it's OK to reintroduce the warning, NO_GETPAGESIZE might as well be
removed entirely.
I don't think it's a good idea to just enable thread support. On QNX,
once a process creates a thread, fork stops working. This breaks
commands that create threads and then try to run other programs, such
as "git fetch" with an https remote. If threads are enabled, I think
that the uses of fork need to be audited and, if they can be called
after a thread is created, fixed.
^ permalink raw reply
* Re: [PATCH v2] Revert "compat: add strtok_r()"
From: Junio C Hamano @ 2013-02-26 17:18 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, jrnieder, b
In-Reply-To: <1361897918-8824-1-git-send-email-kusmabite@gmail.com>
Thanks.
^ permalink raw reply
* Re: Better handling of erroneous git stash save "somemessage" --keep-index
From: Junio C Hamano @ 2013-02-26 17:00 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Gunnlaugur Thor Briem, git
In-Reply-To: <vpq1uc3cagy.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> I didn't even know that multi-words messages would be allowed this way.
> That seems to me to be really weird indeed.
Yeah, but it is understandable why it was done that way, considering
taht the whole point of "stash" is to save away quickly for higher
priority interrupt. IIRC, earlier iterations of the command did not
even require you to say "save", i.e.
git stash wip: futzing with --keep-index
would have been a perfectly good invocation.
> My feeling is that "git stash save" should learn a "-m, --message"
> option analogous to the one of "git commit", and then the "message on
> the command-line" syntax could be deprecated.
>
> (One nice side effect would be that in the very long term, we may want
> to allow "git stash save -- <pathspecs>" to do a limited stash)
>
> But maybe it's not worth the effort, I don't know.
Yeah, if the user wants to be more elaborate perhaps
git checkout -b temp
git commit -m 'whatever message' -a
git checkout -
would suffice; "stash" is for smaller changes in a very tentative
nature that do not deserve such a long command sequence, so
requiring "-m" may make the command less useful.
^ permalink raw reply
* [PATCH v2] Revert "compat: add strtok_r()"
From: Erik Faye-Lund @ 2013-02-26 16:58 UTC (permalink / raw)
To: gitster; +Cc: git, jrnieder, b, Erik Faye-Lund
This reverts commit 78457bc0ccc1af8b9eb776a0b17986ebd50442bc.
commit 28c5d9e ("vcs-svn: drop string_pool") previously removed
the only call-site for strtok_r. So let's get rid of the compat
implementation as well.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
---
Makefile | 6 ------
compat/strtok_r.c | 61 -------------------------------------------------------
config.mak.uname | 2 --
configure.ac | 6 ------
git-compat-util.h | 5 -----
5 files changed, 80 deletions(-)
delete mode 100644 compat/strtok_r.c
diff --git a/Makefile b/Makefile
index 1b30d7b..6d16a52 100644
--- a/Makefile
+++ b/Makefile
@@ -98,8 +98,6 @@ all::
#
# Define NO_MKSTEMPS if you don't have mkstemps in the C library.
#
-# Define NO_STRTOK_R if you don't have strtok_r in the C library.
-#
# Define NO_FNMATCH if you don't have fnmatch in the C library.
#
# Define NO_FNMATCH_CASEFOLD if your fnmatch function doesn't have the
@@ -1202,10 +1200,6 @@ endif
ifdef NO_STRTOULL
COMPAT_CFLAGS += -DNO_STRTOULL
endif
-ifdef NO_STRTOK_R
- COMPAT_CFLAGS += -DNO_STRTOK_R
- COMPAT_OBJS += compat/strtok_r.o
-endif
ifdef NO_FNMATCH
COMPAT_CFLAGS += -Icompat/fnmatch
COMPAT_CFLAGS += -DNO_FNMATCH
diff --git a/compat/strtok_r.c b/compat/strtok_r.c
deleted file mode 100644
index 7b5d568..0000000
--- a/compat/strtok_r.c
+++ /dev/null
@@ -1,61 +0,0 @@
-/* Reentrant string tokenizer. Generic version.
- Copyright (C) 1991,1996-1999,2001,2004 Free Software Foundation, Inc.
- This file is part of the GNU C Library.
-
- The GNU C Library is free software; you can redistribute it and/or
- modify it under the terms of the GNU Lesser General Public
- License as published by the Free Software Foundation; either
- version 2.1 of the License, or (at your option) any later version.
-
- The GNU C Library is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- Lesser General Public License for more details.
-
- You should have received a copy of the GNU Lesser General Public
- License along with the GNU C Library; if not, write to the Free
- Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
- 02111-1307 USA. */
-
-#include "../git-compat-util.h"
-
-/* Parse S into tokens separated by characters in DELIM.
- If S is NULL, the saved pointer in SAVE_PTR is used as
- the next starting point. For example:
- char s[] = "-abc-=-def";
- char *sp;
- x = strtok_r(s, "-", &sp); // x = "abc", sp = "=-def"
- x = strtok_r(NULL, "-=", &sp); // x = "def", sp = NULL
- x = strtok_r(NULL, "=", &sp); // x = NULL
- // s = "abc\0-def\0"
-*/
-char *
-gitstrtok_r (char *s, const char *delim, char **save_ptr)
-{
- char *token;
-
- if (s == NULL)
- s = *save_ptr;
-
- /* Scan leading delimiters. */
- s += strspn (s, delim);
- if (*s == '\0')
- {
- *save_ptr = s;
- return NULL;
- }
-
- /* Find the end of the token. */
- token = s;
- s = strpbrk (token, delim);
- if (s == NULL)
- /* This token finishes the string. */
- *save_ptr = token + strlen (token);
- else
- {
- /* Terminate the token and make *SAVE_PTR point past it. */
- *s = '\0';
- *save_ptr = s + 1;
- }
- return token;
-}
diff --git a/config.mak.uname b/config.mak.uname
index bea34f0..7f3018f 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -321,7 +321,6 @@ ifeq ($(uname_S),Windows)
NO_UNSETENV = YesPlease
NO_STRCASESTR = YesPlease
NO_STRLCPY = YesPlease
- NO_STRTOK_R = YesPlease
NO_FNMATCH = YesPlease
NO_MEMMEM = YesPlease
# NEEDS_LIBICONV = YesPlease
@@ -476,7 +475,6 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_UNSETENV = YesPlease
NO_STRCASESTR = YesPlease
NO_STRLCPY = YesPlease
- NO_STRTOK_R = YesPlease
NO_FNMATCH = YesPlease
NO_MEMMEM = YesPlease
NEEDS_LIBICONV = YesPlease
diff --git a/configure.ac b/configure.ac
index 1991258..f3462d9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -901,12 +901,6 @@ GIT_CHECK_FUNC(strcasestr,
[NO_STRCASESTR=YesPlease])
GIT_CONF_SUBST([NO_STRCASESTR])
#
-# Define NO_STRTOK_R if you don't have strtok_r
-GIT_CHECK_FUNC(strtok_r,
-[NO_STRTOK_R=],
-[NO_STRTOK_R=YesPlease])
-GIT_CONF_SUBST([NO_STRTOK_R])
-#
# Define NO_FNMATCH if you don't have fnmatch
GIT_CHECK_FUNC(fnmatch,
[NO_FNMATCH=],
diff --git a/git-compat-util.h b/git-compat-util.h
index e5a4b74..89a44ab 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -408,11 +408,6 @@ extern uintmax_t gitstrtoumax(const char *, char **, int);
extern intmax_t gitstrtoimax(const char *, char **, int);
#endif
-#ifdef NO_STRTOK_R
-#define strtok_r gitstrtok_r
-extern char *gitstrtok_r(char *s, const char *delim, char **save_ptr);
-#endif
-
#ifdef NO_HSTRERROR
#define hstrerror githstrerror
extern const char *githstrerror(int herror);
--
1.8.0.msysgit.0.3.gd0186ec
^ permalink raw reply related
* Re: [PATCH v2 0/2] improve-wincred-compatibility
From: Erik Faye-Lund @ 2013-02-26 16:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Karsten Blees, git, msysgit, Jeff King, patthoyts,
Johannes.Schindelin
In-Reply-To: <7vip5gne96.fsf@alter.siamese.dyndns.org>
On Tue, Feb 26, 2013 at 12:51 AM, Junio C Hamano <gitster@pobox.com> wrote:
> My question was if msysgit folks
> want me to take your patch (which I cannot test myself) and then
> merge my tree to the msysgit tree as part of their regular updates
> to catch up with 1.8.2 (and future releases), or they want to test
> your patches in their tree first, and then either throw me a pull
> request or send me a patch series with Acked-by:.
The following changes since commit 4dac0679feaebbf6545daec14480cf6b94cb74ed:
Git 1.8.2-rc1 (2013-02-25 09:03:26 -0800)
are available in the git repository at:
git://github.com/kusma/git.git for-junio
for you to fetch changes up to 8b2d219a3d6db49c8c3c0a5b620af33d6a40a974:
wincred: improve compatibility with windows versions (2013-02-26
17:42:46 +0100)
----------------------------------------------------------------
Karsten Blees (2):
wincred: accept CRLF on stdin to simplify console usage
wincred: improve compatibility with windows versions
.../credential/wincred/git-credential-wincred.c | 206 ++++++++-------------
1 file changed, 75 insertions(+), 131 deletions(-)
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: [PATH/RFC] Revert "compat: add strtok_r()"
From: Erik Faye-Lund @ 2013-02-26 16:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Michael Barr, Jonathan Nieder
In-Reply-To: <7v7glw288j.fsf@alter.siamese.dyndns.org>
On Mon, Feb 25, 2013 at 7:55 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Care to tie the loose end on this one, with a sign-off?
Yes, I'll get right to it, sorry for the delay!
^ permalink raw reply
* Re: Better handling of erroneous git stash save "somemessage" --keep-index
From: Gunnlaugur Thor Briem @ 2013-02-26 16:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwqtvm4yr.fsf@alter.siamese.dyndns.org>
On Tue, Feb 26, 2013 at 4:10 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Then the user cannot say
>
> git stash save some message that consists of multiple words
>
> no? You may have a WIP to enhance the behaviour of one option and
> you might want to say
>
> git stash save wip: tweak behaviour of --keep-index
>
> to save it away when switching to higher priority task.
In this case (which must be rarer than --keep-index intended as a
parameter) the user gets the error message, the problem is pretty
clear, and the workaround is very easy, quote the message:
git stash save "wip: tweak behaviour of --keep-index"
... which also is more conventional on the command line.
To minimize the behavior change, it could apply solely for the case of
known parameters to this command (like --keep-index), so that:
git stash save wip: tweak behaviour of --froob-nob
would still work like before. That's less consistent, but then again,
this is just a matter of catching very likely errors to avoid lost
work.
Expressing a multi-word message without quotes on the command line is
unconventional (in general, though maybe not in the use of git-stash)
so it seems reasonable to let that usage be the one that gets
inconvenienced.
-Gulli
(Sorry about the initial reply to you alone Junio)
^ permalink raw reply
* Re: [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS
From: Torsten Bögershausen @ 2013-02-26 16:40 UTC (permalink / raw)
To: Mark Levedahl
Cc: Junio C Hamano, git, Jonathan Nieder, Eric Blake, Alex Riesen,
Jason Pyeron, Torsten Bögershausen,
Stephen & Linda Smith, Ramsay Jones
In-Reply-To: <512C3554.8020902@gmail.com>
On 26.02.13 05:08, Mark Levedahl wrote:
> On 02/25/2013 01:44 AM, Junio C Hamano wrote:
>> I was in "find leftover bits" mode today and found this thread hanging. Has anything come out of this thread, or there is nothing to improve in this area?
>
> The patch passed my simple tests (build, run a few commands), but I didn't get around to a full test. And of course, I am testing on current Cygwin where git compiles and runs correctly anyway.
>
> Mark
I run the test suite, and there was 1301 failing (and t0070 ?) which have
to do with POSIX permisions.
They are on my TODO stack.
/Torsten
^ 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