* Re: [PATCH] Add --contains flag to git tag
From: Jake Goulding @ 2009-01-21 1:37 UTC (permalink / raw)
To: git
In-Reply-To: <1232501631-21531-3-git-send-email-goulding@vivisimo.com>
Ack - I sent that a bit before I meant to (and before I added patch sequence numbers).
This is a patch that adds a --contains flag to git tag, providing similar functionality as git branch --contains.
Please let me know what else I have inevitably messed up, and I shall endeavor to fix and resubmit.
-Jake
----- Original Message -----
From: "Jake Goulding" <goulding@vivisimo.com>
To: git@vger.kernel.org
Cc: "Jake Goulding" <goulding@vivisimo.com>
Sent: Tuesday, January 20, 2009 8:33:49 PM GMT -05:00 US/Canada Eastern
Subject: [PATCH] Add --contains flag to git tag
This functions similar to how --contains works for git branch - it
will show all tags that contain the specified commit. Indeed, it uses
the same lookup mechanisms as git branch.
Signed-off-by: Jake Goulding <goulding@vivisimo.com>
---
builtin-tag.c | 28 ++++++++++++++++++++++++++--
1 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index a398499..453ed26 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -26,6 +26,7 @@ static char signingkey[1000];
struct tag_filter {
const char *pattern;
int lines;
+ struct commit_list *with_commit;
};
#define PGP_SIGNATURE "-----BEGIN PGP SIGNATURE-----"
@@ -35,6 +36,15 @@ static int show_reference(const char *refname, const unsigned char *sha1,
{
struct tag_filter *filter = cb_data;
+ if (filter->with_commit) {
+ struct commit *commit;
+
+ commit = lookup_commit_reference_gently(sha1, 1);
+ if (!commit)
+ return error("branch '%s' does not point at a commit", refname);
+ if (!has_commit(commit, filter->with_commit))
+ return 0;
+ }
if (!fnmatch(filter->pattern, refname, 0)) {
int i;
unsigned long size;
@@ -79,7 +89,8 @@ static int show_reference(const char *refname, const unsigned char *sha1,
return 0;
}
-static int list_tags(const char *pattern, int lines)
+static int list_tags(const char *pattern, int lines,
+ struct commit_list *with_commit)
{
struct tag_filter filter;
@@ -88,6 +99,7 @@ static int list_tags(const char *pattern, int lines)
filter.pattern = pattern;
filter.lines = lines;
+ filter.with_commit = with_commit;
for_each_tag_ref(show_reference, (void *) &filter);
@@ -360,6 +372,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
list = 0, delete = 0, verify = 0;
const char *msgfile = NULL, *keyid = NULL;
struct msg_arg msg = { 0, STRBUF_INIT };
+ struct commit_list *with_commit = NULL;
struct option options[] = {
OPT_BOOLEAN('l', NULL, &list, "list tag names"),
{ OPTION_INTEGER, 'n', NULL, &lines, NULL,
@@ -378,6 +391,14 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
OPT_STRING('u', NULL, &keyid, "key-id",
"use another key to sign the tag"),
OPT_BOOLEAN('f', NULL, &force, "replace the tag if exists"),
+
+ OPT_GROUP("Tag listing options"),
+ {
+ OPTION_CALLBACK, 0, "contains", &with_commit, "commit",
+ "print only tags that contain the commit",
+ PARSE_OPT_LASTARG_DEFAULT,
+ parse_opt_with_commit, (intptr_t)"HEAD",
+ },
OPT_END()
};
@@ -402,9 +423,12 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
if (list + delete + verify > 1)
usage_with_options(git_tag_usage, options);
if (list)
- return list_tags(argv[0], lines == -1 ? 0 : lines);
+ return list_tags(argv[0], lines == -1 ? 0 : lines,
+ with_commit);
if (lines != -1)
die("-n option is only allowed with -l.");
+ if (with_commit)
+ die("--contains option is only allowed with -l.");
if (delete)
return for_each_tag_name(argv, delete_tag);
if (verify)
--
1.6.0.6
^ permalink raw reply related
* [PATCH 2/2 v2] valgrind: ignore ldso errors
From: Johannes Schindelin @ 2009-01-21 1:36 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901210216440.19014@racer>
On some Linux systems, we get a host of Cond and Addr errors
from calls to dlopen that are caused by nss modules. We
should be able to safely ignore anything happening in
ld-*.so as "not our problem."
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Only change vs v1: adds Addr4 suppression, so that ld.so "errors"
are ignored on 32-bit, too.
t/valgrind/default.supp | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/t/valgrind/default.supp b/t/valgrind/default.supp
index 2482b3b..6061283 100644
--- a/t/valgrind/default.supp
+++ b/t/valgrind/default.supp
@@ -11,6 +11,24 @@
}
{
+ ignore-ldso-cond
+ Memcheck:Cond
+ obj:*ld-*.so
+}
+
+{
+ ignore-ldso-addr8
+ Memcheck:Addr8
+ obj:*ld-*.so
+}
+
+{
+ ignore-ldso-addr4
+ Memcheck:Addr4
+ obj:*ld-*.so
+}
+
+{
writing-data-from-zlib-triggers-errors
Memcheck:Param
write(buf)
--
1.6.1.243.g6c8bb35
^ permalink raw reply related
* Re: how to keeping track of cherry-pick?
From: Junio C Hamano @ 2009-01-21 1:29 UTC (permalink / raw)
To: Knut Olav Bøhmer; +Cc: git
In-Reply-To: <497663E4.4000302@telenor.com>
Knut Olav Bøhmer <knut-olav.bohmer@telenor.com> writes:
> svnmerge.py can give us a list of revisions available for merging. The
> result is similar to "git log --chery-pick master..dev" The difference
> is that svnmerge.py operates on revision-numbers, and --chery-pick looks
> at the diffs. The result of that is that when we get a conflict when a
> patch is cherry-picked, it will still show up as "available" when I run
> "git log --cherry-pick master..dev"
I think you are looking at it a wrong way.
Because subversion (at least the older one) does not keep track of merges,
you had to track cherry-picks. But cherry-pick is not how you usually do
things in git. You keep many topic branches with different doneness, and
you merge well-cooked ones to the more stable integration branch while
leaving others still cooking. So what you want to know is not cherry-pick
status, but merge status.
Because git tracks merges, output from "git log master..$topic" gives all
you need to know about $topic. The command lists changes that are still
not merged to master on the $topic branch. If it is empty, $topic is
already merged fully to master. Otherwise you still have things to
merge.
To get a list of topics that have been merged (or not merged) to a
particular integration branch, you should be able to use "git branch" with
its --merged and --no-merged options. This does not list what commits
each yet-to-be-merged topics have, though.
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Johannes Schindelin @ 2009-01-21 1:26 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090121003739.GA18373@coredump.intra.peff.net>
Hi,
On Tue, 20 Jan 2009, Jeff King wrote:
> On Wed, Jan 21, 2009 at 01:28:01AM +0100, Johannes Schindelin wrote:
>
> > Actually, I test first if it is there, and only if it is not, try to
> > create the symlink.
> >
> > Now, there is still a very minor chance for a race, namely if two
> > processes happen to test the existence of the missing symlink at exactly
> > the same time, and both do not find it, so both processes will try to
> > create it.
>
> Yep. Though I find "minor chance" when it comes to races to really mean
> "annoying to debug". But...
Well, in this case, you will find that the "bug" is _at most_ some
binaries not being found.
And really, the chance is so small as to be forgotten in the clutter:
after the valgrind setup, there are so many other things which are done
that by the time we actually use the Git binaries, everything should be
okay.
And keep in mind, this _only_ matters if you do make -j _and_ you haven't
run --valgrind _ever_. Once the symlinks are there, they are there.
(Actually, with my new patch, the may be replaced, but _only_ if
necessary, and the same thing would apply as I said earlier: the binary
would not be found, or a binary from the PATH would be run without
valgrind; but the next runs will not have the problem.)
> > However, the symlink creation is not checked for success, so the
> > processes will still both run just fine.
>
> Yes, so there is no race in what is there currently. It's just sad that
> we can't detect any actual errors.
Now we can. I actually check for the correct link target now (which means
I also check for a link), and if it is incorrect, the link is recreated
(and the deletion is checked for errors).
> > There is a very subtle problem, though. If you screw with your
> > configuration, replacing a link in t/valgrind/ by a script, my code
> > will not try to undo it. However, I think that's really asking for
> > trouble, and you can get out of the mess by "rm -r t/valgrind/git*".
>
> I think we can safely ignore such mucking about in the valgrind
> directory as craziness.
You'll find that v2 copes with that, too.
> > Another problem which is potentially much more troublesome is this:
> > when there was a script by a certain name, my code would symlink it to
> > $GIT_DIR/$BASENAME (actually a relative path, but you get the idea).
> > If that script is turned into a builtin -- this list has certainly
> > known a certain person to push for that kind of conversion :-) -- that
> > fact is not picked up.
>
> Yes. One way around this is to generate a "want" and a "have" list, and
> then just operate on the differences. Something like (totally untested):
>
> (cd $GIT_VALGRIND && ls) | sort >have
> (cd $TEST_DIRECTORY/.. && ls git git-*) | sort >want
> comm -23 have want | xargs -r rm -v
> comm -13 have want | while read f; do ln -s ../../$f $GIT_VALGRIND/$f; done
>
> and then you are also cleaning every time you create.
The script will now pick up on those changes, and recreate the symlink
correctly.
We don't need cleaning, as we only link to $TEST_DIRECTORY/.. (at least
via valgrind.sh), and if the binary does not exist there, well, it does
not exist there, and the script will error out, saying so.
Ciao,
Dscho
^ permalink raw reply
* [INTERDIFF of PATCH 1/2 v2] Add valgrind support in test scripts
From: Johannes Schindelin @ 2009-01-21 1:11 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901210209580.19014@racer>
t/README | 6 +++++-
t/test-lib.sh | 32 +++++++++++++++++++++-----------
t/valgrind/.gitignore | 3 +--
t/valgrind/valgrind.sh | 4 ++--
4 files changed, 29 insertions(+), 16 deletions(-)
diff --git a/t/README b/t/README
index 8f12d48..0cee429 100644
--- a/t/README
+++ b/t/README
@@ -39,7 +39,8 @@ this:
* passed all 3 test(s)
You can pass --verbose (or -v), --debug (or -d), and --immediate
-(or -i) command line argument to the test.
+(or -i) command line argument to the test, or by setting GIT_TEST_OPTS
+appropriately before running "make".
--verbose::
This makes the test more verbose. Specifically, the
@@ -58,6 +59,9 @@ You can pass --verbose (or -v), --debug (or -d), and --immediate
This causes additional long-running tests to be run (where
available), for more exhaustive testing.
+--valgrind::
+ Execute all Git binaries with valgrind and stop on errors (the
+ exit code will be 126).
Skipping Tests
--------------
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 6bd893d..f031905 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -488,27 +488,37 @@ then
GIT_EXEC_PATH=$TEST_DIRECTORY/..
else
# override all git executables in PATH and TEST_DIRECTORY/..
- GIT_VALGRIND=$TEST_DIRECTORY/valgrind
+ GIT_VALGRIND=$TEST_DIRECTORY/valgrind/bin
mkdir -p "$GIT_VALGRIND"
OLDIFS=$IFS
IFS=:
- for path in $PATH:$TEST_DIRECTORY/..
+ for path in $PATH $TEST_DIRECTORY/..
do
- ls "$TEST_DIRECTORY"/../git "$path"/git-* 2> /dev/null |
+ ls "$path"/git "$path"/git-* 2> /dev/null |
while read file
do
# handle only executables
- test -x "$file" || continue
+ test -x "$file" && test ! -d "$file" || continue
base=$(basename "$file")
- test ! -h "$GIT_VALGRIND"/"$base" || continue
-
- if test "#!" = "$(head -c 2 < "$file")"
+ symlink_target=$TEST_DIRECTORY/../$base
+ # do not override scripts
+ if test -x "$symlink_target" &&
+ test "#!" != "$(head -c 2 < "$symlink_target")"
+ then
+ symlink_target=../valgrind.sh
+ fi
+ case "$base" in
+ *.sh|*.perl)
+ symlink_target=../unprocessed-script
+ esac
+ # create the link, or replace it if it is out of date
+ if test ! -h "$GIT_VALGRIND"/"$base" ||
+ test "$symlink_target" != \
+ "$(readlink "$GIT_VALGRIND"/"$base")"
then
- # do not override scripts
- ln -s ../../"$base" "$GIT_VALGRIND"/"$base"
- else
- ln -s valgrind.sh "$GIT_VALGRIND"/"$base"
+ rm -f "$GIT_VALGRIND"/"$base" || exit
+ ln -s "$symlink_target" "$GIT_VALGRIND"/"$base"
fi
done
done
diff --git a/t/valgrind/.gitignore b/t/valgrind/.gitignore
index d781a63..ae3c172 100644
--- a/t/valgrind/.gitignore
+++ b/t/valgrind/.gitignore
@@ -1,2 +1 @@
-/git
-/git-*
+/bin/
diff --git a/t/valgrind/valgrind.sh b/t/valgrind/valgrind.sh
index 24f3a4e..2c4b54b 100755
--- a/t/valgrind/valgrind.sh
+++ b/t/valgrind/valgrind.sh
@@ -4,9 +4,9 @@ base=$(basename "$0")
exec valgrind -q --error-exitcode=126 \
--leak-check=no \
- --suppressions="$GIT_VALGRIND/default.supp" \
+ --suppressions="$GIT_VALGRIND/../default.supp" \
--gen-suppressions=all \
--log-fd=4 \
--input-fd=4 \
$GIT_VALGRIND_OPTIONS \
- "$GIT_VALGRIND"/../../"$base" "$@"
+ "$GIT_VALGRIND"/../../../"$base" "$@"
^ permalink raw reply related
* [PATCH 1/2 v2] Add valgrind support in test scripts
From: Johannes Schindelin @ 2009-01-21 1:10 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090121001219.GA18169@coredump.intra.peff.net>
This patch adds the ability to use valgrind's memcheck tool to
diagnose memory problems in git while running the test scripts. It
works by placing a "fake" git in the front of the test script's PATH;
this fake git runs the real git under valgrind. It also points the
exec-path such that any stand-alone dashed git programs are run using
the same script. In this way we avoid having to modify the actual git
code in any way.
To be certain that every call to any git executable is intercepted,
the PATH is searched for executables beginning with "git-"; Scripts
are excluded however.
Valgrind can be used by specifying "GIT_TEST_OPTS=--valgrind" in the
make invocation. Any invocation of git that finds any errors under
valgrind will exit with failure code 126. Any valgrind output will go
to the usual stderr channel for tests (i.e., /dev/null, unless -v has
been specified).
If you need to pass options to valgrind -- you might want to run
another tool than memcheck, for example -- you can set the environment
variable GIT_VALGRIND_OPTIONS.
A few default suppressions are included, since libz seems to
trigger quite a few false positives. We'll assume that libz
works and that we can ignore any errors which are reported
there.
Initial patch and all the hard work by Jeff King.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Changes vs v1:
- the symlinks will be created in t/valgrind/bin/ again, as it is
easier to remove the whole directory than weed out the unwanted
files from t/valgrind/.
- symbolic links are inspected for correct targets now, and if they
point somewhere else than expected, they are removed (this can
error out if the file could not be removed) and recreated.
- if the executable ends in ".sh" or ".perl", the target will be
set to a non-existing file (to catch invocations, erroring out).
- the Git binaries from the root are actually found now (IFS is
only interpreted after the file is parsed, it seems).
- added rudimentary documentation to t/README.
Interdiff to follow.
t/README | 6 ++++-
t/test-lib.sh | 49 +++++++++++++++++++++++++++++++++++++++++++++-
t/valgrind/.gitignore | 1 +
t/valgrind/default.supp | 21 ++++++++++++++++++++
t/valgrind/valgrind.sh | 12 +++++++++++
5 files changed, 86 insertions(+), 3 deletions(-)
create mode 100644 t/valgrind/.gitignore
create mode 100644 t/valgrind/default.supp
create mode 100755 t/valgrind/valgrind.sh
diff --git a/t/README b/t/README
index 8f12d48..0cee429 100644
--- a/t/README
+++ b/t/README
@@ -39,7 +39,8 @@ this:
* passed all 3 test(s)
You can pass --verbose (or -v), --debug (or -d), and --immediate
-(or -i) command line argument to the test.
+(or -i) command line argument to the test, or by setting GIT_TEST_OPTS
+appropriately before running "make".
--verbose::
This makes the test more verbose. Specifically, the
@@ -58,6 +59,9 @@ You can pass --verbose (or -v), --debug (or -d), and --immediate
This causes additional long-running tests to be run (where
available), for more exhaustive testing.
+--valgrind::
+ Execute all Git binaries with valgrind and stop on errors (the
+ exit code will be 126).
Skipping Tests
--------------
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 79f69de..f031905 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -94,6 +94,8 @@ do
--no-python)
# noop now...
shift ;;
+ --va|--val|--valg|--valgr|--valgri|--valgrin|--valgrind)
+ valgrind=t; shift ;;
*)
break ;;
esac
@@ -480,8 +482,51 @@ test_done () {
# Test the binaries we have just built. The tests are kept in
# t/ subdirectory and are run in 'trash directory' subdirectory.
TEST_DIRECTORY=$(pwd)
-PATH=$TEST_DIRECTORY/..:$PATH
-GIT_EXEC_PATH=$(pwd)/..
+if test -z "$valgrind"
+then
+ PATH=$TEST_DIRECTORY/..:$PATH
+ GIT_EXEC_PATH=$TEST_DIRECTORY/..
+else
+ # override all git executables in PATH and TEST_DIRECTORY/..
+ GIT_VALGRIND=$TEST_DIRECTORY/valgrind/bin
+ mkdir -p "$GIT_VALGRIND"
+ OLDIFS=$IFS
+ IFS=:
+ for path in $PATH $TEST_DIRECTORY/..
+ do
+ ls "$path"/git "$path"/git-* 2> /dev/null |
+ while read file
+ do
+ # handle only executables
+ test -x "$file" && test ! -d "$file" || continue
+
+ base=$(basename "$file")
+ symlink_target=$TEST_DIRECTORY/../$base
+ # do not override scripts
+ if test -x "$symlink_target" &&
+ test "#!" != "$(head -c 2 < "$symlink_target")"
+ then
+ symlink_target=../valgrind.sh
+ fi
+ case "$base" in
+ *.sh|*.perl)
+ symlink_target=../unprocessed-script
+ esac
+ # create the link, or replace it if it is out of date
+ if test ! -h "$GIT_VALGRIND"/"$base" ||
+ test "$symlink_target" != \
+ "$(readlink "$GIT_VALGRIND"/"$base")"
+ then
+ rm -f "$GIT_VALGRIND"/"$base" || exit
+ ln -s "$symlink_target" "$GIT_VALGRIND"/"$base"
+ fi
+ done
+ done
+ IFS=$OLDIFS
+ PATH=$GIT_VALGRIND:$PATH
+ GIT_EXEC_PATH=$GIT_VALGRIND
+ export GIT_VALGRIND
+fi
GIT_TEMPLATE_DIR=$(pwd)/../templates/blt
unset GIT_CONFIG
GIT_CONFIG_NOSYSTEM=1
diff --git a/t/valgrind/.gitignore b/t/valgrind/.gitignore
new file mode 100644
index 0000000..ae3c172
--- /dev/null
+++ b/t/valgrind/.gitignore
@@ -0,0 +1 @@
+/bin/
diff --git a/t/valgrind/default.supp b/t/valgrind/default.supp
new file mode 100644
index 0000000..2482b3b
--- /dev/null
+++ b/t/valgrind/default.supp
@@ -0,0 +1,21 @@
+{
+ ignore-zlib-errors-cond
+ Memcheck:Cond
+ obj:*libz.so*
+}
+
+{
+ ignore-zlib-errors-value4
+ Memcheck:Value4
+ obj:*libz.so*
+}
+
+{
+ writing-data-from-zlib-triggers-errors
+ Memcheck:Param
+ write(buf)
+ obj:/lib/ld-*.so
+ fun:write_in_full
+ fun:write_buffer
+ fun:write_loose_object
+}
diff --git a/t/valgrind/valgrind.sh b/t/valgrind/valgrind.sh
new file mode 100755
index 0000000..2c4b54b
--- /dev/null
+++ b/t/valgrind/valgrind.sh
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+base=$(basename "$0")
+
+exec valgrind -q --error-exitcode=126 \
+ --leak-check=no \
+ --suppressions="$GIT_VALGRIND/../default.supp" \
+ --gen-suppressions=all \
+ --log-fd=4 \
+ --input-fd=4 \
+ $GIT_VALGRIND_OPTIONS \
+ "$GIT_VALGRIND"/../../../"$base" "$@"
--
1.6.1.243.g6c8bb35
^ permalink raw reply related
* Re: [PATCH 1/2] Add valgrind support in test scripts
From: Johannes Schindelin @ 2009-01-21 0:41 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090121001219.GA18169@coredump.intra.peff.net>
Hi,
On Tue, 20 Jan 2009, Jeff King wrote:
> On Tue, Jan 20, 2009 at 04:04:28PM +0100, Johannes Schindelin wrote:
>
> > +else
> > + # override all git executables in PATH and TEST_DIRECTORY/..
> > + GIT_VALGRIND=$TEST_DIRECTORY/valgrind
> > + mkdir -p "$GIT_VALGRIND"
>
> Isn't this mkdir unnecessary, since it is actually part of the
> repository (i.e., there is a gitignore there already).
>
> However, I think it makes more sense to put the symlink cruft into
> "$GIT_VALGRIND/bin". That way you can clean up the cruft very easily. In
> which case you do need to "mkdir" that directory.
Hmm. I actually liked the hierarchy to be shallow, but I could be
convinced...
> > + OLDIFS=$IFS
> > + IFS=:
> > + for path in $PATH:$TEST_DIRECTORY/..
> > + do
> > + ls "$TEST_DIRECTORY"/../git "$path"/git-* 2> /dev/null |
>
> Why aren't these both "$path"/ ?
Yeah. Makes it more readable, doesn't it?
> But more importantly, do we really need to bother overriding the whole
> $PATH? In theory, we aren't calling anything git-* that isn't in
> "$TEST_DIRECTORY/..". And while it might be nice to catch it if we do,
> it seems like detecting that is totally orthogonal to running valgrind,
> and we get different behavior from valgrind versus not. And I think the
> two should be as similar as possible (with the obvious except of
> actually, you know, running valgrind).
Actually, the two _are_ orthogonal from the technical viewpoint.
But with the infrastructure we have in place, it was already very easy to
make sure that calls to a Git program we no longer ship are caught.
I vividly remember such a bug costing me 3 hours of my life, and a few
hairs.
So I think "as it's already _that_ easy, we should catch them bugs, too".
Needs some documentation though, I agree.
> > + base=$(basename "$file")
> > + test ! -h "$GIT_VALGRIND"/"$base" || continue
> > +
> > + if test "#!" = "$(head -c 2 < "$file")"
> > + then
> > + # do not override scripts
> > + ln -s ../../"$base" "$GIT_VALGRIND"/"$base"
> > + else
> > + ln -s valgrind.sh "$GIT_VALGRIND"/"$base"
> > + fi
>
> It would be nice to actually detect errors. But you have to
> differentiate between EEXIST and other errors, which is a pain. And you
> can't use "ln -sf" because it isn't atomic.
I really would not care all that much about that.
'GIT_TEST_OPTS==--valgrind make test' should be run by experts. And even
if it is a dummy driving the test, the next "make" call should take care
of that.
> Copying would solve that (provided you copied to a tempfile and did
> an atomic rename). Or writing this snippet as a C helper.
Nah, that is really too much work for such a rare thing. Think about it.
The symlinks are set up once. And even if you do that with -j50, there is
hardly a chance that two processes conflict with each other, and even if
they do, they do the same thing.
No, what I really want to fix is a script being replaced by a binary.
> > --- /dev/null
> > +++ b/t/valgrind/valgrind.sh
> > @@ -0,0 +1,12 @@
> > +#!/bin/sh
> > +
> > +base=$(basename "$0")
> > +
> > +exec valgrind -q --error-exitcode=126 \
> > + --leak-check=no \
> > + --suppressions="$GIT_VALGRIND/default.supp" \
> > + --gen-suppressions=all \
> > + --log-fd=4 \
> > + --input-fd=4 \
> > + $GIT_VALGRIND_OPTIONS \
> > + "$GIT_VALGRIND"/../../"$base" "$@"
>
> Hm. My version had to do some magic with the GIT_EXEC_PATH, but I think
> that is because I didn't set GIT_EXEC_PATH in the first place. If yours
> works (and I haven't really tested it -- I remember it being a real pain
> in the butt to make sure valgrind was getting called from every code
> path), then I like your approach much better.
I set GIT_EXEC_PATH... to $GIT_VALGRIND.
Ciao,
Dscho
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Jeff King @ 2009-01-21 0:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901210119510.19014@racer>
On Wed, Jan 21, 2009 at 01:28:01AM +0100, Johannes Schindelin wrote:
> Actually, I test first if it is there, and only if it is not, try to
> create the symlink.
>
> Now, there is still a very minor chance for a race, namely if two
> processes happen to test the existence of the missing symlink at exactly
> the same time, and both do not find it, so both processes will try to
> create it.
Yep. Though I find "minor chance" when it comes to races to really mean
"annoying to debug". But...
> However, the symlink creation is not checked for success, so the processes
> will still both run just fine.
Yes, so there is no race in what is there currently. It's just sad that
we can't detect any actual errors.
> There is a very subtle problem, though. If you screw with your
> configuration, replacing a link in t/valgrind/ by a script, my code will
> not try to undo it. However, I think that's really asking for trouble,
> and you can get out of the mess by "rm -r t/valgrind/git*".
I think we can safely ignore such mucking about in the valgrind
directory as craziness.
> Another problem which is potentially much more troublesome is this:
> when there was a script by a certain name, my code would symlink it
> to $GIT_DIR/$BASENAME (actually a relative path, but you get the
> idea). If that script is turned into a builtin -- this list has certainly
> known a certain person to push for that kind of conversion :-) -- that
> fact is not picked up.
Yes. One way around this is to generate a "want" and a "have" list, and
then just operate on the differences. Something like (totally untested):
(cd $GIT_VALGRIND && ls) | sort >have
(cd $TEST_DIRECTORY/.. && ls git git-*) | sort >want
comm -23 have want | xargs -r rm -v
comm -13 have want | while read f; do ln -s ../../$f $GIT_VALGRIND/$f; done
and then you are also cleaning every time you create.
-Peff
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Johannes Schindelin @ 2009-01-21 0:28 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090121001551.GB18169@coredump.intra.peff.net>
Hi,
On Tue, 20 Jan 2009, Jeff King wrote:
> On Wed, Jan 21, 2009 at 01:10:22AM +0100, Johannes Schindelin wrote:
>
> > > Hmm. I suppose that would work, since every test run is trying to create
> > > the same state.
> >
> > Yep, that's what I meant with "no race".
>
> Right, but it is still possible to screw it up, if your creation process
> does a delete-create. But it looks like you did it correctly in your
> patch (try to create, and if you fail because it's there, assume it's
> right).
Actually, I test first if it is there, and only if it is not, try to
create the symlink.
Now, there is still a very minor chance for a race, namely if two
processes happen to test the existence of the missing symlink at exactly
the same time, and both do not find it, so both processes will try to
create it.
However, the symlink creation is not checked for success, so the processes
will still both run just fine.
There is a very subtle problem, though. If you screw with your
configuration, replacing a link in t/valgrind/ by a script, my code will
not try to undo it. However, I think that's really asking for trouble,
and you can get out of the mess by "rm -r t/valgrind/git*".
Another problem which is potentially much more troublesome is this:
when there was a script by a certain name, my code would symlink it
to $GIT_DIR/$BASENAME (actually a relative path, but you get the
idea). If that script is turned into a builtin -- this list has certainly
known a certain person to push for that kind of conversion :-) -- that
fact is not picked up.
But I think I have an easy solution for that.
> > In any case, I already found a bug in the nth_last series, thanks to
> > your work, which I'll send in a minute.
>
> Yay! It's nice when infrastructure work like this actually pays off.
Yep! Thanks!
> Thanks for picking up this topic...I can drop the size of my
> ever-growing git todo list by one. :)
Actually, don't remind me... of my TODO list.
Ciao,
Dscho
^ permalink raw reply
* [VALGRIND PATCH for nth_last patch series] Fix invalid memory access
From: Johannes Schindelin @ 2009-01-21 0:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <alpine.DEB.1.00.0901191331590.3586@pacific.mpi-cbg.de>
Please squash in.
---
On Mon, 19 Jan 2009, Johannes Schindelin wrote:
> @@ -720,7 +718,7 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
> if (target[len] == '\n' && !strncmp(match, target, len))
> return 0;
This code is still not valid, as target[len] can be well after the
NUL marker.
Found by valgrind.
sha1_name.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 4d10705..803f9d2 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -735,7 +735,7 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
if ((target = strstr(match, " to ")) != NULL) {
len = target - match;
target += 4;
- if (target[len] == '\n' && !strncmp(match, target, len))
+ if (len == strlen(target) && !strncmp(match, target, len))
return 0;
}
else
--
1.6.1.243.g6c8bb35
^ permalink raw reply related
* how to keeping track of cherry-pick?
From: Knut Olav Bøhmer @ 2009-01-20 23:53 UTC (permalink / raw)
To: git
Hi,
We are changing from subversion to git. We used to merge revisions from
development branch to stable with svnmerge.py.
svnmerge.py can give us a list of revisions available for merging. The
result is similar to "git log --chery-pick master..dev" The difference
is that svnmerge.py operates on revision-numbers, and --chery-pick looks
at the diffs. The result of that is that when we get a conflict when a
patch is cherry-picked, it will still show up as "available" when I run
"git log --cherry-pick master..dev"
svnmerge.py can also mark revisions as blocked, and will not show up in
the list of available revisions.
How can I keep track of cherry-picked patches, and mark patches as
"blocked", in the same (or similar) way as I did in subversion with
svnmerge.py?
--
Knut Olav Bøhmer
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Jeff King @ 2009-01-21 0:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901210105470.19014@racer>
On Wed, Jan 21, 2009 at 01:10:22AM +0100, Johannes Schindelin wrote:
> > Hmm. I suppose that would work, since every test run is trying to create
> > the same state.
>
> Yep, that's what I meant with "no race".
Right, but it is still possible to screw it up, if your creation process
does a delete-create. But it looks like you did it correctly in your
patch (try to create, and if you fail because it's there, assume it's
right).
> Heh. Okay. I was convinced that your valgrind patch predated my -j<n>
> patch...
I think I did an early version that did predate it, but then another
round afterwards.
> In any case, I already found a bug in the nth_last series, thanks to your
> work, which I'll send in a minute.
Yay! It's nice when infrastructure work like this actually pays off.
Thanks for picking up this topic...I can drop the size of my
ever-growing git todo list by one. :)
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] Add valgrind support in test scripts
From: Jeff King @ 2009-01-21 0:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901201602410.5159@intel-tinevez-2-302>
On Tue, Jan 20, 2009 at 04:04:28PM +0100, Johannes Schindelin wrote:
> +else
> + # override all git executables in PATH and TEST_DIRECTORY/..
> + GIT_VALGRIND=$TEST_DIRECTORY/valgrind
> + mkdir -p "$GIT_VALGRIND"
Isn't this mkdir unnecessary, since it is actually part of the
repository (i.e., there is a gitignore there already).
However, I think it makes more sense to put the symlink cruft into
"$GIT_VALGRIND/bin". That way you can clean up the cruft very easily. In
which case you do need to "mkdir" that directory.
> + OLDIFS=$IFS
> + IFS=:
> + for path in $PATH:$TEST_DIRECTORY/..
> + do
> + ls "$TEST_DIRECTORY"/../git "$path"/git-* 2> /dev/null |
Why aren't these both "$path"/ ?
But more importantly, do we really need to bother overriding the whole
$PATH? In theory, we aren't calling anything git-* that isn't in
"$TEST_DIRECTORY/..". And while it might be nice to catch it if we do,
it seems like detecting that is totally orthogonal to running valgrind,
and we get different behavior from valgrind versus not. And I think the
two should be as similar as possible (with the obvious except of
actually, you know, running valgrind).
> + base=$(basename "$file")
> + test ! -h "$GIT_VALGRIND"/"$base" || continue
> +
> + if test "#!" = "$(head -c 2 < "$file")"
> + then
> + # do not override scripts
> + ln -s ../../"$base" "$GIT_VALGRIND"/"$base"
> + else
> + ln -s valgrind.sh "$GIT_VALGRIND"/"$base"
> + fi
It would be nice to actually detect errors. But you have to
differentiate between EEXIST and other errors, which is a pain. And you
can't use "ln -sf" because it isn't atomic.
Copying would solve that (provided you copied to a tempfile and did
an atomic rename). Or writing this snippet as a C helper.
> --- /dev/null
> +++ b/t/valgrind/valgrind.sh
> @@ -0,0 +1,12 @@
> +#!/bin/sh
> +
> +base=$(basename "$0")
> +
> +exec valgrind -q --error-exitcode=126 \
> + --leak-check=no \
> + --suppressions="$GIT_VALGRIND/default.supp" \
> + --gen-suppressions=all \
> + --log-fd=4 \
> + --input-fd=4 \
> + $GIT_VALGRIND_OPTIONS \
> + "$GIT_VALGRIND"/../../"$base" "$@"
Hm. My version had to do some magic with the GIT_EXEC_PATH, but I think
that is because I didn't set GIT_EXEC_PATH in the first place. If yours
works (and I haven't really tested it -- I remember it being a real pain
in the butt to make sure valgrind was getting called from every code
path), then I like your approach much better.
-Peff
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Johannes Schindelin @ 2009-01-21 0:10 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090120232439.GA17746@coredump.intra.peff.net>
Hi,
On Tue, 20 Jan 2009, Jeff King wrote:
> On Tue, Jan 20, 2009 at 03:50:28PM +0100, Johannes Schindelin wrote:
>
> > > How will you deal with race conditions between two simultaneously
> > > running scripts? I.e., where are you going to put it?
> >
> > There are no race conditions, as for every git executable, a symbolic
> > link is created, pointing to the valgrind.sh script [*1*].
>
> Hmm. I suppose that would work, since every test run is trying to create
> the same state.
Yep, that's what I meant with "no race".
> > Besides, what with valgrind being a memory hog, you'd be nuts to call
> > valgrinded scripts simultaneously.
>
> I have to disagree there. I think there are two obvious usage patterns:
>
> - run script $X specifically under valgrind to track down a bug
>
> - run the whole test suite under valgrind occasionally to find
> latent bugs that wouldn't otherwise show up
>
> In the latter, you want a pretty beefy box. When I did the original
> patches, I ran through the whole test suite under valgrind. It took
> several hours on a 6GB quad-core box, using "-j4". I would hate for it
> to have taken an entire day. :)
Heh. Okay. I was convinced that your valgrind patch predated my -j<n>
patch...
In any case, I already found a bug in the nth_last series, thanks to your
work, which I'll send in a minute.
Ciao,
Dscho
^ permalink raw reply
* Re: Newbie Query
From: Johannes Schindelin @ 2009-01-21 0:05 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Morey-Chaisemartin, Boyd Stephen Smith Jr., git
In-Reply-To: <20090120235125.GD17746@coredump.intra.peff.net>
Hi,
On Tue, 20 Jan 2009, Jeff King wrote:
> On Tue, Jan 20, 2009 at 10:46:47PM +0100, Nicolas Morey-Chaisemartin wrote:
>
> > Well I know there are solutions to convert it to a bare repo.
> > I was just wondering if there was a "clean" one which really converts
> > the repo to a bare one and not create a copy which is bare.
>
> It has been a long time since I have done this. It used to be that you
> could simply "mv foo/.git foo.git" and be done with it. These days I
> think you would also need "git config core.bare true". But I haven't
> actually tested it recently.
Yep, you need to set that option. At least if you initialized your
repository with anything newer than v1.5.0-rc1~3^2~2.
Ciao,
Dscho
^ permalink raw reply
* Re: An idea: maybe Git should use a lock/unlock file mode for problematic files? [Was: Re: after first git clone of linux kernel repository there are changed files in working dir]
From: Daniel Barkalow @ 2009-01-21 0:03 UTC (permalink / raw)
To: Alex Riesen; +Cc: John Chapman, Hannu Koivisto, rdkrsr, git
In-Reply-To: <81b0412b0901201525w22513418p57acc19457908a3@mail.gmail.com>
On Wed, 21 Jan 2009, Alex Riesen wrote:
> 2009/1/20 Daniel Barkalow <barkalow@iabervon.org>:
> > My impression was that this didn't happen in practice, because teams
> > would tend to not have two people create the same file at the same time,
> > but with different cases, and people interacting with the same file at
> > different times would use whatever case it was introduced with.
>
> It will and does happen in practice (annoingly too often even). Not with Git
> yet (with Perforce), where people do "branching" by simply copying things
> in another directory (perforce world does not know real branches),
> renaming files randomly, and putting the new directory back in the
> system (or maybe it is the strange tools here which do that - often
> it is the first character of a directory or file which gets down- or up-cased).
How does the resulting code work at all? With a case-sensitive filesystem,
most of the files you're using don't have the expected names any more, and
most systems will therefore not actually build or run.
I have to assume it's your strange tools, because we never have this
problem at my work, where we also use Perforce. Perhaps it's that we
always use "p4 integrate //some/project/version/...
//some/other/project/version/..." which inherently preserves the case of
all of the filenames within the project.
> As Perforce itself is case sensitive (like Git), using of such branches
> is a nightmare: the files get overwritten in checkout order which is
> not always sorted in predictable order. Combined with case-stupidity
> of the file system the working directories sometimes cause "interesting
> time" for unlucky users.
> Luckily (sadly) it is all-opening-in-a-wall shop, so the problem with "fanthom"
> files is rare (it is hard to notice) for most. Which actually makes it more
> frustrating when the real shit happens.
>
> And it will happen to Git as well, especially if development go crossplatform.
> It is not that hard to accidentally rename a file on case-sensitive file system,
> "git add *" it and commit without thinking (that's how most of software
> development happens, come to think of it).
People can accidentally rename files? And still have things work when they
do it on a case-sensitive filesystem?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Newbie Query
From: Jeff King @ 2009-01-20 23:51 UTC (permalink / raw)
To: Nicolas Morey-Chaisemartin; +Cc: Boyd Stephen Smith Jr., git
In-Reply-To: <49764647.1080606@morey-chaisemartin.com>
On Tue, Jan 20, 2009 at 10:46:47PM +0100, Nicolas Morey-Chaisemartin wrote:
> Well I know there are solutions to convert it to a bare repo.
> I was just wondering if there was a "clean" one which really converts
> the repo to a bare one and not create a copy which is bare.
It has been a long time since I have done this. It used to be that you
could simply "mv foo/.git foo.git" and be done with it. These days I
think you would also need "git config core.bare true". But I haven't
actually tested it recently.
You may also want to tweak other config settings (e.g., bare
repositories do not generally have reflogs turned on, but non-bare do).
-Peff
^ permalink raw reply
* Re: [JGIT PATCH] Fix TreeWalk.idEqual when both trees are missing the path
From: Robin Rosenberg @ 2009-01-20 23:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: tomi.pakarinen, git
In-Reply-To: <1232387556-10289-1-git-send-email-spearce@spearce.org>
måndag 19 januari 2009 18:52:36 skrev Shawn O. Pearce:
> The Javadoc of idEqual() says its simply a faster form of
> getObjectId(nthA).equals(getObjectId(nthB)), but its code
> didn't match that definition when both trees didn't exist
> at the current path.
Great. I think we're almost ready for merge. First a few test
cases below. If you think they are ok, I'll add them after the
(simple) merge implementation, or maybe squash.
However there is a conflict with the CanonicalTreeParsers here and
in master. Shawn: Could you resolve that and resubmit patch 5 rebased on main?
-- robin
From 7e8fd54d304bac1fcf08e29c9b8a208c9d0be743 Mon Sep 17 00:00:00 2001
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Date: Mon, 19 Jan 2009 23:09:09 +0100
Subject: [JGIT PATCH] Add a few simple merge test cases
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../spearce/jgit/test/resources/create-second-pack | 13 +++-
...ck-3280af9c07ee18a87705ef50b0cc4cd20266cf12.idx | Bin 0 -> 1296 bytes
...k-3280af9c07ee18a87705ef50b0cc4cd20266cf12.pack | Bin 0 -> 562 bytes
...ck-9fb5b411fe6dfa89cc2e6b89d2bd8e5de02b5745.idx | Bin 1088 -> 1100 bytes
...ck-df2982f284bbabb6bdb59ee3fcc6eb0983e20371.idx | Bin 2696 -> 2976 bytes
...k-df2982f284bbabb6bdb59ee3fcc6eb0983e20371.pack | Bin 5956 -> 5901 bytes
.../org/spearce/jgit/test/resources/packed-refs | 6 +-
.../org/spearce/jgit/lib/RepositoryTestCase.java | 3 +-
.../org/spearce/jgit/merge/SimpleMergeTest.java | 86 ++++++++++++++++++++
9 files changed, 103 insertions(+), 5 deletions(-)
create mode 100644 org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-3280af9c07ee18a87705ef50b0cc4cd20266cf12.idx
create mode 100644 org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-3280af9c07ee18a87705ef50b0cc4cd20266cf12.pack
create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/merge/SimpleMergeTest.java
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/create-second-pack b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/create-second-pack
index 052877d..5501a67 100755
--- a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/create-second-pack
+++ b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/create-second-pack
@@ -138,7 +138,18 @@ done
git repack -d
+git checkout -b f a
+mkdir f
+echo "an eff" >f/f
+git add f/f
+git commit -m "An eff"
+git checkout -b g a
+mkdir f
+echo "an F" >f/f
+git add f/f
+git commit -m "An F"
+git repack -d
git pack-refs --all
-qgit --all master
+gitk --all master
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-3280af9c07ee18a87705ef50b0cc4cd20266cf12.idx b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-3280af9c07ee18a87705ef50b0cc4cd20266cf12.idx
new file mode 100644
index 0000000000000000000000000000000000000000..300c0cea48c6c4eda2b870b3631355c2137cebb0
GIT binary patch
literal 1296
zcmexg;-AdGz`z8=xBw$if)Wfen|Y98R-n6x!E8Wvw8HE_v#E_afM$;3(J&x74Y2LV
z)Q$1iT(-xv{o%d?ezP~d30WlO{o~}bSuv7YXEk0%y}!Bi+NY5F;<3>Ud#7h~`1YT>
zpf~%nNr$-eG+Xt8#O{s4dXa}k?k(2XVRih3k&*4s=J(gu+%LX=d`sY>$NY6y^vccL
zFK5=6yT6d|<2_P&W-sI8NG8+rIE_yi-_5-HB{Hf?{<GXKDS;Zn=f$-%{*{*K-dyoz
z&(nux&wt#UJNGfeC6_5O>cO{}3Ii^?mL8a&y=G5Sv+Zu7cmBCoC&;S-%NRy4AT9!?
z`vpMy1+YjH0J3?2>?R=nM4az|fajV^sv(TevSnRfJoL#bbLi`ut*5^~(=3sT{r8l`
LdIkBjci#j6ga?3q
literal 0
HcmV?d00001
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-3280af9c07ee18a87705ef50b0cc4cd20266cf12.pack b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-3280af9c07ee18a87705ef50b0cc4cd20266cf12.pack
new file mode 100644
index 0000000000000000000000000000000000000000..fca3460ed2d263db153ef11a3e559aa47be9efa1
GIT binary patch
literal 562
zcmWG=boORoU|<4bj+wj_bLMu(avd@dV7p)3wYNd_w#iMsjvLl57%x5H=K9t?sp<Ik
zy-ohcJU(|Bgw!K{Gkv_Y)iV2yx4Bxy1{RN(o3pO*q+i>SxK8BLij_wrj#O`T2rS%|
zUidH}#Dz~P_m$6`*V#8S7O30$?L3y2f3D=Xx!-Gc->7BMhQ+Jj+_2mgvGJNrY1Q>E
z`!M4(EkS4a)5PtqUNAR^RLt3ZvSM!F_9Ysop$AQ_o=`fgan!){>Lnvp)w4&gTr#<6
zbJ0Ne><t4`-HQenFC4JBdBNan&7yZ)YUX+jzt0Q2UdLK7$Jmg8snw;eQ&#wAvg(}L
zl3h94ac_R_Q2Cq@G><bvueUMReOX@5{%4zP=e_0sF8g8j-j}{7l$@EFjfI6<?;LqF
z>59_cNnJv1%X-D5F2%7O*}gP)y~fA+sX;sDEEi;$xJmWcT1KEPCI$w^hJhZ*0-ygC
ze!96v!gK9rDgDLw?#EQU4L(uJFlPtvbn}Wi-e-b6e7zqtF>ux~X%pkRgJF9WHdZg*
z5cec;Vs*D^S%j>8VoFLzLPA>7q6xDjVkSi`2@eW9bYaU!C+}OQ8-8rt@>W#!-)0}K
z>7PxQ7@WVWFrc_@!{3{K{@t4O`{?)ne9o9JGxophirXp4u;mKxJX5gi3V?27nZf8F
Z&i6pTbIm2y5XNWOvMw(k`ec<k001O50^|Sy
literal 0
HcmV?d00001
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-9fb5b411fe6dfa89cc2e6b89d2bd8e5de02b5745.idx b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-9fb5b411fe6dfa89cc2e6b89d2bd8e5de02b5745.idx
index cf58d5baa11824217bb0c5eab7444fb406219885..58b712f6c58e3b99abd536c17c306ef2c37c5238 100644
GIT binary patch
delta 89
zcmV-f0H*)I2+Rlw|8!4d00002kpW(@UZMj;7j}SvqA`rvo4QPkhl4}`;t5v+%)Fm1
v0000CGYgnnQ2?6FEimT$X76fU(jBSR$3y!oeS1unZtru#oQ%-R@OV6B4p%0y
literal 1088
zcmZQzpebMknm&q0!(cQG4Bj-rBVN|fu*k6I#_U}_-R;dTjE^|OnT@$;L<KU;I;(5&
j?04Gxtk_GkE3duSzFw<E`CW}`!gtH2lI+N+ZF^b)CtDqp
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-df2982f284bbabb6bdb59ee3fcc6eb0983e20371.idx b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-df2982f284bbabb6bdb59ee3fcc6eb0983e20371.idx
index 2579301b8447e4d55480f65ae6c27fe1eb99bf4d..3ff542377406158d8155129ae66fc0b51cba76b8 100644
GIT binary patch
delta 1975
zcmWNSc{~(o9L8VczD?s85wmDmCU<REE7_%?a(yIa3Nhujj!cFI!x(prt4tc2lCznL
z1~tkN*3sk&Z76pK<xDp1`^WqFywCG~f6x28f4y`imWssBXy*$600c{ff@n4!@-K4*
zh&E+cMsP%Ib<EEyNg~_)<6Z=z@v&lR&4t^o{5zON$(63T8`MI*TJpp#7UthPAzfOc
zlyz+6vCLqF@J2mU$LOeTUUpuRf{5UCEp}(q*rmd}hnHb5?x{MYFmbx@5(WhVT^1(X
zog&=aI9Bs}ggMsT%6*iUi?KF(51%v80Z!80O5c~}T}7;?f9zY{pjX?po{6)4p}hSG
zlzCk0IJh3wY`JgCbeOr=uK9Z8%1+SCZoz?POdQGFPH=ox19Pu#;j#r@gY}e1-X<*8
ztg+3zu`%e}u|U$ulM|81z|3FJ^;VmwapsJJkGG1&aa+H3thG=i6+bmj_TbvrmCoc$
zc-yFT6Q)bDggm<Y)Qu}Sk;Arc{@X<mxt;$l9oOn`m^eDS&^agm4)w8xB*YDNdr2e5
zzr&jva1$*1^6a;>iUlNBQ@xh8XZX%<u1CTWMR>|Q75Q-VjND>ulSg@_&y*95g(;{K
znYx3VYzXiYJx$@;d$o8X3qJqlCvZA=6Z=cJTbNfw5c28!rt}-S^usHds;jwag@fn!
zS8qfuunGdNq*dwi%%<rm`)D7`ZQjV}p*eitQyKU7m+ezpO!oV6y>Cu*yRWo>jXdr3
z6wX<(v4{SC3u6eoBJPRHuJ1n~-?w~;6YU70RtZ?l`BxOJe3O$y<L@@*EOt2|nJBV)
zfUb#Gd^$1LmP{*L&3+x))b?@9<J$6el!VHmD5<jYKvqYXVhkqC6DdEi-lUDO3(+Wv
zysbq^*0ZSCE%sTX^|tid<ah2SO>QO4`c1`0C!9^A-bc4mTX$Bn+nyvFuTzbuMG0ln
zofVa_Xv*eWh7K>8D@Y+OxtymFACsb;Z<zmGDU+1EV@QgMDUI$>z_6s6KQMpGh*P2x
z%27#^OUM6a+4}cayIYGz&CXG&j&VP#_wMmIm3ncr?ixZkebb*h_{C1Gzo+d7PKBqZ
zXf?m=%uh@WYm=xCsjJ<8_qDSs*Wf{%&aMs(OYt`2mKrRmy(MQgoz`BBwidoe8+g%>
zkobcw40dFRR|4*|w|g382N~&qdC(MYDm!Y_IGz_ih))>Lb!k=_X1FK){^C8N1mI*<
zI91De^gMY2+U__m!<w|n|H=;R^b0F;_eB{RDW%8X8tu~MH^dlwwr3P&IE7SadfZK<
zluYB#KP`)?6rB5BK_Be<V`0qbm|;XcIsEe@mc?7i+m@1Q@!3n6mimLMn)DB}wZhkF
z?CCk#*}&Q`qbb8hw8X0W$m86h+N)Rpd`>^N<Dfs{NHR?zwsw44sTF9+i*3!martnz
z;^>#D&%cs&@7FU#JcGj8ZA-P)4464)EJ}Fs_D)k8g}UC>EMq;kV-$Q|gjM}DwV=5%
z_}I5Yp9^KKqfTxT?ZP>6k}Q7dUuITBA*)ICD8-dd`I_;E%+O~Mby*TAGD*r4w6g~S
zyexy8`t_fa%a#N#nxE>vw>QeLQ@PFre#!G>iugOlHc^LvgCdJg(<9gojkul{_bC+8
z69>F(>mSLu)wQ-0PS<?<onE#j+{Fc_$SwfBx=-c&b+<bLq$97^G`Pli=B_8pB8Jpi
zexE+1dB$g0Y|%t;idVb;@Q9Lv%z@S6Caz{T2wLNKuRiisi2WQ?nk7CKq+eIDvCy~q
z6`k1HRCDBH2Hk%`K4*Myu93VLnPN4C#S*;PS>JH8KcypkB@5ncRZU=}KH96_q#HEM
zxBm3rCok9UqU83-QUf&xGM<>MR`)V4C58qdSe8{266V7V(zoQctO_q`ni7>qgY|c;
zruth3kkWtR1%_Q7n&w~us~__9)|NEra+0;p|EDD5x~h#dgPA>b>D4-#;)Gq>2)Om;
zC2i5-Qs|itym7H^$-c$DtN9JvzN+O$Twg0&`nQv2$@&Auk>uq*xAD!f@qcim;RdFh
zLfeAS+><K!IQJf5?d=N<HM@@Ka>ZdA*u*!ZgK}+DCT0ksb@vC2=f<9yy(gNkYH3K)
zOziCCA8z3FEF;fH4z4*<GzffNE?M|!j(WY9r%R>R)XPK68OCKk!$nlyoMV??=#U*P
zd1l{D@BH-~wiLU_;hu2WOsS4@L5+XRsR#3Vt1mefM%%CO+Doafhws1rdP-CkQ&T<|
zc5i-n?*k?xbdKrk^XwQwPSfH68UVRT0Hn+SP`UzutS(#>4m8E#SF{O5J^%{-P@e-p
zSrhKn0g${7z@AX3O8^k1z&}d{o-4xzJ!!~`F#%9K0_`dQkj?;z%){^@s0{&-2!y$Z
zAR_`96!f3Lxp<iO9J0}n#R5PPAApBh@UjS4;2VT+0HAyUkS9Q04*gLG>%$>fQgIBn
zhYS+>NDat!0U(?M**mb<M_95O&SRkO0WX5(glYf~KM1ufe25Utqd_JFW;MW>$FQ8#
tIo)0Ce0{H4d`WoglAGiPUdBsD(Nnqf$%y01fxIk6k#j3%Ow8X>?tj#hbMOEF
delta 1424
zcmXAodpOg39LK-zhS}CORBqiywTvYvt=owdD#N2mgzBt@5IKe;vS>-U{M=6D3@eXI
zwN+-U$n|h4?YM<bxg?b9L8d%7UpxPPp6C1ezTfZ9=grgQ67$uSEdjtNDOOS2&*wP<
z#X22l#6LK^By6P^01bB(lW#e;PSHzLL5MFsS6EYh-&h0yQGl2$6OI9ZKBloRJmlyt
ze{7J*6yMO*Ws-V3^%|UaVwI)u%1Ddz=JW!~7IC7T8e?rc0NP}1uY1NtV?1EdM|xcy
zgI!z%v|#|0)+4e111pF>z6?7n@9SSOnEb{qIZ)#f`EwHh*c_ej;~>xNV#BVv(5gKK
zGHOTeXgvgSjNWxdEc$&~PT%n|m&~@bksg~d1VHB`B9#NNuB0%%<Zc$b^ZD@*9P8Ew
zy+^cpcK}e;WJ_dMg)B>rEZf>JD?t&)MIT!LSi>jR&k;TD^m-mx-|W?&ouuH_{8}FZ
z-y+5;tCm&xhlWNPKdTMk$0Te8p}))9gs9&J003I{)a}CPJ+D*kz9(f#+0Il`$?Qw0
zkY?Yw;CwJJR#~hg*2M(rebOEcuY~h7Bv=mAtZ=WkJ0)S@(kBj|l{)UaN7@kN5(t25
z?Wtft+>61=n|DpPyQhqcuO{EfXaj%{?!BetTj&TcofUDT*hIXupNqG<0{?GCUdn;E
zgtJ1=d%exBQxfnkb<^B+!D-d*r%<`(`LiS4iZ+?T<G(r&j^hR;(~&9-(3(a7r&!9%
z9sYY`n#GCso`HF7>tz81x*}NBRm<vkE>+fz$=p&VzlW;pT7_!l<+FJ3q2lR4LYQ$N
z1BYpytK4L46JVGfQn(Q+-x?EVYF)6L<ujY`O7iMJTI2Gyk20v-0r8OoiLyBJIgWY1
zidUXyV?j~4-uwq-vlwQQA19PvXMUl3Con76SDfxzUM|vt=d@-aZqbY#8kTdV0c*_D
zsQQ}wQ(`0$09+{|kOP$+IUI+`rIK}Pd``w+n17g}sC0AwJOFC5oVID3^>140mdLtd
zQvz*x(y2NYDyfeTtW$p!@UU#lgLh7Ah1;J*ZeHFD&#Wj-ZPl^1K|*U&d35X&UkNOt
znGwI-udioN;NhRU?MK-*{iHI8iteI_dQyYh?4x@Cz-K4ZtB4(l>$Sa2gNoUJjMfzt
zPr_owA#^zq-IVF-i#MYXZ~pd2*PkZU<zeQG`b6jeotfwuP;$%dL2P!vz4wc}up;T1
zA8_tlz-@cIf25mo)GYW>RM5mTp7jS5OkzL6lLLtue*b6m5UVVZ(q}fRr#|D_S&<AI
zrfE=i^{Q<x_srsvZJiEmYBaN^VSEY#yUU~-F{-km_w=u)3l2^9O>B)ac?{=n$g~`Y
zU#`3n!<nnA(%RR(Nb&bp=9T;#pAM_}v`XZEbiryOL+f|^iFu|?kRTGpgVz44&N;l3
z##Eqv)DI<0HDXG8p5|VHJs3j{s;_3Kvr-$C_eDxK8h`ksUZlm37dm-WXTuB`wQ(_O
z1B5!2Bmek?WV&;M`Q;)q%rL2?>2VDE`4M|`&Hgy@%xv9p#}r?<iwYz~4pb<W;vB?f
zRR2=*PY)P8>o9g>{$nm&vPZj-hfjy<sD<>TxNOVrP9j!o#|#A8c2o+Dnt|V}z;ouA
zFE)I_FDFS2R-c6Q%Yo?9Ud)}Ib;%TrY80)HMDp_FCoMoFI)y_knjx=H>F;I5y(En>
zJN<jy?d351@!^^kPXmnh8#>YD*&aiDH%NSL0i&2i%u$4cun_t(TE+z<DpRM+f7>Fh
z?~SAtr)g`O&$8&1U0h1vT~cU;GC=Re9<sOUyT0Rzlyn)1V7VEdU<8k4y$JXZTkul8
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-df2982f284bbabb6bdb59ee3fcc6eb0983e20371.pack b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-df2982f284bbabb6bdb59ee3fcc6eb0983e20371.pack
index bb47c90d93b0b2276fc36b96bc8734085bde6007..ef56d7e941828561e9f6e2cbc46e2d6c9c8d76bf 100644
GIT binary patch
delta 55
zcmV-70LcHuE{!g*s{sV$1%N=4!2w$X;R0W?G6I+l180Cov)>O<2NYiZCg!fo8+@2=
Nzv)s5^+^m_Both>71IC!
delta 110
zcmV-!0FnQVF2pXds{t1D1;B8vj0l7bffm|^TP<Z-I%~PjDwD4PTNd#G&=E?wtTJn>
zFyp3IpgDDT#i6f=vkd~64Hb6+x-!#bo>2e-!WL1JYjAg}b^oces1H#G6hxtEG1~WN
Q{ggPWqc#a04LlG+NkNq^UjP6A
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/packed-refs b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/packed-refs
index 746bd6b..fd735fe 100644
--- a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/packed-refs
+++ b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/packed-refs
@@ -4,8 +4,10 @@
6e1475206e57110fcef4b92320436c1e9872a322 refs/heads/c
f73b95671f326616d66b2afb3bdfcdbbce110b44 refs/heads/d
d0114ab8ac326bab30e3a657a0397578c5a1af88 refs/heads/e
-d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864 refs/heads/pa
+47d3697c3747e8184e0dc479ccbd01e359023577 refs/heads/f
+175d5b80bd9768884d8fced02e9bd33488174396 refs/heads/g
49322bb17d3acc9146f98c97d078513228bbf3c0 refs/heads/master
+d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864 refs/heads/pa
6db9c2ebf75590eef973081736730a9ea169a0c4 refs/tags/A
17768080a2318cd89bba4c8b87834401e2095703 refs/tags/B
^d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864
@@ -27,5 +29,3 @@ bf5123bb77c7b5a379f7de9c1293558e3e24dfb8 refs/tags/B8th
^d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864
dd144af286452bfd6a1ea02b0d3745bcdb555e9d refs/tags/B9th
^d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864
-8bbde7aacf771a9afb6992434f1ae413e010c6d8 refs/tags/spearce-gpg-pub
-^fd608fbe625a2b456d9f15c2b1dc41f252057dd7
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
index 9e48fde..20348f1 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
@@ -236,7 +236,8 @@ public void run() {
"pack-df2982f284bbabb6bdb59ee3fcc6eb0983e20371",
"pack-9fb5b411fe6dfa89cc2e6b89d2bd8e5de02b5745",
"pack-546ff360fe3488adb20860ce3436a2d6373d2796",
- "pack-e6d07037cbcf13376308a0a995d1fa48f8f76aaa"
+ "pack-e6d07037cbcf13376308a0a995d1fa48f8f76aaa",
+ "pack-3280af9c07ee18a87705ef50b0cc4cd20266cf12"
};
final File packDir = new File(db.getObjectsDirectory(), "pack");
for (int k = 0; k < packs.length; k++) {
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/merge/SimpleMergeTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/merge/SimpleMergeTest.java
new file mode 100644
index 0000000..96064f5
--- /dev/null
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/merge/SimpleMergeTest.java
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2008, Robin Rosenberg
+ *
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials provided
+ * with the distribution.
+ *
+ * - Neither the name of the Git Development Community nor the
+ * names of its contributors may be used to endorse or promote
+ * products derived from this software without specific prior
+ * written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+package org.spearce.jgit.merge;
+
+import java.io.IOException;
+
+import org.spearce.jgit.lib.ObjectId;
+import org.spearce.jgit.lib.RepositoryTestCase;
+
+public class SimpleMergeTest extends RepositoryTestCase {
+
+ public void testOurs() throws IOException {
+ Merger ourMerger = MergeStrategy.OURS.newMerger(db);
+ boolean merge = ourMerger.merge(new ObjectId[] { db.resolve("a"), db.resolve("c") });
+ assertTrue(merge);
+ assertEquals(db.mapTree("a").getId(), ourMerger.getResultTreeId());
+ }
+
+ public void testTheirs() throws IOException {
+ Merger ourMerger = MergeStrategy.THEIRS.newMerger(db);
+ boolean merge = ourMerger.merge(new ObjectId[] { db.resolve("a"), db.resolve("c") });
+ assertTrue(merge);
+ assertEquals(db.mapTree("c").getId(), ourMerger.getResultTreeId());
+ }
+
+ public void testTrivialTwoWay() throws IOException {
+ Merger ourMerger = MergeStrategy.SIMPLE_TWO_WAY_IN_CORE.newMerger(db);
+ boolean merge = ourMerger.merge(new ObjectId[] { db.resolve("a"), db.resolve("c") });
+ assertTrue(merge);
+ assertEquals("02ba32d3649e510002c21651936b7077aa75ffa9",ourMerger.getResultTreeId().name());
+ }
+
+ public void testTrivialTwoWay_disjointhistories() throws IOException {
+ Merger ourMerger = MergeStrategy.SIMPLE_TWO_WAY_IN_CORE.newMerger(db);
+ boolean merge = ourMerger.merge(new ObjectId[] { db.resolve("a"), db.resolve("c~4") });
+ assertTrue(merge);
+ assertEquals("86265c33b19b2be71bdd7b8cb95823f2743d03a8",ourMerger.getResultTreeId().name());
+ }
+
+ public void testTrivialTwoWay_ok() throws IOException {
+ Merger ourMerger = MergeStrategy.SIMPLE_TWO_WAY_IN_CORE.newMerger(db);
+ boolean merge = ourMerger.merge(new ObjectId[] { db.resolve("a^0^0^0"), db.resolve("a^0^0^1") });
+ assertTrue(merge);
+ assertEquals(db.mapTree("a^0^0").getId(), ourMerger.getResultTreeId());
+ }
+
+ public void testTrivialTwoWay_conflict() throws IOException {
+ Merger ourMerger = MergeStrategy.SIMPLE_TWO_WAY_IN_CORE.newMerger(db);
+ boolean merge = ourMerger.merge(new ObjectId[] { db.resolve("f"), db.resolve("g") });
+ assertFalse(merge);
+ }
+}
--
1.6.1.rc3.56.gd0306
^ permalink raw reply related
* Re: An idea: maybe Git should use a lock/unlock file mode for problematic files? [Was: Re: after first git clone of linux kernel repository there are changed files in working dir]
From: Alex Riesen @ 2009-01-20 23:25 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: John Chapman, Hannu Koivisto, rdkrsr, git
In-Reply-To: <alpine.LNX.1.00.0901201651050.19665@iabervon.org>
2009/1/20 Daniel Barkalow <barkalow@iabervon.org>:
> My impression was that this didn't happen in practice, because teams
> would tend to not have two people create the same file at the same time,
> but with different cases, and people interacting with the same file at
> different times would use whatever case it was introduced with.
It will and does happen in practice (annoingly too often even). Not with Git
yet (with Perforce), where people do "branching" by simply copying things
in another directory (perforce world does not know real branches),
renaming files randomly, and putting the new directory back in the
system (or maybe it is the strange tools here which do that - often
it is the first character of a directory or file which gets down- or up-cased).
As Perforce itself is case sensitive (like Git), using of such branches
is a nightmare: the files get overwritten in checkout order which is
not always sorted in predictable order. Combined with case-stupidity
of the file system the working directories sometimes cause "interesting
time" for unlucky users.
Luckily (sadly) it is all-opening-in-a-wall shop, so the problem with "fanthom"
files is rare (it is hard to notice) for most. Which actually makes it more
frustrating when the real shit happens.
And it will happen to Git as well, especially if development go crossplatform.
It is not that hard to accidentally rename a file on case-sensitive file system,
"git add *" it and commit without thinking (that's how most of software
development happens, come to think of it).
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Jeff King @ 2009-01-20 23:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901201545570.5159@intel-tinevez-2-302>
On Tue, Jan 20, 2009 at 03:50:28PM +0100, Johannes Schindelin wrote:
> > How will you deal with race conditions between two simultaneously
> > running scripts? I.e., where are you going to put it?
>
> There are no race conditions, as for every git executable, a symbolic link
> is created, pointing to the valgrind.sh script [*1*].
Hmm. I suppose that would work, since every test run is trying to create
the same state.
> Besides, what with valgrind being a memory hog, you'd be nuts to call
> valgrinded scripts simultaneously.
I have to disagree there. I think there are two obvious usage patterns:
- run script $X specifically under valgrind to track down a bug
- run the whole test suite under valgrind occasionally to find
latent bugs that wouldn't otherwise show up
In the latter, you want a pretty beefy box. When I did the original
patches, I ran through the whole test suite under valgrind. It took
several hours on a 6GB quad-core box, using "-j4". I would hate for it
to have taken an entire day. :)
-Peff
^ permalink raw reply
* Re: Git rebase -i failing on cygwin -- git checkout-index says File Exists
From: Johannes Schindelin @ 2009-01-20 23:23 UTC (permalink / raw)
To: Ludvig Strigeus; +Cc: git
In-Reply-To: <4285cd450901201444g711626afm296bf372a100b999@mail.gmail.com>
Hi,
On Tue, 20 Jan 2009, Ludvig Strigeus wrote:
> On Tue, Jan 20, 2009 at 11:20 PM, Ludvig Strigeus <strigeus@gmail.com> wrote:
> >
> > Maybe this command log is useful. I got this while aborting the
> > rebase. Looks like some file creation race condition? Windows doesn't
> > allow files to be deleted while they're open.
>
> I believe I found the source of my problems with git rebase. I had an
> editor open that wanted to reload the files when changed, and this
> seemed to conflict with git's file manipulations. After closing the
> editor, I don't get the mysterious errors anymore.
Yep, that's a Windows issue. Once you keep a file open in an editor, it
cannot be overwritten/deleted.
Live with it, or upgrade to a real operating system :-)
Ciao,
Dscho
^ permalink raw reply
* Re: Git rebase -i failing on cygwin -- git checkout-index says File Exists
From: Ludvig Strigeus @ 2009-01-20 22:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <4285cd450901201420l8929dci25688dc9723c917a@mail.gmail.com>
On Tue, Jan 20, 2009 at 11:20 PM, Ludvig Strigeus <strigeus@gmail.com> wrote:
>
> Maybe this command log is useful. I got this while aborting the
> rebase. Looks like some file creation race condition? Windows doesn't
> allow files to be deleted while they're open.
I believe I found the source of my problems with git rebase. I had an
editor open that wanted to reload the files when changed, and this
seemed to conflict with git's file manipulations. After closing the
editor, I don't get the mysterious errors anymore.
/Ludde
^ permalink raw reply
* Re: An idea: maybe Git should use a lock/unlock file mode for problematic files? [Was: Re: after first git clone of linux kernel repository there are changed files in working dir]
From: John Chapman @ 2009-01-20 21:28 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Hannu Koivisto, rdkrsr, git
In-Reply-To: <alpine.LNX.1.00.0901201441480.19665@iabervon.org>
On Tue, 2009-01-20 at 15:11 -0500, Daniel Barkalow wrote:
<snip>
>
> The hard part is actually identifying what the user's filesystem has done.
> There's pretty good internal support for git knowing that, for a
> particular entry, the filesystem should not be consulted for information.
> I don't think anyone's come up with a suitably cross-platform and
> automatic way to figure out what's happened when git tries to write to a
> particular filename and the system decides it is the same as some other
> filename or it decides to use a different filename instead.
This would only need to interact with the git status command, wouldn't
it?
>
> Of course, it is reasonably likely that a project whose files can't all be
> checked out can't be dealt with anyway on that platform (IIRC, the Linux
> kernel build system assumes that it can create both .S and .s files, so it
> won't build on FAT). So nobody's been sufficiently motivated to try to
> implement a fix.
I doubt the kernel builds on windows, but this would allow a windows
user to modify such files, perhaps in preparation for a patch that does
allow the kernel to be built on windows?
(Of course, we're using the kernel here as an example, right? Nobody
would be insane as to want to use windows for that!)
See, a very annoying thing about windows is that it is quite simple for
a team to commit two files that differ by case alone to a git
repository.
Was just an idea, really.
^ permalink raw reply
* Re: [PATCH] Rename detection: Avoid repeated filespec population
From: Jeff King @ 2009-01-20 21:27 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <20090120155957.GA23237@atjola.homenet>
On Tue, Jan 20, 2009 at 04:59:57PM +0100, Björn Steinbrink wrote:
> In diffcore_rename, we assume that the blob contents in the filespec
> aren't required anymore after estimate_similarity has been called and thus
> we free it. But estimate_similarity might return early when the file sizes
> differ too much. In that case, cnt_data is never set and the next call to
> estimate_similarity will populate the filespec again, eventually rereading
> the same blob over and over again.
>
> To fix that, we first get the blob sizes and only when the blob contents
> are actually required, and when cnt_data will be set, the full filespec is
> populated, once.
I think this is a sane thing to do, and obviously your numbers show an
impressive improvement.
However, I found your explanation a little confusing. Yes, repeatedly
loading those blobs is a problem. But what this is really about is that
estimate_similarity has two levels of checks: cheap checks involving the
size, and expensive checks involving the content. What is happening now
is that we are doing extra work for the expensive checks, even if the
cheap checks are going to let us fail early.
And that's just stupid, and a waste of processing time even if we
_don't_ ever look at the same filespec again.
But what makes it even worse is that we have a system in place to cache
the expensive work, but because we only do part of it, we don't bother
to cache the result. And that's what your patch description is about.
So I think your patch is absolutely the right thing to do. But I think
from the commit message it isn't clear that it would not be equally
correct to follow through on generating cnt_data instead of an early
return (which _isn't_ right, because you might not need to generate
cnt_data at all).
> This actually affects the copy detection way more than the pure
> rename detection, due to the larger number of candidates, but it's the
> same code, and I only realized that when I reran the stuff to get some
> numbers to show off. ;-)
I have a pathological real-world rename test case from a long time ago.
It's so awful on rename because almost the whole repo was reorganized,
but almost every path got its content adjusted, too. I was hoping it
would be better with your patch, but it isn't: as it turns out, it is
_too_ uniform. The cheap size checks don't work because all of the files
are almost the same size (they're all jpgs from a camera).
But I think for non-pathological cases, your improvement makes sense.
-Peff
^ permalink raw reply
* Re: Newbie Query
From: Boyd Stephen Smith Jr. @ 2009-01-20 22:24 UTC (permalink / raw)
To: devel; +Cc: git
In-Reply-To: <49764647.1080606@morey-chaisemartin.com>
[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]
On Tuesday 2009 January 20 15:46:47 Nicolas Morey-Chaisemartin wrote:
>Boyd Stephen Smith Jr. a écrit :
>> On Tuesday 2009 January 20 15:07:55 Nicolas Morey-Chaisemartin wrote:
>>> I did the rookie mistkae on the central server to create the main
>>> reposity in non-bare mode.
>>> Is there a cleaner way to convert a non-bare git repo into a bare repo
>>> than cloning it?
No.
>>> My repo have a lot of remote branch registered, and cloning them to a
>>> new bare repo mean I'll have to add all those remote branches again
>>> (except if there is another trick here I don't know about).
>>
>> Well, if you can make sure no one is pushing into the repo for a bit:
>> clone it and replace the original with a symlink to new, bare one. Your
>> clients will be able to use the same URL, so they should be happy. (I
>> haven't tried this, but it should work.)
>
>Well I know there are solutions to convert it to a bare repo.
>I was just wondering if there was a "clean" one which really converts
>the repo to a bare one and not create a copy which is bare.
The clone *is* a way to convert, with the added advantage of not trashing the
original during the conversion, by putting the results in a different
location. In fact, it's probably *cleaner* than any convert-in-place.
>I don't know how bare/non-bare is managed but I guess both types of repo
>are not differing by much, so it'd be great to have a function to
>convert from one to another.
I couldn't tell you all the differences, but I don't think there are many
either.
--
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
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