* [PATCH 02/11] t7501-commit.sh: Not all seds understand option -i
From: Johannes Sixt @ 2007-11-13 20:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1194984306-3181-2-git-send-email-johannes.sixt@telecom.at>
Use mv instead.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
t/t7501-commit.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 4dc35bd..38db2f2 100644
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -69,7 +69,8 @@ test_expect_success \
cat >editor <<\EOF
#!/bin/sh
-sed -i -e "s/a file/an amend commit/g" $1
+sed -e "s/a file/an amend commit/g" < $1 > $1-
+mv $1- $1
EOF
chmod 755 editor
@@ -88,7 +89,8 @@ test_expect_success \
cat >editor <<\EOF
#!/bin/sh
-sed -i -e "s/amend/older/g" $1
+sed -e "s/amend/older/g" < $1 > $1-
+mv $1- $1
EOF
chmod 755 editor
--
1.5.3.5.1592.g0d6db
^ permalink raw reply related
* [PATCH 0/11] Miscellaneous MinGW port fallout
From: Johannes Sixt @ 2007-11-13 20:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
This is a series of smallish, unrelated changes that were necessary
for the MinGW port.
[PATCH 01/11] t5300-pack-object.sh: Split the big verify-pack test into
smaller parts.
[PATCH 02/11] t7501-commit.sh: Not all seds understand option -i
[PATCH 03/11] t5302-pack-index: Skip tests of 64-bit offsets if necessary.
[PATCH 04/11] Skip t3902-quoted.sh if the file system does not support
funny names.
Some changes to the test suite.
[PATCH 05/11] Use is_absolute_path() in sha1_file.c.
[PATCH 06/11] Move #include <sys/select.h> and <sys/ioctl.h> to
git-compat-util.h.
These two are certainly undisputed.
[PATCH 07/11] builtin run_command: do not exit with -1.
Replaces exit(-1) by exit(255). I don't know if this has any bad
consequences on *nix.
[PATCH 08/11] Close files opened by lock_file() before unlinking.
This one was authored by Dscho. It is a definite MUST on Windows.
[PATCH 09/11] Allow a relative builtin template directory.
[PATCH 10/11] Introduce git_etc_gitconfig() that encapsulates access
of ETC_GITCONFIG.
[PATCH 11/11] Allow ETC_GITCONFIG to be a relative path.
These need probably some discussion. They avoid that $(prefix) is
hardcoded and so allows that an arbitrary installation directory.
Makefile | 5 ++++-
builtin-config.c | 4 ++--
builtin-init-db.c | 16 +++++++++++++---
cache.h | 2 ++
config.c | 20 ++++++++++++++++++--
git-compat-util.h | 2 ++
git.c | 2 +-
help.c | 1 -
lockfile.c | 17 ++++++++++-------
pager.c | 2 --
sha1_file.c | 8 ++++----
t/t3902-quoted.sh | 7 +++++++
t/t5300-pack-object.sh | 34 ++++++++++++++++++----------------
t/t5302-pack-index.sh | 25 +++++++++++++++++++++++--
t/t7501-commit.sh | 6 ++++--
15 files changed, 108 insertions(+), 43 deletions(-)
-- Hannes
^ permalink raw reply
* [PATCH 01/11] t5300-pack-object.sh: Split the big verify-pack test into smaller parts.
From: Johannes Sixt @ 2007-11-13 20:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1194984306-3181-1-git-send-email-johannes.sixt@telecom.at>
This makes it easier to spot which of the tests failed.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
t/t5300-pack-object.sh | 34 ++++++++++++++++++----------------
1 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh
index ba7579c..f1106e6 100755
--- a/t/t5300-pack-object.sh
+++ b/t/t5300-pack-object.sh
@@ -187,49 +187,51 @@ test_expect_success \
test-3-${packname_3}.idx'
test_expect_success \
- 'corrupt a pack and see if verify catches' \
+ 'verify-pack catches mismatched .idx and .pack files' \
'cat test-1-${packname_1}.idx >test-3.idx &&
cat test-2-${packname_2}.pack >test-3.pack &&
if git verify-pack test-3.idx
then false
else :;
- fi &&
+ fi'
- : PACK_SIGNATURE &&
- cat test-1-${packname_1}.pack >test-3.pack &&
+test_expect_success \
+ 'verify-pack catches a corrupted pack signature' \
+ 'cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=2 &&
if git verify-pack test-3.idx
then false
else :;
- fi &&
+ fi'
- : PACK_VERSION &&
- cat test-1-${packname_1}.pack >test-3.pack &&
+test_expect_success \
+ 'verify-pack catches a corrupted pack version' \
+ 'cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=7 &&
if git verify-pack test-3.idx
then false
else :;
- fi &&
+ fi'
- : TYPE/SIZE byte of the first packed object data &&
- cat test-1-${packname_1}.pack >test-3.pack &&
+test_expect_success \
+ 'verify-pack catches a corrupted type/size of the 1st packed object data' \
+ 'cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=12 &&
if git verify-pack test-3.idx
then false
else :;
- fi &&
+ fi'
- : sum of the index file itself &&
- l=`wc -c <test-3.idx` &&
+test_expect_success \
+ 'verify-pack catches a corrupted sum of the index file itself' \
+ 'l=`wc -c <test-3.idx` &&
l=`expr $l - 20` &&
cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.idx count=20 bs=1 conv=notrunc seek=$l &&
if git verify-pack test-3.pack
then false
else :;
- fi &&
-
- :'
+ fi'
test_expect_success \
'build pack index for an existing pack' \
--
1.5.3.5.1592.g0d6db
^ permalink raw reply related
* [PATCH 04/11] Skip t3902-quoted.sh if the file system does not support funny names.
From: Johannes Sixt @ 2007-11-13 20:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1194984306-3181-4-git-send-email-johannes.sixt@telecom.at>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
t/t3902-quoted.sh | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/t/t3902-quoted.sh b/t/t3902-quoted.sh
index 245fb3b..73da45f 100755
--- a/t/t3902-quoted.sh
+++ b/t/t3902-quoted.sh
@@ -20,6 +20,13 @@ LF='
'
DQ='"'
+echo foo > "Name and an${HT}HT"
+test -f "Name and an${HT}HT" || {
+ # since FAT/NTFS does not allow tabs in filenames, skip this test
+ say 'Your filesystem does not allow tabs in filenames, test skipped.'
+ test_done
+}
+
for_each_name () {
for name in \
Name "Name and a${LF}LF" "Name and an${HT}HT" "Name${DQ}" \
--
1.5.3.5.1592.g0d6db
^ permalink raw reply related
* [PATCH 03/11] t5302-pack-index: Skip tests of 64-bit offsets if necessary.
From: Johannes Sixt @ 2007-11-13 20:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1194984306-3181-3-git-send-email-johannes.sixt@telecom.at>
There are platforms where off_t is not 64 bits wide. In this case many tests
are doomed to fail. Let's skip them.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
t/t5302-pack-index.sh | 25 +++++++++++++++++++++++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/t/t5302-pack-index.sh b/t/t5302-pack-index.sh
index 4f58c4c..d93abc4 100755
--- a/t/t5302-pack-index.sh
+++ b/t/t5302-pack-index.sh
@@ -61,17 +61,33 @@ test_expect_success \
test_expect_success \
'index v2: force some 64-bit offsets with pack-objects' \
- 'pack3=$(git pack-objects --index-version=2,0x40000 test-3 <obj-list) &&
- git verify-pack -v "test-3-${pack3}.pack"'
+ 'pack3=$(git pack-objects --index-version=2,0x40000 test-3 <obj-list)'
+
+have_64bits=
+if msg=$(git verify-pack -v "test-3-${pack3}.pack" 2>&1) ||
+ ! echo "$msg" | grep "pack too large .* off_t"
+then
+ have_64bits=t
+else
+ say "skipping tests concerning 64-bit offsets"
+fi
+
+test "$have_64bits" &&
+test_expect_success \
+ 'index v2: verify a pack with some 64-bit offsets' \
+ 'git verify-pack -v "test-3-${pack3}.pack"'
+test "$have_64bits" &&
test_expect_failure \
'64-bit offsets: should be different from previous index v2 results' \
'cmp "test-2-${pack2}.idx" "test-3-${pack3}.idx"'
+test "$have_64bits" &&
test_expect_success \
'index v2: force some 64-bit offsets with index-pack' \
'git-index-pack --index-version=2,0x40000 -o 3.idx "test-1-${pack1}.pack"'
+test "$have_64bits" &&
test_expect_success \
'64-bit offsets: index-pack result should match pack-objects one' \
'cmp "test-3-${pack3}.idx" "3.idx"'
@@ -113,6 +129,7 @@ test_expect_failure \
'[index v1] 6) newly created pack is BAD !' \
'git verify-pack -v "test-4-${pack1}.pack"'
+test "$have_64bits" &&
test_expect_success \
'[index v2] 1) stream pack to repository' \
'rm -f .git/objects/pack/* &&
@@ -122,6 +139,7 @@ test_expect_success \
cmp "test-1-${pack1}.pack" ".git/objects/pack/pack-${pack1}.pack" &&
cmp "test-3-${pack1}.idx" ".git/objects/pack/pack-${pack1}.idx"'
+test "$have_64bits" &&
test_expect_success \
'[index v2] 2) create a stealth corruption in a delta base reference' \
'# this test assumes a delta smaller than 16 bytes at the end of the pack
@@ -134,14 +152,17 @@ test_expect_success \
bs=1 count=20 conv=notrunc &&
git cat-file blob "$delta_sha1" > blob_4 )'
+test "$have_64bits" &&
test_expect_failure \
'[index v2] 3) corrupted delta happily returned wrong data' \
'cmp blob_3 blob_4'
+test "$have_64bits" &&
test_expect_failure \
'[index v2] 4) confirm that the pack is actually corrupted' \
'git fsck --full $commit'
+test "$have_64bits" &&
test_expect_failure \
'[index v2] 5) pack-objects refuses to reuse corrupted data' \
'git pack-objects test-5 <obj-list'
--
1.5.3.5.1592.g0d6db
^ permalink raw reply related
* [PATCH 05/11] Use is_absolute_path() in sha1_file.c.
From: Johannes Sixt @ 2007-11-13 20:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1194984306-3181-5-git-send-email-johannes.sixt@telecom.at>
There are some places that test for an absolute path. Use the helper
function to ease porting.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
sha1_file.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index f007874..560c0e0 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -86,7 +86,7 @@ int safe_create_leading_directories(char *path)
char *pos = path;
struct stat st;
- if (*pos == '/')
+ if (is_absolute_path(path))
pos++;
while (pos) {
@@ -253,7 +253,7 @@ static int link_alt_odb_entry(const char * entry, int len, const char * relative
int entlen = pfxlen + 43;
int base_len = -1;
- if (*entry != '/' && relative_base) {
+ if (!is_absolute_path(entry) && relative_base) {
/* Relative alt-odb */
if (base_len < 0)
base_len = strlen(relative_base) + 1;
@@ -262,7 +262,7 @@ static int link_alt_odb_entry(const char * entry, int len, const char * relative
}
ent = xmalloc(sizeof(*ent) + entlen);
- if (*entry != '/' && relative_base) {
+ if (!is_absolute_path(entry) && relative_base) {
memcpy(ent->base, relative_base, base_len - 1);
ent->base[base_len - 1] = '/';
memcpy(ent->base + base_len, entry, len);
@@ -333,7 +333,7 @@ static void link_alt_odb_entries(const char *alt, const char *ep, int sep,
while (cp < ep && *cp != sep)
cp++;
if (last != cp) {
- if ((*last != '/') && depth) {
+ if (!is_absolute_path(last) && depth) {
error("%s: ignoring relative alternate object store %s",
relative_base, last);
} else {
--
1.5.3.5.1592.g0d6db
^ permalink raw reply related
* [PATCH 08/11] Close files opened by lock_file() before unlinking.
From: Johannes Sixt @ 2007-11-13 20:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1194984306-3181-8-git-send-email-johannes.sixt@telecom.at>
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
This is needed on Windows since open files cannot be unlinked.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
This was authored by Dscho, but carries only my sign-off.
Is this ok?
cache.h | 1 +
lockfile.c | 17 ++++++++++-------
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/cache.h b/cache.h
index f0a25c7..28870c5 100644
--- a/cache.h
+++ b/cache.h
@@ -284,6 +284,7 @@ extern int refresh_index(struct index_state *, unsigned int flags, const char **
struct lock_file {
struct lock_file *next;
+ int fd;
pid_t owner;
char on_list;
char filename[PATH_MAX];
diff --git a/lockfile.c b/lockfile.c
index 9a1f64d..258fb3f 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -12,8 +12,10 @@ static void remove_lock_file(void)
while (lock_file_list) {
if (lock_file_list->owner == me &&
- lock_file_list->filename[0])
+ lock_file_list->filename[0]) {
+ close(lock_file_list->fd);
unlink(lock_file_list->filename);
+ }
lock_file_list = lock_file_list->next;
}
}
@@ -120,8 +122,6 @@ static char *resolve_symlink(char *p, size_t s)
static int lock_file(struct lock_file *lk, const char *path)
{
- int fd;
-
if (strlen(path) >= sizeof(lk->filename)) return -1;
strcpy(lk->filename, path);
/*
@@ -130,8 +130,8 @@ static int lock_file(struct lock_file *lk, const char *path)
*/
resolve_symlink(lk->filename, sizeof(lk->filename)-5);
strcat(lk->filename, ".lock");
- fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
- if (0 <= fd) {
+ lk->fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
+ if (0 <= lk->fd) {
if (!lock_file_list) {
signal(SIGINT, remove_lock_file_on_signal);
atexit(remove_lock_file);
@@ -148,7 +148,7 @@ static int lock_file(struct lock_file *lk, const char *path)
}
else
lk->filename[0] = 0;
- return fd;
+ return lk->fd;
}
int hold_lock_file_for_update(struct lock_file *lk, const char *path, int die_on_error)
@@ -163,6 +163,7 @@ int commit_lock_file(struct lock_file *lk)
{
char result_file[PATH_MAX];
int i;
+ close(lk->fd);
strcpy(result_file, lk->filename);
i = strlen(result_file) - 5; /* .lock */
result_file[i] = 0;
@@ -194,7 +195,9 @@ int commit_locked_index(struct lock_file *lk)
void rollback_lock_file(struct lock_file *lk)
{
- if (lk->filename[0])
+ if (lk->filename[0]) {
+ close(lk->fd);
unlink(lk->filename);
+ }
lk->filename[0] = 0;
}
--
1.5.3.5.1592.g0d6db
^ permalink raw reply related
* [PATCH 06/11] Move #include <sys/select.h> and <sys/ioctl.h> to git-compat-util.h.
From: Johannes Sixt @ 2007-11-13 20:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1194984306-3181-6-git-send-email-johannes.sixt@telecom.at>
... since all system headers are pulled in via git-compat-util.h
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
git-compat-util.h | 2 ++
help.c | 1 -
| 2 --
3 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 7b29d1b..6a8b592 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -52,6 +52,8 @@
#include <fnmatch.h>
#include <sys/poll.h>
#include <sys/socket.h>
+#include <sys/ioctl.h>
+#include <sys/select.h>
#include <assert.h>
#include <regex.h>
#include <netinet/in.h>
diff --git a/help.c b/help.c
index 8217d97..d340b6a 100644
--- a/help.c
+++ b/help.c
@@ -7,7 +7,6 @@
#include "builtin.h"
#include "exec_cmd.h"
#include "common-cmds.h"
-#include <sys/ioctl.h>
/* most GUI terminals set COLUMNS (although some don't export it) */
static int term_columns(void)
--git a/pager.c b/pager.c
index 8bac9d9..fb7a1a6 100644
--- a/pager.c
+++ b/pager.c
@@ -1,7 +1,5 @@
#include "cache.h"
-#include <sys/select.h>
-
/*
* This is split up from the rest of git so that we might do
* something different on Windows, for example.
--
1.5.3.5.1592.g0d6db
^ permalink raw reply related
* [PATCH 07/11] builtin run_command: do not exit with -1.
From: Johannes Sixt @ 2007-11-13 20:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1194984306-3181-7-git-send-email-johannes.sixt@telecom.at>
There are shells that do not correctly detect an exit code of -1 as a
failure. We simply truncate the status code to the lower 8 bits.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
git.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git.c b/git.c
index 4a250f7..37d99d6 100644
--- a/git.c
+++ b/git.c
@@ -256,7 +256,7 @@ static int run_command(struct cmd_struct *p, int argc, const char **argv)
status = p->fn(argc, argv, prefix);
if (status)
- return status;
+ return status & 0xff;
/* Somebody closed stdout? */
if (fstat(fileno(stdout), &st))
--
1.5.3.5.1592.g0d6db
^ permalink raw reply related
* [PATCH 09/11] Allow a relative builtin template directory.
From: Johannes Sixt @ 2007-11-13 20:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1194984306-3181-9-git-send-email-johannes.sixt@telecom.at>
In order to make git relocatable (i.e. not have the prefix compiled-in)
the template directory must depend on the location where this git instance
is found, which is GIT_EXEC_DIR.
The exec path is prepended only if the compiled-in default template
directory is to be used and that is relative. Any relative directories
that are specified via environment variable or the --exec-dir switch are
taken as is.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
builtin-init-db.c | 16 +++++++++++++---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 763fa55..e1393b8 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -5,6 +5,7 @@
*/
#include "cache.h"
#include "builtin.h"
+#include "exec_cmd.h"
#ifndef DEFAULT_GIT_TEMPLATE_DIR
#define DEFAULT_GIT_TEMPLATE_DIR "/usr/share/git-core/templates"
@@ -131,10 +132,19 @@ static void copy_templates(const char *git_dir, int len, const char *template_di
int template_len;
DIR *dir;
- if (!template_dir) {
+ if (!template_dir)
template_dir = getenv(TEMPLATE_DIR_ENVIRONMENT);
- if (!template_dir)
- template_dir = DEFAULT_GIT_TEMPLATE_DIR;
+ if (!template_dir) {
+ /*
+ * if the hard-coded template is relative, it is
+ * interpreted relative to the exec_dir
+ */
+ template_dir = DEFAULT_GIT_TEMPLATE_DIR;
+ if (!is_absolute_path(template_dir)) {
+ const char *exec_path = git_exec_path();
+ template_dir = prefix_path(exec_path, strlen(exec_path),
+ template_dir);
+ }
}
strcpy(template_path, template_dir);
template_len = strlen(template_path);
--
1.5.3.5.1592.g0d6db
^ permalink raw reply related
* [PATCH 10/11] Introduce git_etc_gitconfig() that encapsulates access of ETC_GITCONFIG.
From: Johannes Sixt @ 2007-11-13 20:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1194984306-3181-10-git-send-email-johannes.sixt@telecom.at>
In a subsequent patch the path to the system-wide config file will be
computed. This is a preparation for that change. It turns all accesses
of ETC_GITCONFIG into function calls. There is no change in behavior.
As a consequence, config.c is the only file that needs the definition of
ETC_GITCONFIG. Hence, -DETC_GITCONFIG is removed from the CFLAGS and a
special build rule for config.c is introduced. As a side-effect, changing
the defintion of ETC_GITCONFIG (e.g. in config.mak) does not trigger a
complete rebuild anymore.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Makefile | 5 ++++-
builtin-config.c | 4 ++--
cache.h | 1 +
config.c | 9 +++++++--
4 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index 18c61f3..e32f07e 100644
--- a/Makefile
+++ b/Makefile
@@ -752,7 +752,7 @@ TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
LIBS = $(GITLIBS) $(EXTLIBS)
BASIC_CFLAGS += -DSHA1_HEADER='$(SHA1_HEADER_SQ)' \
- -DETC_GITCONFIG='"$(ETC_GITCONFIG_SQ)"' $(COMPAT_CFLAGS)
+ $(COMPAT_CFLAGS)
LIB_OBJS += $(COMPAT_OBJS)
ALL_CFLAGS += $(BASIC_CFLAGS)
@@ -901,6 +901,9 @@ exec_cmd.o: exec_cmd.c GIT-CFLAGS
builtin-init-db.o: builtin-init-db.c GIT-CFLAGS
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) -DDEFAULT_GIT_TEMPLATE_DIR='"$(template_dir_SQ)"' $<
+config.o: config.c GIT-CFLAGS
+ $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) -DETC_GITCONFIG='"$(ETC_GITCONFIG_SQ)"' $<
+
http.o: http.c GIT-CFLAGS
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) -DGIT_USER_AGENT='"git/$(GIT_VERSION)"' $<
diff --git a/builtin-config.c b/builtin-config.c
index e5e243f..f672c9c 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -81,7 +81,7 @@ static int get_value(const char* key_, const char* regex_)
local = repo_config = xstrdup(git_path("config"));
if (home)
global = xstrdup(mkpath("%s/.gitconfig", home));
- system_wide = ETC_GITCONFIG;
+ system_wide = git_etc_gitconfig();
}
key = xstrdup(key_);
@@ -191,7 +191,7 @@ int cmd_config(int argc, const char **argv, const char *prefix)
}
}
else if (!strcmp(argv[1], "--system"))
- setenv(CONFIG_ENVIRONMENT, ETC_GITCONFIG, 1);
+ setenv(CONFIG_ENVIRONMENT, git_etc_gitconfig(), 1);
else if (!strcmp(argv[1], "--file") || !strcmp(argv[1], "-f")) {
if (argc < 3)
usage(git_config_set_usage);
diff --git a/cache.h b/cache.h
index 28870c5..0eb7b43 100644
--- a/cache.h
+++ b/cache.h
@@ -551,6 +551,7 @@ extern int git_config_bool(const char *, const char *);
extern int git_config_set(const char *, const char *);
extern int git_config_set_multivar(const char *, const char *, const char *, int);
extern int git_config_rename_section(const char *, const char *);
+extern const char *git_etc_gitconfig(void);
extern int check_repository_format_version(const char *var, const char *value);
#define MAX_GITNAME (1000)
diff --git a/config.c b/config.c
index dc3148d..dd7e9ad 100644
--- a/config.c
+++ b/config.c
@@ -452,6 +452,11 @@ int git_config_from_file(config_fn_t fn, const char *filename)
return ret;
}
+const char *git_etc_gitconfig(void)
+{
+ return ETC_GITCONFIG;
+}
+
int git_config(config_fn_t fn)
{
int ret = 0;
@@ -464,8 +469,8 @@ int git_config(config_fn_t fn)
* config file otherwise. */
filename = getenv(CONFIG_ENVIRONMENT);
if (!filename) {
- if (!access(ETC_GITCONFIG, R_OK))
- ret += git_config_from_file(fn, ETC_GITCONFIG);
+ if (!access(git_etc_gitconfig(), R_OK))
+ ret += git_config_from_file(fn, git_etc_gitconfig());
home = getenv("HOME");
filename = getenv(CONFIG_LOCAL_ENVIRONMENT);
if (!filename)
--
1.5.3.5.1592.g0d6db
^ permalink raw reply related
* [PATCH 11/11] Allow ETC_GITCONFIG to be a relative path.
From: Johannes Sixt @ 2007-11-13 20:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1194984306-3181-11-git-send-email-johannes.sixt@telecom.at>
If ETC_GITCONFIG is not an absolute path, interpret it relative to
--exec-dir. This makes the installed binaries relocatable because the
prefix is not compiled-in.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
config.c | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/config.c b/config.c
index dd7e9ad..9f014bb 100644
--- a/config.c
+++ b/config.c
@@ -6,6 +6,7 @@
*
*/
#include "cache.h"
+#include "exec_cmd.h"
#define MAXNAME (256)
@@ -454,7 +455,17 @@ int git_config_from_file(config_fn_t fn, const char *filename)
const char *git_etc_gitconfig(void)
{
- return ETC_GITCONFIG;
+ static const char *system_wide;
+ if (!system_wide) {
+ system_wide = ETC_GITCONFIG;
+ if (!is_absolute_path(system_wide)) {
+ /* interpret path relative to exec-dir */
+ const char *exec_path = git_exec_path();
+ system_wide = prefix_path(exec_path, strlen(exec_path),
+ system_wide);
+ }
+ }
+ return system_wide;
}
int git_config(config_fn_t fn)
--
1.5.3.5.1592.g0d6db
^ permalink raw reply related
* Re: wishlist: git info
From: Junio C Hamano @ 2007-11-13 20:06 UTC (permalink / raw)
To: Thomas Neumann; +Cc: Johannes Schindelin, git
In-Reply-To: <4739F9F7.20407@users.sourceforge.net>
Thomas Neumann <tneumann@users.sourceforge.net> writes:
>> I haven't spoken in this thread because honestly I found most of
>> the things mentioned here were totally uninteresting.
>
> sorry for this. While I find it useful, this is certainly not an
> important feature, and I can mimic it now myself.
Don't get me wrong. My not finding it useful does not mean it
won't be useful in the git user comminity in general. It just
means I do not have a useful input to the discussion.
^ permalink raw reply
* Re: [PATCH 0/11] Miscellaneous MinGW port fallout
From: Johannes Sixt @ 2007-11-13 20:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1194984306-3181-1-git-send-email-johannes.sixt@telecom.at>
On Tuesday 13 November 2007 21:04, Johannes Sixt wrote:
> [PATCH 09/11] Allow a relative builtin template directory.
> [PATCH 10/11] Introduce git_etc_gitconfig() that encapsulates access
> of ETC_GITCONFIG.
> [PATCH 11/11] Allow ETC_GITCONFIG to be a relative path.
>
> These need probably some discussion. They avoid that $(prefix) is
> hardcoded and so allows that an arbitrary installation directory.
... and so allow that the compiled binaries are installed in any directory
that the user chooses.
-- Hannes
^ permalink raw reply
* Re: [PATCH/RFC 1/3] send-pack: track errors for each ref
From: Alex Riesen @ 2007-11-13 20:18 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Pierre Habouzit, Daniel Barkalow
In-Reply-To: <20071113102709.GA2905@sigill.intra.peff.net>
Jeff King, Tue, Nov 13, 2007 11:27:09 +0100:
> Instead of keeping the 'ret' variable, we instead have a
> status flag for each ref that tracks what happened to it.
> We then print the ref status after all of the refs have
> been examined.
It wont apply to current master. How ready is built-in send-pack/push?
Should I fix send-pack.c properly?
^ permalink raw reply
* Integrating with hooks
From: Todd A. Jacobs @ 2007-11-13 17:37 UTC (permalink / raw)
To: git
I've created some bash functions which handle tagging some files with
revision information, but even after reading the git manual I'm not
really sure how to integrate them so that they remove revision expansion
before each check-in (to avoid cluttering the repository with keyword
substitutions), and add them back (with the current commit info) after
each commit.
These are the functions:
# Show some kind of useful revision string, like the RCS $Id$ string. I
# think commit hash, filename, hostname containing the repository, and
# timestamp should be plenty of information to track down a given file.
git-id () {
for file in "$@"; do
_date=$(date +'%F %T %Z')
git log -1 \
--pretty=format:"[%h] \"$file\" $(hostname -f) ($_date)" \
"$file"
done
}
# Replace the $Id$ keyword string in the file itself.
git-export () {
for file in "$@"; do
echo Modifying $file...
_id=$(git-id "$file")
sed -ri 's/\$(Id|Revision).*\$/$Id: '"$_id"' $/' "$file"
done
}
# Clean the $Id$ keyword string to prevent cluttering the repository
# with keyword-revision diffs when we check the file back in.
git-unexport () {
for file in "$@"; do
echo Resetting $file...
sed -ri 's/\$Id.*\$/$Id$/' "$file"
done
}
How do I hook this in the way I want so that it's handled automatically?
--
"Oh, look: rocks!"
-- Doctor Who, "Destiny of the Daleks"
^ permalink raw reply
* Strange "beagle" interaction..
From: Linus Torvalds @ 2007-11-13 20:56 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List; +Cc: Johannes Schindelin
Ok, I've made a bugzilla entry for this for the Fedora people, but I
thought I'd mention something I noticed yesterday but only tracked down
today: it seems like the beagle file indexing code is able to screw up git
in subtle ways.
I do not know exactly what happens, but the symptoms are random (and
quite hard-to-trigger) dirty index contents where git believes that some
set of files are not clean in the index.
I *suspect* that beagle is playing games with the file access times,
causing the ctime on disk to not match the ce_ctime in the index file. But
that's just a guess.
I'm posting here in case somebody on the list knows what beagle does, or
somebody has been bitten by strange behaviour and realizes that he has
beagle running and prefers to fix the problem by just disabling beagle
(which will also be a great boon for performance - beagle seems to be very
good at flushing your file caches, but I guess that's not a bug, but a
"feature").
The easiest way I have found so far to trigger this is to run
while ./t7003-filter-branch.sh -i; do echo ok; done
in the git t/ directory, while at the same time telling beagle to index
just that git/t/ directory. That seems to trigger a failure on subtest 17
fairly reliably (not the first time through the loop, but *eventually* -
it takes a few minutes). I think it's because "git filter-branch" requires
the index to be clean.
(But I've also seen it fail on subtest 4).
I opened bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=380791
for this, since I consider it a beagle bug (indexing shouldn't change
directory state, and if beagle wants to avoid changing access times, it
should use O_NOATIME). But I don't actually know exactly what it is that
causes problems, so if somebody is interested and tries to figure this
out, that would probably be good.
Linus
^ permalink raw reply
* Re: Strange "beagle" interaction..
From: J. Bruce Fields @ 2007-11-13 21:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List, Johannes Schindelin
In-Reply-To: <alpine.LFD.0.9999.0711131241050.2786@woody.linux-foundation.org>
On Tue, Nov 13, 2007 at 12:56:19PM -0800, Linus Torvalds wrote:
>
> Ok, I've made a bugzilla entry for this for the Fedora people, but I
> thought I'd mention something I noticed yesterday but only tracked down
> today: it seems like the beagle file indexing code is able to screw up git
> in subtle ways.
>
> I do not know exactly what happens, but the symptoms are random (and
> quite hard-to-trigger) dirty index contents where git believes that some
> set of files are not clean in the index.
>
> I *suspect* that beagle is playing games with the file access times,
> causing the ctime on disk to not match the ce_ctime in the index file. But
> that's just a guess.
>
> I'm posting here in case somebody on the list knows what beagle does, or
> somebody has been bitten by strange behaviour and realizes that he has
> beagle running and prefers to fix the problem by just disabling beagle
> (which will also be a great boon for performance - beagle seems to be very
> good at flushing your file caches, but I guess that's not a bug, but a
> "feature").
Last I ran across this, I believe I found it was adding extended
attributes to the file. I think it's something like
getfattr -d
to show all the extended attributes set on the file. Does that show
anything?
Yeah, I just turned off beagle. It looked to me like it was doing
something wrongheaded.
--b.
>
> The easiest way I have found so far to trigger this is to run
>
> while ./t7003-filter-branch.sh -i; do echo ok; done
>
> in the git t/ directory, while at the same time telling beagle to index
> just that git/t/ directory. That seems to trigger a failure on subtest 17
> fairly reliably (not the first time through the loop, but *eventually* -
> it takes a few minutes). I think it's because "git filter-branch" requires
> the index to be clean.
>
> (But I've also seen it fail on subtest 4).
>
> I opened bugzilla
>
> https://bugzilla.redhat.com/show_bug.cgi?id=380791
>
> for this, since I consider it a beagle bug (indexing shouldn't change
> directory state, and if beagle wants to avoid changing access times, it
> should use O_NOATIME). But I don't actually know exactly what it is that
> causes problems, so if somebody is interested and tries to figure this
> out, that would probably be good.
>
> Linus
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 08/11] Close files opened by lock_file() before unlinking.
From: Johannes Schindelin @ 2007-11-13 21:05 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <1194984306-3181-9-git-send-email-johannes.sixt@telecom.at>
Hi,
On Tue, 13 Nov 2007, Johannes Sixt wrote:
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> This is needed on Windows since open files cannot be unlinked.
>
> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
> ---
>
> This was authored by Dscho, but carries only my sign-off.
> Is this ok?
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
BTW: Hannes, many thanks for your efforts. Much appreciated.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/11] Miscellaneous MinGW port fallout
From: Junio C Hamano @ 2007-11-13 21:10 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200711132110.29136.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> On Tuesday 13 November 2007 21:04, Johannes Sixt wrote:
>> [PATCH 09/11] Allow a relative builtin template directory.
>> [PATCH 10/11] Introduce git_etc_gitconfig() that encapsulates access
>> of ETC_GITCONFIG.
>> [PATCH 11/11] Allow ETC_GITCONFIG to be a relative path.
>>
>> These need probably some discussion. They avoid that $(prefix) is
>> hardcoded and so allows that an arbitrary installation directory.
>
> ... and so allow that the compiled binaries are installed in any directory
> that the user chooses.
If you can do that without breaking the tests (specifically, the
test script should pick up the version of git you just built,
not from /usr/bin nor /usr/local/stow/git/bin) that would be
great.
^ permalink raw reply
* [PATCH 1/2] t/t3404: fix test for a bogus todo file.
From: Junio C Hamano @ 2007-11-13 21:14 UTC (permalink / raw)
To: git
The test wants to see if there are still remaining tasks, but checked
a wrong file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t3404-rebase-interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 1113904..f1039d1 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -149,7 +149,7 @@ test_expect_success 'stop on conflicting pick' '
diff -u expect .git/.dotest-merge/patch &&
diff -u expect2 file1 &&
test 4 = $(grep -v "^#" < .git/.dotest-merge/done | wc -l) &&
- test 0 = $(grep -v "^#" < .git/.dotest-merge/todo | wc -l)
+ test 0 = $(grep -v "^#" < .git/.dotest-merge/git-rebase-todo | wc -l)
'
test_expect_success 'abort' '
--
1.5.3.5.1728.g34b3e
^ permalink raw reply related
* [PATCH] revert/cherry-pick: allow starting from dirty work tree.
From: Junio C Hamano @ 2007-11-13 21:16 UTC (permalink / raw)
To: git
There is no reason to forbid a dirty work tree when reverting or
cherry-picking a change, as long as the index is clean.
The scripted version used to allow it:
case "$no_commit" in
t)
# We do not intend to commit immediately. We just want to
# merge the differences in.
head=$(git-write-tree) ||
die "Your index file is unmerged."
;;
*)
head=$(git-rev-parse --verify HEAD) ||
die "You do not have a valid HEAD"
files=$(git-diff-index --cached --name-only $head) || exit
if [ "$files" ]; then
die "Dirty index: cannot $me (dirty: $files)"
fi
;;
esac
but C rewrite tightened the check, probably by mistake.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-revert.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-revert.c b/builtin-revert.c
index cef7147..f704197 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -272,7 +272,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
if (get_sha1("HEAD", head))
die ("You do not have a valid HEAD");
wt_status_prepare(&s);
- if (s.commitable || s.workdir_dirty)
+ if (s.commitable)
die ("Dirty index: cannot %s", me);
discard_cache();
}
--
1.5.3.5.1728.g34b3e
^ permalink raw reply related
* Re: Strange "beagle" interaction..
From: J. Bruce Fields @ 2007-11-13 21:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List, Johannes Schindelin
In-Reply-To: <20071113210354.GD22590@fieldses.org>
On Tue, Nov 13, 2007 at 04:03:54PM -0500, J. Bruce Fields wrote:
> On Tue, Nov 13, 2007 at 12:56:19PM -0800, Linus Torvalds wrote:
> >
> > Ok, I've made a bugzilla entry for this for the Fedora people, but I
> > thought I'd mention something I noticed yesterday but only tracked down
> > today: it seems like the beagle file indexing code is able to screw up git
> > in subtle ways.
> >
> > I do not know exactly what happens, but the symptoms are random (and
> > quite hard-to-trigger) dirty index contents where git believes that some
> > set of files are not clean in the index.
> >
> > I *suspect* that beagle is playing games with the file access times,
> > causing the ctime on disk to not match the ce_ctime in the index file. But
> > that's just a guess.
> >
> > I'm posting here in case somebody on the list knows what beagle does, or
> > somebody has been bitten by strange behaviour and realizes that he has
> > beagle running and prefers to fix the problem by just disabling beagle
> > (which will also be a great boon for performance - beagle seems to be very
> > good at flushing your file caches, but I guess that's not a bug, but a
> > "feature").
>
> Last I ran across this, I believe I found it was adding extended
> attributes to the file. I think it's something like
>
> getfattr -d
>
> to show all the extended attributes set on the file. Does that show
> anything?
By the way, on Debian or Ubuntu, at least, that requires an "apt-get
install attr" first.
>
> Yeah, I just turned off beagle. It looked to me like it was doing
> something wrongheaded.
Just looking at the attribute names and taking a wild guess, it looked
to me like beagle was computing a checksum of each file's data and
comparing it to a checksum previously stored in an xattr, and using that
to decide whether to reindex the file data.
With the result that to check whether anything's changed when it starts
up again it has to read through the entire filesystem's data.
Maybe I'm wrong--I hope so. I'd love to know.
--b.
^ permalink raw reply
* Re: [PATCH 10/11] Introduce git_etc_gitconfig() that encapsulates access of ETC_GITCONFIG.
From: Johannes Schindelin @ 2007-11-13 21:22 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <1194984306-3181-11-git-send-email-johannes.sixt@telecom.at>
Hi,
On Tue, 13 Nov 2007, Johannes Sixt wrote:
> diff --git a/config.c b/config.c
> index dc3148d..dd7e9ad 100644
> --- a/config.c
> +++ b/config.c
> @@ -452,6 +452,11 @@ int git_config_from_file(config_fn_t fn, const char *filename)
> return ret;
> }
>
> +const char *git_etc_gitconfig(void)
> +{
> + return ETC_GITCONFIG;
> +}
> +
Wouldn't this logically belong into environment.c?
Ciao,
Dscho
^ permalink raw reply
* Re: wishlist: git info
From: Alex Riesen @ 2007-11-13 21:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Neumann, git
In-Reply-To: <Pine.LNX.4.64.0711131111220.4362@racer.site>
Johannes Schindelin, Tue, Nov 13, 2007 12:13:59 +0100:
> > I use an alias with the commands proposed by Alex Riessen for now, but a
> > more general command would be nice.
>
> His name is "Riesen", just like in the German translation of the famous
> Newton statement.
now I am misspelled. How should I feel?...
^ 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