* Re: rerere: how to remove an erroneous resolution?
From: Jeff King @ 2009-01-26 21:11 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <20090126151326.GA2618@neumann>
On Mon, Jan 26, 2009 at 04:13:26PM +0100, SZEDER Gábor wrote:
> On Mon, Jan 26, 2009 at 03:42:39PM +0100, SZEDER Gábor wrote:
> > some time ago I mistakenly resolved a merge conflict incorrectly. Of
> > course, rerere noted the erroneous conflict resolution, and whenever
> > the same merge conflict occurs rerere offers me that erroneous
> > conflict resolution, even though I correct it each time.
> >
> > So, the question is how could I make rerere forget that particular
> > merge conflict resolution? Is it at all possible?
>
> Ok, I should have investigated a little longer before sending that
> email.
Hmm. I have never actually used rerere in a real setting, so I am
somewhat clueless. But from your description, it sounds like it would
make sense for it to update the resolution to the latest one used. If
you changed it, it was probably to correct it; you would have no need to
make a change to break an already-working resolution.
Then you would not have had to go mucking about in .git.
-Peff
^ permalink raw reply
* Re: [PATCH] rebase -i: correctly remember --root flag across --continue
From: Jeff King @ 2009-01-26 21:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Johannes Schindelin
In-Reply-To: <20090126210942.GH27604@coredump.intra.peff.net>
On Mon, Jan 26, 2009 at 04:09:42PM -0500, Jeff King wrote:
> > Maybe I am misrecalling things but didn't we have reports from people on
> > some platforms that single-shot exporting of the environment like this one
> > does not work for them?
>
> I don't think you are misrecalling. The problem is with one-shot
> variables and functional calls. See 09b78bc1.
Err, _function_ calls. Need sleep badly.
-Peff
^ permalink raw reply
* [PATCH/RFC v1 0/6] git checkout: more cleanups, optimisation, less lstat() calls
From: Kjetil Barvik @ 2009-01-26 21:17 UTC (permalink / raw)
To: git; +Cc: Kjetil Barvik
Here is 6 small patches which should further improve the time it take
to do 'git checkout'. After the 6 patches, the numbers from the 'git
checkout -q my-v2.6.27' test, should now look like this:
TOTAL 136752 100.000% OK:124567 NOT: 12185 8.641698 sec 63 usec/call
lstat64 55502 40.586% OK: 49122 NOT: 6380 2.463762 sec 44 usec/call
strings 55502 tot 30163 uniq 1.840 /uniq 2.463762 sec 44 usec/call
files 47122 tot 23813 uniq 1.979 /uniq 2.070486 sec 44 usec/call
dirs 2000 tot 1436 uniq 1.393 /uniq 0.087281 sec 44 usec/call
errors 6380 tot 5187 uniq 1.230 /uniq 0.305995 sec 48 usec/call
4 0.007% OK: 3 NOT: 1 "arch/sh/boards"
3 0.005% OK: 3 NOT: 0 ".git/HEAD"
3 0.005% OK: 3 NOT: 0 ".git/refs/heads/my-v2.6.27"
3 0.005% OK: 3 NOT: 0 ".gitignore"
3 0.005% OK: 3 NOT: 0 ".mailmap"
3 0.005% OK: 3 NOT: 0 "CREDITS"
3 0.005% OK: 3 NOT: 0 "Documentation"
3 0.005% OK: 3 NOT: 0 "Documentation/00-INDEX"
3 0.005% OK: 3 NOT: 0 "Documentation/ABI/testing/sysfs-block"
3 0.005% OK: 3 NOT: 0 "Documentation/ABI/testing/sysfs-firmware-acpi"
3 0.005% OK: 3 NOT: 0 "Documentation/CodingStyle"
3 0.005% OK: 3 NOT: 0 "Documentation/DMA-API.txt"
3 0.005% OK: 3 NOT: 0 "Documentation/DMA-mapping.txt"
3 0.005% OK: 3 NOT: 0 "Documentation/DocBook/Makefile"
3 0.005% OK: 3 NOT: 0 "Documentation/DocBook/gadget.tmpl"
3 0.005% OK: 3 NOT: 0 "Documentation/DocBook/kernel-api.tmpl"
3 0.005% OK: 3 NOT: 0 "Documentation/DocBook/kernel-locking.tmpl"
3 0.005% OK: 3 NOT: 0 "Documentation/DocBook/procfs-guide.tmpl"
3 0.005% OK: 3 NOT: 0 "Documentation/DocBook/procfs_example.c"
3 0.005% OK: 3 NOT: 0 "Documentation/DocBook/rapidio.tmpl"
<snipp>
fstat64 14403 10.532% OK: 14403 NOT: 0 0.179938 sec 12 usec/call
So, since last time, and because of patch 4/6, almost 14 400 of the
lstat() calls has now become fstat() calls, and it seems we have saved
(* 14403 (- 44 12)) = 460 896 microseconds system time because of
this. I am planing to do a more complete and long-running
/usr/bin/time test, to get real numbers.
With both patch-series, the count of lstat() calls for this particular
test have dropped from 120 954 to 55 502, which is a total reduction
of 65 452 calls or 54%.
Please note that patch 6/6 is only to be a debug patch, to catch a
possible ping-pong situation inside the lstat_cache(), so I think that
it should at _most_ be merged to the pu branch, such that people who
wish to test, can 'git cherry-pick' the patch from there.
Kjetil Barvik (6):
symlinks.c: small cleanup and optimisation
remove some memcpy() and strchr() calls inside create_directories()
cleanup of write_entry() in entry.c
use fstat() instead of lstat() when we have an opened file
combine-diff.c: remove a call to fstat() inside show_patch_diff()
lstat_cache(): print a warning if doing ping-pong between cache types
combine-diff.c | 5 +-
entry.c | 144 ++++++++++++++++++++++++++++++--------------------------
symlinks.c | 48 ++++++++++++++-----
3 files changed, 115 insertions(+), 82 deletions(-)
^ permalink raw reply
* [PATCH/RFC v1 1/6] symlinks.c: small cleanup and optimisation
From: Kjetil Barvik @ 2009-01-26 21:17 UTC (permalink / raw)
To: git; +Cc: Kjetil Barvik
In-Reply-To: <1233004637-15112-1-git-send-email-barvik@broadpark.no>
Simplify the if-else test in longest_match_lstat_cache() such that we
only have one simple if test. Instead of testing for 'i == cache.len'
or 'i == len', we transform this to a common test for 'i == max_len'.
And to further optimise we use 'i >= max_len' instead of 'i ==
max_len', the reason is that it is now the exact opposite of one part
inside the while-loop termination expression 'i < max_len && name[i]
== cache.path[i]', and then the compiler can hopefully/probably reuse
a test-result from it.
We do similar transformations inside the lstat_cache() and the
invalidate_lstat_cache() functions.
The result is a little smaller text-size as shown below:
~/git/git $ size symlinks_??_*
text data bss dec hex filename
1282 0 4116 5398 1516 symlinks_O2_after.o
1378 0 4116 5494 1576 symlinks_O2_before.o
896 0 4116 5012 1394 symlinks_Os_after.o
902 0 4116 5018 139a symlinks_Os_before.o
'O2' means that the file is compiled with 'gcc -O2', and similar 'Os'
means that the file is compiled with 'gcc -Os' (gcc 4.3.2).
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
---
symlinks.c | 25 +++++++++++++------------
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/symlinks.c b/symlinks.c
index f262b7c..81f490c 100644
--- a/symlinks.c
+++ b/symlinks.c
@@ -25,15 +25,16 @@ static inline int longest_match_lstat_cache(int len, const char *name,
}
i++;
}
- /* Is the cached path string a substring of 'name'? */
- if (i == cache.len && cache.len < len && name[cache.len] == '/') {
- match_len_prev = match_len;
- match_len = cache.len;
- /* Is 'name' a substring of the cached path string? */
- } else if ((i == len && len < cache.len && cache.path[len] == '/') ||
- (i == len && len == cache.len)) {
+ /*
+ * Is the cached path string a substring of 'name', is 'name'
+ * a substring of the cached path string, or is 'name' and the
+ * cached path string the exact same string?
+ */
+ if (i >= max_len && ((i < len && name[i] == '/') ||
+ (i < cache.len && cache.path[i] == '/') ||
+ (len == cache.len))) {
match_len_prev = match_len;
- match_len = len;
+ match_len = i;
}
*previous_slash = match_len_prev;
return match_len;
@@ -91,7 +92,7 @@ static int lstat_cache(int len, const char *name,
match_len = last_slash =
longest_match_lstat_cache(len, name, &previous_slash);
match_flags = cache.flags & track_flags & (FL_NOENT|FL_SYMLINK);
- if (match_flags && match_len == cache.len)
+ if (match_flags && match_len >= cache.len)
return match_flags;
/*
* If we now have match_len > 0, we would know that
@@ -102,7 +103,7 @@ static int lstat_cache(int len, const char *name,
* we can return immediately.
*/
match_flags = track_flags & FL_DIR;
- if (match_flags && len == match_len)
+ if (match_flags && match_len >= len)
return match_flags;
}
@@ -153,7 +154,7 @@ static int lstat_cache(int len, const char *name,
cache.path[last_slash] = '\0';
cache.len = last_slash;
cache.flags = save_flags;
- } else if (track_flags & FL_DIR &&
+ } else if ((track_flags & FL_DIR) &&
last_slash_dir > 0 && last_slash_dir <= PATH_MAX) {
/*
* We have a separate test for the directory case,
@@ -184,7 +185,7 @@ void invalidate_lstat_cache(int len, const char *name)
int match_len, previous_slash;
match_len = longest_match_lstat_cache(len, name, &previous_slash);
- if (len == match_len) {
+ if (match_len >= len) {
if ((cache.track_flags & FL_DIR) && previous_slash > 0) {
cache.path[previous_slash] = '\0';
cache.len = previous_slash;
--
1.6.1.349.g99fa5
^ permalink raw reply related
* [PATCH/RFC v1 2/6] remove some memcpy() and strchr() calls inside create_directories()
From: Kjetil Barvik @ 2009-01-26 21:17 UTC (permalink / raw)
To: git; +Cc: Kjetil Barvik
In-Reply-To: <1233004637-15112-1-git-send-email-barvik@broadpark.no>
Remove the call to memcpy() and strchr() for each path component
tested, and instead add each path component as we go forward inside
the while-loop.
Impact: small optimisation
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
---
OK, maybe I instead should have tried to merge the function
create_directories() with the safe_create_leading_directories() and
*_const() functions? What do pepople think?
entry.c | 23 ++++++++++++++---------
1 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/entry.c b/entry.c
index 05aa58d..c2404ea 100644
--- a/entry.c
+++ b/entry.c
@@ -2,15 +2,19 @@
#include "blob.h"
#include "dir.h"
-static void create_directories(const char *path, const struct checkout *state)
+static void
+create_directories(int path_len, const char *path, const struct checkout *state)
{
- int len = strlen(path);
- char *buf = xmalloc(len + 1);
- const char *slash = path;
-
- while ((slash = strchr(slash+1, '/')) != NULL) {
- len = slash - path;
- memcpy(buf, path, len);
+ char *buf = xmalloc(path_len + 1);
+ int len = 0;
+
+ while (len < path_len) {
+ do {
+ buf[len] = path[len];
+ len++;
+ } while (len < path_len && path[len] != '/');
+ if (len >= path_len)
+ break;
buf[len] = 0;
/*
@@ -190,6 +194,7 @@ int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *t
memcpy(path, state->base_dir, len);
strcpy(path + len, ce->name);
+ len += ce_namelen(ce);
if (!lstat(path, &st)) {
unsigned changed = ce_match_stat(ce, &st, CE_MATCH_IGNORE_VALID);
@@ -218,6 +223,6 @@ int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *t
return error("unable to unlink old '%s' (%s)", path, strerror(errno));
} else if (state->not_new)
return 0;
- create_directories(path, state);
+ create_directories(len, path, state);
return write_entry(ce, path, state, 0);
}
--
1.6.1.349.g99fa5
^ permalink raw reply related
* [PATCH/RFC v1 3/6] cleanup of write_entry() in entry.c
From: Kjetil Barvik @ 2009-01-26 21:17 UTC (permalink / raw)
To: git; +Cc: Kjetil Barvik
In-Reply-To: <1233004637-15112-1-git-send-email-barvik@broadpark.no>
The switch-cases for S_IFREG and S_IFLNK was so similar that it will
be better to do some cleanup and use the common parts of it.
Also fold the longest lines such that no line is longer then 80 chars
or so.
And the entry.c file should now be clean for 'gcc -Wextra' warnings.
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
---
If people do not like this approach I can be willing to drop it from
this patch-series, but then I get some source code duplication from
the next patch (4/6).
entry.c | 114 +++++++++++++++++++++++++++++++-------------------------------
1 files changed, 57 insertions(+), 57 deletions(-)
diff --git a/entry.c b/entry.c
index c2404ea..8543755 100644
--- a/entry.c
+++ b/entry.c
@@ -78,7 +78,7 @@ static int create_file(const char *path, unsigned int mode)
return open(path, O_WRONLY | O_CREAT | O_EXCL, mode);
}
-static void *read_blob_entry(struct cache_entry *ce, const char *path, unsigned long *size)
+static void *read_blob_entry(struct cache_entry *ce, unsigned long *size)
{
enum object_type type;
void *new = read_sha1_file(ce->sha1, &type, size);
@@ -91,88 +91,86 @@ static void *read_blob_entry(struct cache_entry *ce, const char *path, unsigned
return NULL;
}
-static int write_entry(struct cache_entry *ce, char *path, const struct checkout *state, int to_tempfile)
+static int
+write_entry(struct cache_entry *ce, char *path, const struct checkout *state,
+ int to_tempfile)
{
- int fd;
- long wrote;
-
- switch (ce->ce_mode & S_IFMT) {
- char *new;
- struct strbuf buf;
- unsigned long size;
-
+ unsigned int ce_mode_s_ifmt = ce->ce_mode & S_IFMT;
+ int fd, ret;
+ char *new;
+ struct strbuf buf = STRBUF_INIT;
+ unsigned long size;
+ size_t wrote, newsize = 0;
+
+ switch (ce_mode_s_ifmt) {
case S_IFREG:
- new = read_blob_entry(ce, path, &size);
+ case S_IFLNK:
+ new = read_blob_entry(ce, &size);
if (!new)
- return error("git checkout-index: unable to read sha1 file of %s (%s)",
- path, sha1_to_hex(ce->sha1));
+ return error("git checkout-index: "\
+ "unable to read sha1 file of %s (%s)",
+ path, sha1_to_hex(ce->sha1));
+
+ if (ce_mode_s_ifmt == S_IFLNK && has_symlinks && !to_tempfile) {
+ ret = symlink(new, path);
+ free(new);
+ if (ret)
+ return error("git checkout-index: "\
+ "unable to create symlink %s (%s)",
+ path, strerror(errno));
+ break;
+ }
/*
* Convert from git internal format to working tree format
*/
- strbuf_init(&buf, 0);
- if (convert_to_working_tree(ce->name, new, size, &buf)) {
- size_t newsize = 0;
+ if (ce_mode_s_ifmt == S_IFREG &&
+ convert_to_working_tree(ce->name, new, size, &buf)) {
free(new);
new = strbuf_detach(&buf, &newsize);
size = newsize;
}
if (to_tempfile) {
- strcpy(path, ".merge_file_XXXXXX");
+ if (ce_mode_s_ifmt == S_IFREG)
+ strcpy(path, ".merge_file_XXXXXX");
+ else
+ strcpy(path, ".merge_link_XXXXXX");
fd = mkstemp(path);
- } else
- fd = create_file(path, ce->ce_mode);
+ } else {
+ if (ce_mode_s_ifmt == S_IFREG)
+ fd = create_file(path, ce->ce_mode);
+ else
+ fd = create_file(path, 0666);
+ }
if (fd < 0) {
free(new);
- return error("git checkout-index: unable to create file %s (%s)",
- path, strerror(errno));
+ return error("git checkout-index: "\
+ "unable to create file %s (%s)",
+ path, strerror(errno));
}
wrote = write_in_full(fd, new, size);
close(fd);
free(new);
if (wrote != size)
- return error("git checkout-index: unable to write file %s", path);
- break;
- case S_IFLNK:
- new = read_blob_entry(ce, path, &size);
- if (!new)
- return error("git checkout-index: unable to read sha1 file of %s (%s)",
- path, sha1_to_hex(ce->sha1));
- if (to_tempfile || !has_symlinks) {
- if (to_tempfile) {
- strcpy(path, ".merge_link_XXXXXX");
- fd = mkstemp(path);
- } else
- fd = create_file(path, 0666);
- if (fd < 0) {
- free(new);
- return error("git checkout-index: unable to create "
- "file %s (%s)", path, strerror(errno));
- }
- wrote = write_in_full(fd, new, size);
- close(fd);
- free(new);
- if (wrote != size)
- return error("git checkout-index: unable to write file %s",
- path);
- } else {
- wrote = symlink(new, path);
- free(new);
- if (wrote)
- return error("git checkout-index: unable to create "
- "symlink %s (%s)", path, strerror(errno));
- }
+ return error("git checkout-index: "\
+ "unable to write file %s", path);
+
break;
case S_IFGITLINK:
if (to_tempfile)
- return error("git checkout-index: cannot create temporary subproject %s", path);
+ return error("git checkout-index: "\
+ "cannot create temporary subproject %s",
+ path);
if (mkdir(path, 0777) < 0)
- return error("git checkout-index: cannot create subproject directory %s", path);
+ return error("git checkout-index: "\
+ "cannot create subproject directory %s (%s)",
+ path, strerror(errno));
break;
default:
- return error("git checkout-index: unknown file mode for %s", path);
+ return error("git checkout-index: "\
+ "unknown file mode for %s", path);
}
if (state->refresh_cache) {
@@ -202,7 +200,8 @@ int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *t
return 0;
if (!state->force) {
if (!state->quiet)
- fprintf(stderr, "git-checkout-index: %s already exists\n", path);
+ fprintf(stderr, "git-checkout-index: "\
+ "%s already exists\n", path);
return -1;
}
@@ -220,7 +219,8 @@ int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *t
return error("%s is a directory", path);
remove_subtree(path);
} else if (unlink(path))
- return error("unable to unlink old '%s' (%s)", path, strerror(errno));
+ return error("unable to unlink old '%s' (%s)",
+ path, strerror(errno));
} else if (state->not_new)
return 0;
create_directories(len, path, state);
--
1.6.1.349.g99fa5
^ permalink raw reply related
* [PATCH/RFC v1 4/6] use fstat() instead of lstat() when we have an opened file
From: Kjetil Barvik @ 2009-01-26 21:17 UTC (permalink / raw)
To: git; +Cc: Kjetil Barvik
In-Reply-To: <1233004637-15112-1-git-send-email-barvik@broadpark.no>
Currently inside write_entry() we do an lstat(path, &st) call on a
file which have just been opened inside the exact same function. It
should be better to call fstat(fd, &st) on the file while it is
opened, and it should be at least as fast as the lstat() method.
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
---
entry.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/entry.c b/entry.c
index 8543755..c932ae8 100644
--- a/entry.c
+++ b/entry.c
@@ -96,11 +96,12 @@ write_entry(struct cache_entry *ce, char *path, const struct checkout *state,
int to_tempfile)
{
unsigned int ce_mode_s_ifmt = ce->ce_mode & S_IFMT;
- int fd, ret;
+ int fd, ret, fstat_done = 0;
char *new;
struct strbuf buf = STRBUF_INIT;
unsigned long size;
size_t wrote, newsize = 0;
+ struct stat st;
switch (ce_mode_s_ifmt) {
case S_IFREG:
@@ -151,6 +152,10 @@ write_entry(struct cache_entry *ce, char *path, const struct checkout *state,
}
wrote = write_in_full(fd, new, size);
+ if (state->refresh_cache) {
+ fstat(fd, &st);
+ fstat_done = 1;
+ }
close(fd);
free(new);
if (wrote != size)
@@ -174,8 +179,8 @@ write_entry(struct cache_entry *ce, char *path, const struct checkout *state,
}
if (state->refresh_cache) {
- struct stat st;
- lstat(ce->name, &st);
+ if (!fstat_done)
+ lstat(ce->name, &st);
fill_stat_cache_info(ce, &st);
}
return 0;
--
1.6.1.349.g99fa5
^ permalink raw reply related
* [PATCH/RFC v1 5/6] combine-diff.c: remove a call to fstat() inside show_patch_diff()
From: Kjetil Barvik @ 2009-01-26 21:17 UTC (permalink / raw)
To: git; +Cc: Kjetil Barvik
In-Reply-To: <1233004637-15112-1-git-send-email-barvik@broadpark.no>
Currently inside show_patch_diff() we have and fstat() call after an
ok lstat() call. Since we before the call to fstat() have already
test for the link case with S_ISLNK() the fstat() can be removed.
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
---
combine-diff.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index bccc018..ab4df31 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -713,9 +713,8 @@ static void show_patch_diff(struct combine_diff_path *elem, int num_parent,
result_size = buf.len;
result = strbuf_detach(&buf, NULL);
elem->mode = canon_mode(st.st_mode);
- }
- else if (0 <= (fd = open(elem->path, O_RDONLY)) &&
- !fstat(fd, &st)) {
+
+ } else if (0 <= (fd = open(elem->path, O_RDONLY))) {
size_t len = xsize_t(st.st_size);
ssize_t done;
int is_file, i;
--
1.6.1.349.g99fa5
^ permalink raw reply related
* [PATCH/RFC v1 6/6] lstat_cache(): print a warning if doing ping-pong between cache types
From: Kjetil Barvik @ 2009-01-26 21:18 UTC (permalink / raw)
To: git; +Cc: Kjetil Barvik
This is a debug patch which is only to be used while the lstat_cache()
is in the test stage, and should be removed/reverted before the final
relase.
I think it should be useful to catch these warnings, as I it could be
an indication of that the cache would not be very effective if it is
doing ping-pong by switching between different cache types too many
times.
Also, if someone is experimenting with the lstat_cache(), this patch
will maybe be useful while debugging.
If someone is able to trigger the warning, then send a mail to the GIT
mailing list, containing the first 15 lines of the warning, and a
short description of the GIT commands to trigger the warnings.
This patch is against the 'next' branch. I hope someone is willing to
use this patch for a while, to be able to catch possible ping-pong's.
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
---
Hmmm, it seems that 'git send-email' always fails for this mail, with
the following error message:
Died at /usr/local/libexec/git-core/git-send-email line 882.
So I send this as a separate command from 'git send-email', sorry
abouth that.
symlinks.c | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/symlinks.c b/symlinks.c
index 81f490c..1c07ae0 100644
--- a/symlinks.c
+++ b/symlinks.c
@@ -49,6 +49,11 @@ static inline void reset_lstat_cache(int track_flags, int prefix_len_stat_func)
cache.prefix_len_stat_func = prefix_len_stat_func;
}
+#define SWITCHES_BEFORE_WARNING 10
+static unsigned int cache_switches = 0, number_of_warnings = 0;
+static unsigned int current_cache_func = 0, last_cache_func = 0;
+static unsigned int total_calls = 0;
+
#define FL_DIR (1 << 0)
#define FL_NOENT (1 << 1)
#define FL_SYMLINK (1 << 2)
@@ -75,6 +80,7 @@ static int lstat_cache(int len, const char *name,
int match_flags, ret_flags, save_flags, max_len, ret;
struct stat st;
+ total_calls++;
if (cache.track_flags != track_flags ||
cache.prefix_len_stat_func != prefix_len_stat_func) {
/*
@@ -84,6 +90,17 @@ static int lstat_cache(int len, const char *name,
*/
reset_lstat_cache(track_flags, prefix_len_stat_func);
match_len = last_slash = 0;
+ cache_switches++;
+ if (cache_switches > SWITCHES_BEFORE_WARNING) {
+ if (number_of_warnings < 10 || number_of_warnings % 1000 == 0)
+ printf("warning from %s:%d cache_switches:%u > %u "\
+ "(current:%u last:%u total:%u)\n",
+ __FILE__, __LINE__,
+ cache_switches, SWITCHES_BEFORE_WARNING,
+ current_cache_func, last_cache_func,
+ total_calls);
+ number_of_warnings++;
+ }
} else {
/*
* Check to see if we have a match from the cache for
@@ -211,6 +228,8 @@ void clear_lstat_cache(void)
*/
int has_symlink_leading_path(int len, const char *name)
{
+ last_cache_func = current_cache_func;
+ current_cache_func = 1;
return lstat_cache(len, name,
FL_SYMLINK|FL_DIR, USE_ONLY_LSTAT) &
FL_SYMLINK;
@@ -222,6 +241,8 @@ int has_symlink_leading_path(int len, const char *name)
*/
int has_symlink_or_noent_leading_path(int len, const char *name)
{
+ last_cache_func = current_cache_func;
+ current_cache_func = 2;
return lstat_cache(len, name,
FL_SYMLINK|FL_NOENT|FL_DIR, USE_ONLY_LSTAT) &
(FL_SYMLINK|FL_NOENT);
@@ -236,6 +257,8 @@ int has_symlink_or_noent_leading_path(int len, const char *name)
*/
int has_dirs_only_path(int len, const char *name, int prefix_len)
{
+ last_cache_func = current_cache_func;
+ current_cache_func = 3;
return lstat_cache(len, name,
FL_DIR|FL_FULLPATH, prefix_len) &
FL_DIR;
--
1.6.1.349.g99fa5
^ permalink raw reply related
* Re: [PATCH] mergetool: respect autocrlf by using checkout-index
From: Junio C Hamano @ 2009-01-26 21:28 UTC (permalink / raw)
To: Charles Bailey; +Cc: Hannu Koivisto, git, Theodore Tso
In-Reply-To: <20090126163114.GD32604@hashpling.org>
Charles Bailey <charles@hashpling.org> writes:
> I suspect that the LF endings in the file is due to the fact that in
> builtin-merge-file.c, the file is opened (fopen) in binary mode
> ("wb"), but xdl_merge terminates all lines with a raw '\n'.
>
> The obvious fix would be to change fopen in builtin-file-merge.c to
> use "w" instead, but this doesn't work in a number of scenarios. In
> particular, it is wrong for repositories on windows with core.autocrlf
> set to false, and would not fix non-windows repositories with
> core.autocrlf set to true.
>
> Currently, I've no idea as to what the solution should be.
"git file-merge" is designed to be a replacement for stock RCS merge, and
unfortunately it does not call convert_to_working_tree(), nor has any way
to know for which path it should take the attributes to apply to affect
what convert_to_working_tree() should do even if it were to call it.
I think we would need a new option to the command that says "pretend this
is about merging this path, and use the gitattributes specified for it
when writing out the result."
^ permalink raw reply
* Re: [PATCH] rebase -i: correctly remember --root flag across --continue
From: Thomas Rast @ 2009-01-26 21:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7veiyp4w2m.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]
Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
> > + GIT_EDITOR=: test_must_fail git rebase -i --root --onto master &&
>
> Maybe I am misrecalling things but didn't we have reports from people on
> some platforms that single-shot exporting of the environment like this one
> does not work for them?
Then that deserves a fix, though I should point out that the original
patches (now on master) have the same code in them.
[So many quirks and so little time!]
> > +sed 's/#/ /g' > expect-conflict-p <<'EOF'
> > +* Merge branch 'third' into other
> > +|\##
> > +| * 6
> > +* | Merge branch 'side' into other
> > +|\ \##
> > +| * | 5
> > +* | | 4
> > +|/ /##
> > +* | 3
> > +|/##
> > +* conflict
> > +* 2
> > +* 1
> > +EOF
>
> I do not like this very much. Future improvements of the graph drawing
> algorithm (one obvious "flaw" you are exposing by the above is that it has
> trailing whitespaces that can be trimmed, and somebody else may be
> inclined to fix) would break the expectation this test vector has.
>
> Do you have to compare the topology this way, or are there other more
> reliable ways?
It would certainly be possible to test the SHA1 of the resulting
branch tip, but t/README says I shouldn't. Or we could spell it out
as a series of 'parent of X is Y' and 'message of Y is foo' tests,
which seems rather messy.
The above approach at least has the advantage that a test failure due
to format change can be diagnosed very quickly just from the diff that
is shown with -v.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Allow format-patch to create patches for merges
From: Nathan W. Panike @ 2009-01-26 21:46 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20090126204543.GF27604@coredump.intra.peff.net>
I have not used the bundle stuff, but yes, it seems to be a better fit
for what I am trying to do.
Thanks,
Nathan Panike
On Mon, Jan 26, 2009 at 2:45 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Jan 26, 2009 at 10:27:18AM -0600, Nathan W. Panike wrote:
>
>> I think I have an unusual workflow where my patch makes sense,
>> although it probably does not for the vast majority of git users. I
>> regularly use 3 machines: S, L, and H. I keep my work synchronized by
>> using git. Normally, I fetch from S to L or to H, depending on which
>> machine I am working on at the moment. I also push from L or H to S.
>> I sporadically lose connectivity to S, so I have a hook in the repo on
>> S to send a backup email to me on mail server M, which has a more
>> reliable connection. This email also serves as a reminder when I
>
> Have you considered sending a bundle instead of a patch in the backup
> email? That is the more exact equivalent of a push (i.e., it preserves
> your actual commits, sha1 and all).
>
> -Peff
>
^ permalink raw reply
* Re: [PATCH] rebase -i: correctly remember --root flag across --continue
From: Junio C Hamano @ 2009-01-26 21:49 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Johannes Schindelin
In-Reply-To: <7veiyp4w2m.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thomas Rast <trast@student.ethz.ch> writes:
> ...
>> +sed 's/#/ /g' > expect-conflict-p <<'EOF'
>> +* Merge branch 'third' into other
>> +|\##
>> +| * 6
>> +* | Merge branch 'side' into other
>> +|\ \##
>> +| * | 5
>> +* | | 4
>> +|/ /##
>> +* | 3
>> +|/##
>> +* conflict
>> +* 2
>> +* 1
>> +EOF
>
> I do not like this very much. Future improvements of the graph drawing
> algorithm (one obvious "flaw" you are exposing by the above is that it has
> trailing whitespaces that can be trimmed, and somebody else may be
> inclined to fix) would break the expectation this test vector has.
>
> Do you have to compare the topology this way, or are there other more
> reliable ways?
Perhaps something like this.
t/t3412-rebase-root.sh | 36 +++++++++++++++++++++---------------
1 files changed, 21 insertions(+), 15 deletions(-)
diff --git i/t/t3412-rebase-root.sh w/t/t3412-rebase-root.sh
index 29bb6d0..2408cf8 100755
--- i/t/t3412-rebase-root.sh
+++ w/t/t3412-rebase-root.sh
@@ -240,19 +240,24 @@ test_expect_success 'rebase -i --root with conflict (second part)' '
'
sed 's/#/ /g' > expect-conflict-p <<'EOF'
-* Merge branch 'third' into other
-|\##
-| * 6
-* | Merge branch 'side' into other
-|\ \##
-| * | 5
-* | | 4
-|/ /##
-* | 3
-|/##
-* conflict
-* 2
-* 1
+commit conflict3 conflict3~1 conflict3^2
+Merge branch 'third' into other
+commit conflict3^2 conflict3~4
+6
+commit conflict3~1 conflict3~2 conflict3~1^2
+Merge branch 'side' into other
+commit conflict3~1^2 conflict3~3
+5
+commit conflict3~2 conflict3~3
+4
+commit conflict3~3 conflict3~4
+3
+commit conflict3~4 conflict3~5
+conflict
+commit conflict3~5 conflict3~6
+2
+commit conflict3~6
+1
EOF
test_expect_success 'rebase -i -p --root with conflict (first part)' '
@@ -268,8 +273,9 @@ test_expect_success 'fix the conflict' '
test_expect_success 'rebase -i -p --root with conflict (second part)' '
git rebase --continue &&
- git log --graph --topo-order --pretty=tformat:"%s" > conflict3 &&
- test_cmp expect-conflict-p conflict3
+ git rev-list --topo-order --parents --pretty="tformat:%s" HEAD |
+ git name-rev --stdin --name-only --refs=refs/heads/conflict3 >out &&
+ test_cmp expect-conflict-p out
'
test_done
^ permalink raw reply related
* Re: [PATCH] mergetool: respect autocrlf by using checkout-index
From: Junio C Hamano @ 2009-01-26 22:08 UTC (permalink / raw)
To: Charles Bailey; +Cc: Hannu Koivisto, git, Theodore Tso
In-Reply-To: <7v7i4h4v19.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Charles Bailey <charles@hashpling.org> writes:
>
>> I suspect that the LF endings in the file is due to the fact that in
>> builtin-merge-file.c, the file is opened (fopen) in binary mode
>> ("wb"), but xdl_merge terminates all lines with a raw '\n'.
>>
>> The obvious fix would be to change fopen in builtin-file-merge.c to
>> use "w" instead, but this doesn't work in a number of scenarios. In
>> particular, it is wrong for repositories on windows with core.autocrlf
>> set to false, and would not fix non-windows repositories with
>> core.autocrlf set to true.
>>
>> Currently, I've no idea as to what the solution should be.
>
> "git file-merge" is designed to be a replacement for stock RCS merge, and
> unfortunately it does not call convert_to_working_tree(), nor has any way
> to know for which path it should take the attributes to apply to affect
> what convert_to_working_tree() should do even if it were to call it.
>
> I think we would need a new option to the command that says "pretend this
> is about merging this path, and use the gitattributes specified for it
> when writing out the result."
Perhaps something along this line to teach
$ git merge-file --attribute-path=frotz.c file1 orig_file file2
to merge what happened since orig_file to file2 into file1, and deposit
the result after converting it appropriately for path "frotz.c" obeying
core.autocrlf and gitattribute rules.
I see rerere.c::merge() has the exact same issue, but its breakage is half
hidden by its use of fopen(path, "w"). It should explicitly use
convert_to_working_tree() like this patch does, and write the results out
in binary mode.
builtin-merge-file.c | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git i/builtin-merge-file.c w/builtin-merge-file.c
index 96edb97..61d1092 100644
--- i/builtin-merge-file.c
+++ w/builtin-merge-file.c
@@ -5,7 +5,7 @@
#include "parse-options.h"
static const char *const merge_file_usage[] = {
- "git merge-file [options] [-L name1 [-L orig [-L name2]]] file1 orig_file file2",
+ "git merge-file [options] [-L name1 [-L orig [-L name2]]] [--attribute-path path] file1 orig_file file2",
NULL
};
@@ -30,10 +30,13 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
int merge_level = XDL_MERGE_ZEALOUS_ALNUM;
int merge_style = 0, quiet = 0;
int nongit;
+ char *attribute_path = NULL;
struct option options[] = {
OPT_BOOLEAN('p', "stdout", &to_stdout, "send results to standard output"),
OPT_SET_INT(0, "diff3", &merge_style, "use a diff3 based merge", XDL_MERGE_DIFF3),
+ OPT_STRING('a', "attribute-path", &attribute_path, "path",
+ "apply work-tree conversion for the path"),
OPT__QUIET(&quiet),
OPT_CALLBACK('L', NULL, names, "name",
"set labels for file1/orig_file/file2", &label_cb),
@@ -73,6 +76,19 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
for (i = 0; i < 3; i++)
free(mmfs[i].ptr);
+ if (ret >= 0 && attribute_path) {
+ struct strbuf buf = STRBUF_INIT;
+ ret = convert_to_working_tree(attribute_path,
+ result.ptr, result.size,
+ &buf);
+ free(result.ptr);
+ if (!ret) {
+ size_t len;
+ result.ptr = strbuf_detach(&buf, &len);
+ result.size = len;
+ }
+ }
+
if (ret >= 0) {
const char *filename = argv[0];
FILE *f = to_stdout ? stdout : fopen(filename, "wb");
^ permalink raw reply related
* Re: git 1.6.1 on AIX 5.3
From: Mike Ralphson @ 2009-01-26 22:32 UTC (permalink / raw)
To: Perry Smith; +Cc: git, Jeff King
In-Reply-To: <20090126210027.GG27604@coredump.intra.peff.net>
2009/1/26 Jeff King <peff@peff.net>:
> [cc-ing Mike Ralphson, our local AIX expert]
Bless you!
> On Mon, Jan 26, 2009 at 02:02:15PM -0600, Perry Smith wrote:
>
>> I tried building git 1.6.1 on AIX 5.3 as an "out of tree" build and it
>> does not seem to be set up to do out of tree builds. If that is not
>> true, please let me know.
>>
>> The install process wants to call install with a -d option. AIX has two
>> install programs but they are pretty old -- neither takes a -d option.
>>
>> Is there a GNU install program I can get? I've not been able to locate
>> one.
>
> It's in GNU coreutils:
>
> http://www.gnu.org/software/coreutils/
>
> I don't know what Mike uses to install on AIX; you can see his config
> setup here:
>
> http://repo.or.cz/w/git/gitbuild.git?a=tree;f=mr/aix;hb=platform
>
> but I don't see any override of install.
I've got the AIX Toolbox for Linux applications[1] installed and ahead
of /bin and /usr/bin on my PATH. Beware that some of these don't
function as well as the stock AIX utilities and should normally be
removed. I've posted about this on what is ostensibly a blog but which
is really just a post-it note I'm less likely to lose[2].
Failing that, many programs which are primarily configured using
autoconf will ship with an install shell script which you can co-opt,
some apache stuff does too[3].
Any other questions, don't hesitate to ask.
Mike
[1] http://www-03.ibm.com/systems/power/software/aix/linux/index.html
[2] http://mermade.blogspot.com/2008/04/aix-toolbox.html
[3] http://svn.apache.org/repos/asf/tcl/websh/trunk/src/unix/install-sh
^ permalink raw reply
* Re: git 1.6.1 on AIX 5.3
From: Perry Smith @ 2009-01-26 22:57 UTC (permalink / raw)
To: Mike Ralphson; +Cc: git, Jeff King
In-Reply-To: <e2b179460901261432r601fa006iaf04fc42487e7235@mail.gmail.com>
On Jan 26, 2009, at 4:32 PM, Mike Ralphson wrote:
> 2009/1/26 Jeff King <peff@peff.net>:
>> [cc-ing Mike Ralphson, our local AIX expert]
>
> Bless you!
>
>> On Mon, Jan 26, 2009 at 02:02:15PM -0600, Perry Smith wrote:
>>
>>> I tried building git 1.6.1 on AIX 5.3 as an "out of tree" build
>>> and it
>>> does not seem to be set up to do out of tree builds. If that is not
>>> true, please let me know.
>>>
>>> The install process wants to call install with a -d option. AIX
>>> has two
>>> install programs but they are pretty old -- neither takes a -d
>>> option.
>>>
>>> Is there a GNU install program I can get? I've not been able to
>>> locate
>>> one.
>>
>> It's in GNU coreutils:
>>
>> http://www.gnu.org/software/coreutils/
>>
>> I don't know what Mike uses to install on AIX; you can see his config
>> setup here:
>>
>> http://repo.or.cz/w/git/gitbuild.git?a=tree;f=mr/aix;hb=platform
>>
>> but I don't see any override of install.
>
> I've got the AIX Toolbox for Linux applications[1] installed and ahead
> of /bin and /usr/bin on my PATH. Beware that some of these don't
> function as well as the stock AIX utilities and should normally be
> removed. I've posted about this on what is ostensibly a blog but which
> is really just a post-it note I'm less likely to lose[2].
>
> Failing that, many programs which are primarily configured using
> autoconf will ship with an install shell script which you can co-opt,
> some apache stuff does too[3].
>
> Any other questions, don't hesitate to ask.
>
> Mike
>
> [1] http://www-03.ibm.com/systems/power/software/aix/linux/index.html
>
> [2] http://mermade.blogspot.com/2008/04/aix-toolbox.html
>
> [3] http://svn.apache.org/repos/asf/tcl/websh/trunk/src/unix/install-
> sh
Thanks guys. I picked up coreutils version 7. I didn't
install them but just moved ginstall over to /usr/local/bin.
A few other comments: I had to add in the --without-tcltk flag. I
don't have
tcl installed but the config did not autodetect that it was not present.
I can't tell if make test is happy or not. The output looks like its
happy
but the exit code is 2.
Below is my "configure" script if anyone is interested.
#!/usr/bin/env bash
export CONFIG_SHELL=/usr/local/bin/bash
export LDFLAGS='-L/usr/local/lib -L/usr/local/ssl/lib'
export CFLAGS='-I/usr/local/include -I/usr/local/ssl/include'
export CC=gcc
echo CONFIG_SHELL set to ${CONFIG_SHELL}
${CONFIG_SHELL} ../../src/git-1.6.1/configure --without-tcltk
#
# Note that to install you need to do:
# make INSTALL=ginstall install
# to use GNU's install program
^ permalink raw reply
* Re: [PATCH] mergetool: respect autocrlf by using checkout-index
From: Junio C Hamano @ 2009-01-26 23:09 UTC (permalink / raw)
To: Charles Bailey; +Cc: Hannu Koivisto, git, Theodore Tso
In-Reply-To: <7vskn53em1.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Perhaps something along this line to teach
>
> $ git merge-file --attribute-path=frotz.c file1 orig_file file2
>
> to merge what happened since orig_file to file2 into file1, and deposit
> the result after converting it appropriately for path "frotz.c" obeying
> core.autocrlf and gitattribute rules.
>
> I see rerere.c::merge() has the exact same issue, but its breakage is half
> hidden by its use of fopen(path, "w"). It should explicitly use
> convert_to_working_tree() like this patch does, and write the results out
> in binary mode.
Second try. I forgot how convert_* worked X-<.
builtin-merge-file.c | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git i/builtin-merge-file.c w/builtin-merge-file.c
index 96edb97..edee815 100644
--- i/builtin-merge-file.c
+++ w/builtin-merge-file.c
@@ -5,7 +5,7 @@
#include "parse-options.h"
static const char *const merge_file_usage[] = {
- "git merge-file [options] [-L name1 [-L orig [-L name2]]] file1 orig_file file2",
+ "git merge-file [options] [-L name1 [-L orig [-L name2]]] [--attribute-path path] file1 orig_file file2",
NULL
};
@@ -30,10 +30,13 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
int merge_level = XDL_MERGE_ZEALOUS_ALNUM;
int merge_style = 0, quiet = 0;
int nongit;
+ char *attribute_path = NULL;
struct option options[] = {
OPT_BOOLEAN('p', "stdout", &to_stdout, "send results to standard output"),
OPT_SET_INT(0, "diff3", &merge_style, "use a diff3 based merge", XDL_MERGE_DIFF3),
+ OPT_STRING('a', "attribute-path", &attribute_path, "path",
+ "apply work-tree conversion for the path"),
OPT__QUIET(&quiet),
OPT_CALLBACK('L', NULL, names, "name",
"set labels for file1/orig_file/file2", &label_cb),
@@ -73,6 +76,21 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
for (i = 0; i < 3; i++)
free(mmfs[i].ptr);
+ if (ret >= 0 && attribute_path) {
+ struct strbuf buf = STRBUF_INIT;
+ int st;
+ st = convert_to_working_tree(attribute_path,
+ result.ptr, result.size,
+ &buf);
+ if (st) {
+ size_t len;
+
+ free(result.ptr);
+ result.ptr = strbuf_detach(&buf, &len);
+ result.size = len;
+ }
+ }
+
if (ret >= 0) {
const char *filename = argv[0];
FILE *f = to_stdout ? stdout : fopen(filename, "wb");
^ permalink raw reply related
* Re: [PATCH v2] Change octal literals to be XEmacs friendly
From: Alexandre Julliard @ 2009-01-26 22:59 UTC (permalink / raw)
To: Kalle Olavi Niemitalo; +Cc: git
In-Reply-To: <874ozp79y4.fsf@Astalo.kon.iki.fi>
Kalle Olavi Niemitalo <kon@iki.fi> writes:
> Vassili Karpov <av1474@comtv.ru> writes:
>
>> #ooctal syntax on the other hand produces integers everywhere.
>
> GNU Emacs 20.7 doesn't support #o, but neither does it include
> the ewoc and log-edit libraries required by the current git.el.
>
> It would be nice to have a comment in git.el saying which
> versions of Emacs and XEmacs it is supposed to support, but I
> guess people wouldn't bother testing those on every commit.
I try to make sure that it still works with Emacs 21, but for older
versions you're on your own. Of course if you find problems patches are
welcome...
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* Re: [PATCH] rebase -i: correctly remember --root flag across --continue
From: Junio C Hamano @ 2009-01-27 0:29 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Johannes Schindelin
In-Reply-To: <200901262228.13104.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> It would certainly be possible to test the SHA1 of the resulting
> branch tip, but t/README says I shouldn't.
Correct. The test should convert the SHA-1 back to some symbolic form
that is stable for comparison.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #05; Wed, 21)
From: Boyd Stephen Smith Jr. @ 2009-01-27 1:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <200901212321.50526.bss@iguanasuicide.net>
[-- Attachment #1: Type: text/plain, Size: 951 bytes --]
On Wednesday 21 January 2009, "Boyd Stephen Smith Jr."
<bss@iguanasuicide.net> wrote about 'Re: What's cooking in git.git (Jan
2009, #05; Wed, 21)':
>On Wednesday 21 January 2009, Junio C Hamano <gitster@pobox.com> wrote
>about 'What's cooking in git.git (Jan 2009, #05; Wed, 21)':
>>* js/notes (Tue Jan 13 20:57:16 2009 +0100) 6 commits
>>
>>It would be nice to hear a real world success story using the notes
>>mechanism before casting this design in stone.
>
>I'll see if I can't try to put this through some paces over the week.
Yeah, that's not gonna happen. I still want to play with this some, but
that's being pushed to the background, so I can't say when I'll really get
time to test it.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v1 0/3] Introduce config variable "diff.primer"
From: Keith Cascio @ 2009-01-27 1:47 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090125220756.GA18855@coredump.intra.peff.net>
On Sun, 25 Jan 2009, Jeff King wrote:
> let's say I have a gitattributes file like this:
> *.c diff=c
> and my config says:
> [diff]
> opt1 = val1_default
> opt2 = val2_default
> [diff "c"]
> opt1 = val1_c
>
> Now obviously if I want to use opt1 for my C files, it should be val1_c.
> But if I want to use opt2, what should it use? There are two reasonable
> choices, I think:
> 1. You use val2_default. The rationale is that the "c" diff driver did
> not define an opt2, so you fall back to the global default.
> 2. It is unset. The rationale is that you are using the "c" diff
> driver, and it has left the value unset. The default then means "if
> you have no diff driver setup".
I'm in favor of option (2), because [diff] a.k.a [diff ""] serving as the
fallback for [diff *] feels like a special case. If a full system of precedence
and fallbacks is desired for .git/config, we should adopt explicit grammar that
lets me define an arbitrary precedence tree over all sections. Once a powerful
concept is born, somewhere down the road, some user will desire its
universalization.
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Theodore Tso @ 2009-01-26 22:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Caleb Cushing, Charles Bailey, git
In-Reply-To: <7vwscmue5z.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 23, 2009 at 09:26:32AM -0800, Junio C Hamano wrote:
> Caleb Cushing <xenoterracide@gmail.com> writes:
>
> > so does my patch satisfy now? what's it take to get it included in the
> > next version of git?
>
> I do not use mergetool myself so I generally do not pay attention to
> patches on this tool, but I would want to pick up ones that people
> involved in mergetool discussion can agree to be good patches.
>
> There are a few mergetool updates in flight from various authors. How
> does your submission compare with others' in both form/presentation and
> clarity of logic (remember, I am not keeping track)?
I was the original author of mergetool, and for a while I was the
person that was reviewing and managing the mergetool patches for
Junio. Unfortunately, in the last couple of months I just haven't had
the time keep up with the various mergetool proposed patch updates.
So maybe it's time for me to hand it off to someone who has the time
and interest in continuing to hack mergetool, and has the necessary
"good taste" and such that Junio would be willing to trust that person
to be the git mergetool patch wrangler?
- Ted
^ permalink raw reply
* Valgrind updates
From: Johannes Schindelin @ 2009-01-27 2:50 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901212259420.3586@pacific.mpi-cbg.de>
Hi,
it is real late now, so I am uncomfortable sending off a new patch series
(I _know_ that I'll just introduce a stupid bug or forget to write a
commit message or whatever). In case you are interested in the current
progress, you know where my branches are.
The changes I made:
- added t/valgrind/templates to t/.gitignore, too,
- split out the valgrind-unrelated parts that Peff complained about,
- added some more suppressions I needed,
- added a mode whereby the tests' results are written to test-results/,
- provided a Makefile target for further convenience,
- added a script to coalesce the valgrind results by backtrace,
- split out a patch that lets --valgrind imply --verbose, and
- ran the scripts several times, which is a PITA because one run takes 5.5
hours (and the first time I forgot to redirect stderr, ouch, thus the
test-results/ patch).
I have an output from a previous full run, albeit it was done with an
earlier version of the valgrind patch series I was not comfortable with,
so I will not send it here. Besides, it is 300K (bzip2 -9 reduces that to
20K), and I am sure you don't want to have it.
Just that much, most of the backtraces are pretty repetitive. In fact, I
think most if not all of them touch xwrite.c (I got other errors from my
patches, as I expected).
==valgrind== Syscall param write(buf) points to uninitialised byte(s)
==valgrind== at 0x5609E40: __write_nocancel (in /lib/libpthread-2.6.1.so)
==valgrind== by 0x4D0380: xwrite (wrapper.c:129)
==valgrind== by 0x4D046E: write_in_full (wrapper.c:159)
==valgrind== by 0x4C0697: write_buffer (sha1_file.c:2275)
==valgrind== by 0x4C0B1C: write_loose_object (sha1_file.c:2387)
==valgrind== by 0x4C0C4F: write_sha1_file (sha1_file.c:2418)
==valgrind== by 0x46DBB8: update_one (cache-tree.c:348)
==valgrind== by 0x46D8CF: update_one (cache-tree.c:282)
==valgrind== by 0x46DCCA: cache_tree_update (cache-tree.c:373)
==valgrind== by 0x46E2B5: write_cache_as_tree (cache-tree.c:562)
==valgrind== by 0x4662D4: cmd_write_tree (builtin-write-tree.c:36)
==valgrind== by 0x404F37: run_command (git.c:243)
==valgrind== Address 0x713dc23 is 51 bytes inside a block of size 195 alloc'd
==valgrind== at 0x4C2273B: malloc (in /usr/local/lib/valgrind/amd64-linux/vgpreload_memcheck.so)
==valgrind== by 0x4CFFCC: xmalloc (wrapper.c:20)
==valgrind== by 0x4C0A33: write_loose_object (sha1_file.c:2362)
==valgrind== by 0x4C0C4F: write_sha1_file (sha1_file.c:2418)
==valgrind== by 0x46DBB8: update_one (cache-tree.c:348)
==valgrind== by 0x46D8CF: update_one (cache-tree.c:282)
==valgrind== by 0x46DCCA: cache_tree_update (cache-tree.c:373)
==valgrind== by 0x46E2B5: write_cache_as_tree (cache-tree.c:562)
==valgrind== by 0x4662D4: cmd_write_tree (builtin-write-tree.c:36)
==valgrind== by 0x404F37: run_command (git.c:243)
==valgrind== by 0x4050E4: handle_internal_command (git.c:387)
==valgrind== by 0x4051CA: run_argv (git.c:425)
which can be reproduced by running t0000-basic.out in valgrind mode.
Good night, Vietnam,
Dscho
^ permalink raw reply
* Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Keith Cascio @ 2009-01-27 3:01 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20090126115957.GA20558@coredump.intra.peff.net>
On Mon, 26 Jan 2009, Jeff King wrote:
> Yep, that's what defaults are. And guess what: we _already_ have the same
> thing. I have diff.renames set in my ~/.gitconfig. That does _exactly_ what
>
> git config --global diff.primer -M
>
> would do. It's just a syntax that saves us from having to introduce a boatload
> of new variables, one per command line option.
Great point, IOW, primer magnifies already existing pitfalls. I like that about
primer v1, however unsatisfying it is otherwise. Rather than stick a piece of
chewing gum in that chink in the dam, let's repair it and get the whole darn
thing ready for the 21st century while we're at it.
> However, there are two other drawbacks of aliases that I can think of:
> 1. They are tied to a specific command, whereas diff options are tied
> to the concept of diffing. So now I have to write an alias (with a
> new name) for each command:
> git config alias.mylog 'log -w'
> git config alias.mydiff 'diff -w'
> git config alias.myshow 'show -w'
> 2. They can't change defaults based on the file to be diffed. One of
> the things Keith mentioned (and I don't remember if this was
> implemented in his patch series) was supporting this for
> gitattributes diff drivers. How do I do
> git config diff.tex.primer -w
> using aliases?
This scenario was specifically part of my motivation for imagining primer v1 as
I did.
> But now you have me defending Keith's proposal
And well.
> which he should be doing himself ;P
True. I'm at the point here where I will demand of myself one of two outcomes.
Either I:
(1) Satisfy myself on a deep, foundational level why the inescapable structure
of not just this particularly well-constituted software project (Git!), but
software projects in general, since surely many a fearless development team has
braved this philosophical sticky place before us, prevents one from getting
everything one wants, i.e. forces a compromise, a.k.a. the "no silver bullet"
interpretation.
(2) Write primer patch v2 that somehow does THE RIGHT THING, also satisfying on
a deep level to at least myself, a.k.a. the silver bullet.
-- Keith
^ permalink raw reply
* Re: Valgrind updates
From: Linus Torvalds @ 2009-01-27 3:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901270327200.26199@intel-tinevez-2-302>
On Tue, 27 Jan 2009, Johannes Schindelin wrote:
>
> Just that much, most of the backtraces are pretty repetitive. In fact, I
> think most if not all of them touch xwrite.c (I got other errors from my
> patches, as I expected).
>
> ==valgrind== Syscall param write(buf) points to uninitialised byte(s)
> ==valgrind== at 0x5609E40: __write_nocancel (in /lib/libpthread-2.6.1.so)
> ==valgrind== by 0x4D0380: xwrite (wrapper.c:129)
> ==valgrind== by 0x4D046E: write_in_full (wrapper.c:159)
> ==valgrind== by 0x4C0697: write_buffer (sha1_file.c:2275)
> ==valgrind== by 0x4C0B1C: write_loose_object (sha1_file.c:2387)
Looks entirely bogus.
I suspect that valgrind for some reason doesn't see the writes made by
zlib as being initialization, possibly due to some incorrect valgrind
annotations on deflate(). We've just totally initialized that whole
buffer with deflate().
It definitely does not look like a git bug, but a valgrind run issue.
Linus
^ 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