* [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
* [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
* 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
* 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: 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
* 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
* 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
* 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
* 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: 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
* [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
* [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 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 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 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 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 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 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 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 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 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 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] user-manual.txt: fix a few mistakes
From: Sergei Organov @ 2007-11-13 18:19 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: Sergei Organov <osv@javad.com>
---
Documentation/user-manual.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index d99adc6..a169ef0 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -475,7 +475,7 @@ Bisecting: 3537 revisions left to test after this
If you run "git branch" at this point, you'll see that git has
temporarily moved you to a new branch named "bisect". This branch
points to a commit (with commit id 65934...) that is reachable from
-v2.6.19 but not from v2.6.18. Compile and test it, and see whether
+"master" but not from v2.6.18. Compile and test it, and see whether
it crashes. Assume it does crash. Then:
-------------------------------------------------
@@ -1367,7 +1367,7 @@ If you make a commit that you later wish you hadn't, there are two
fundamentally different ways to fix the problem:
1. You can create a new commit that undoes whatever was done
- by the previous commit. This is the correct thing if your
+ by the old commit. This is the correct thing if your
mistake has already been made public.
2. You can go back and modify the old commit. You should
@@ -1567,8 +1567,8 @@ old history using, for example,
$ git log master@{1}
-------------------------------------------------
-This lists the commits reachable from the previous version of the head.
-This syntax can be used to with any git command that accepts a commit,
+This lists the commits reachable from the previous version of the branch.
+This syntax can be used with any git command that accepts a commit,
not just with git log. Some other examples:
-------------------------------------------------
--
1.5.3.4
^ permalink raw reply related
* [PATCH] git-remote.txt: fix typo
From: Sergei Organov @ 2007-11-13 18:17 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: Sergei Organov <osv@javad.com>
---
Documentation/git-remote.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 027ba11..0da8704 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -79,7 +79,7 @@ caution.
Fetch updates for a named set of remotes in the repository as defined by
remotes.<group>. If a named group is not specified on the command line,
the configuration parameter remotes.default will get used; if
-remotes.default is not defined, all remotes which do not the
+remotes.default is not defined, all remotes which do not have the
configuration parameter remote.<name>.skipDefaultUpdate set to true will
be updated. (See gitlink:git-config[1]).
--
1.5.3.4
^ permalink raw reply related
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Andreas Ericsson @ 2007-11-13 20:01 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Jakub Narebski, Sergei Organov, git
In-Reply-To: <A919E788-C5D0-4404-95D4-869BAFE868AC@zib.de>
Steffen Prohaska wrote:
>
> On Nov 13, 2007, at 5:03 PM, Jakub Narebski wrote:
>
>> Sergei Organov <osv@javad.com> wrote:
>>> Jakub Narebski <jnareb@gmail.com> writes:
>>>> Sergei Organov wrote:
>>
>>>>> I want to get rid of origin/pu remote tracking branch. What do I do?
>>>>> I RTFM git-branch. What does it suggest?
>>>>>
>>>>> git branch -d -r origin/pu
>>>>>
>>>>> So far so good. However, it doesn't seem to work in practice:
>> [...]
>>>>> $ git branch -d -r origin/pu
>>>>> Deleted remote branch origin/pu.
>>>>> $ git remote show origin
>>>>> * remote origin
>>>>> URL: git://git.kernel.org/pub/scm/git/git.git
>>>>> Remote branch(es) merged with 'git pull' while on branch master
>>>>> master
>>>>> New remote branches (next fetch will store in remotes/origin)
>>>>> pu
>>>>> ^^^^^^^^^^^^^^^^^^^ What???
>>>>> Tracked remote branches
>>>>> html maint man master next todo
>>>>
>>>> Check out what do you have in .git/config file, in the
>>>> [remote "origin"] section. Most probably (if you cloned this
>>>> repository using new enough git) you have wildcard refspec there,
>>>> which means that git would pick all new branches when
>>>> fetching / pulling from given repository.
>>>
>>> Sure, I've cloned git.git using rather recent git, so .git/config has:
>>>
>>> fetch = +refs/heads/*:refs/remotes/origin/*
>>
>> [...]
>>> Isn't "git branch -d -r" supposed to do whatever magic is required to
>>> get rid of the remote branch? Currently it seems like a bug introduced
>>> by addition of wildcards refspecs, right?
>>
>> No, the '-r' part translates 'pu' into 'refs/remotes/origin/pu', and
>> the '-d' option removes branch locally. It is meant I think to remove
>> tracking of branches which were dropped in remote, as I think that
>> wildcard refspec does create new branches, but do not delete dropped
>> branches.
>
> "git remote prune origin" should be used to clean up stale
> remote-tracking branches.
>
> BTW, what's the right name for this type of branch.
> I found "tracking branch", "remote tracking branch", and
> "remote-tracking branch" in the manual. The glossary only
> mentions "tracking branch". Or is it a "tracked remote branch"
> as the output of "git remote show" suggests. I remember,
> there was a lengthy discussion on this issue. Does someone
> remember the conclusion?
>
It seems we agreed to disagree. However, a "tracked remote branch"
is definitely not in your local repo. I think remote-tracking branch
grammatically is the most correct, as that's the only non-ambiguous
form (remote tracking branch might mean "remote tracking-branch" or
"remote-tracking branch"). It's also the only form that works when
used with "local" in front of it. "Tracked remote branch" will
always be a "remote branch", no matter how you prefix it.
I hate that part of git nomenclature with a passion. It's ambiguous
at best and, as a consequence, downright wrong for some uses.
>
>> So I'm not sure if it is a bug, misfeature or a feature.
>
> It doesn't make sense to delete remote-tracking branches
> locally if they are still present at the remote. The main
> purpose of a remote-tracking branch is to be identical to the
> real remote branch.
>
Yes, but it does make sense to say "I no longer want to track that
remote branch". If that should be implied by the user deleting its
local counterpart is, I think, what this discussion is about.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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