* Re: [PATCH] test-lib: write test results to test-results/<basename>-<pid>
From: SZEDER Gábor @ 2009-03-13 17:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster, Sverre Rabbelier
In-Reply-To: <20090313172002.GA16232@neumann>
On Fri, Mar 13, 2009 at 06:20:02PM +0100, SZEDER Gábor wrote:
> Hi,
>
>
> On Fri, Mar 13, 2009 at 05:36:13PM +0100, Johannes Schindelin wrote:
> > On Fri, 13 Mar 2009, Johannes Schindelin wrote:
> >
> > > The earlier code meant to attempt to strip everything except the test
> > > number, but only stripped the part starting with the last dash.
> > >
> > > However, there is no reason why we should not use the whole basename.
>
> I agree.
>
> > >
> > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > > ---
> > >
> > > Even if this is not strictly necessary after Hannes' test cleanup,
> > > it would still be nice.
> >
> > Just to clarify: it fixes the issue that these two tests share the same
> > file in test-results/: t5521-pull-options.sh t5521-pull-symlink.sh
> >
> > As a consequence, one's results overwrite the other one's.
>
> The pid of the test process makes the name of the test result file
> unique for each test, even in the mentioned case, e.g. it would be
> something like t5521-pull-12345 and t5521-pull-23456.
Correction: those files are not always unique, because although
unlikely, it's possible that these two tests get the same pid.
But with Hannes' patch this issue goes away, and the rest of my
previous mail still holds.
Best,
Gábor
^ permalink raw reply
* Re: [PATCH] test-lib: write test results to test-results/<basename>-<pid>
From: Junio C Hamano @ 2009-03-13 17:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Sverre Rabbelier
In-Reply-To: <7viqmdgx0b.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> ...
>> As a consequence, one's results overwrite the other one's.
>
> Are you saying that your "fix" will break things if we did not have
> renames from j6t?
Please disregard; I shouldn't be writing an e-mail when I do not have time
to re-read and think. Sorry for the noise.
^ permalink raw reply
* Re: [PATCH] test-lib: write test results to test-results/<basename>-<pid>
From: Junio C Hamano @ 2009-03-13 17:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Sverre Rabbelier
In-Reply-To: <alpine.DEB.1.00.0903131735110.6288@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 13 Mar 2009, Johannes Schindelin wrote:
>
>> The earlier code meant to attempt to strip everything except the test
>> number, but only stripped the part starting with the last dash.
>>
>> However, there is no reason why we should not use the whole basename.
>>
>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>> ---
>>
>> Even if this is not strictly necessary after Hannes' test cleanup,
>> it would still be nice.
>
> Just to clarify: it fixes the issue that these two tests share the same
> file in test-results/: t5521-pull-options.sh t5521-pull-symlink.sh
>
> As a consequence, one's results overwrite the other one's.
Are you saying that your "fix" will break things if we did not have
renames from j6t?
What bug/problem/issue does this patch fix?
I never look into test-results/ subdirectory myself (I'll let the
summarizing code do that for me) and the full names never bothered me.
Actually I've always thought it was a very nice touch by you to make sure
results will not be mixed up even when we have more than 10 tests in the
same category and some tests need to share their numbers, and and your
"meant to ... strip everything" above gave me "Huh?"
^ permalink raw reply
* Re: [PATCH] test-lib: write test results to test-results/<basename>-<pid>
From: SZEDER Gábor @ 2009-03-13 17:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster, Sverre Rabbelier
In-Reply-To: <alpine.DEB.1.00.0903131735110.6288@intel-tinevez-2-302>
Hi,
On Fri, Mar 13, 2009 at 05:36:13PM +0100, Johannes Schindelin wrote:
> On Fri, 13 Mar 2009, Johannes Schindelin wrote:
>
> > The earlier code meant to attempt to strip everything except the test
> > number, but only stripped the part starting with the last dash.
> >
> > However, there is no reason why we should not use the whole basename.
I agree.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >
> > Even if this is not strictly necessary after Hannes' test cleanup,
> > it would still be nice.
>
> Just to clarify: it fixes the issue that these two tests share the same
> file in test-results/: t5521-pull-options.sh t5521-pull-symlink.sh
>
> As a consequence, one's results overwrite the other one's.
The pid of the test process makes the name of the test result file
unique for each test, even in the mentioned case, e.g. it would be
something like t5521-pull-12345 and t5521-pull-23456. However, after
Hannes' patch there is no need for keeping that pid around because the
test result file names would be unique for each test anyway.
Moreover, if we would remove the pif from the test result file name,
we could also remove the 'pre-clean' target from 't/Makefile'. With
the pid appended, we need that 'pre-clean' target to clean up all
leftovers from the previous run. Without the pid each test will
always write to the same test result file, so we could actually just
overwrite the cruft from the last run.
Something like the patch below. Thoughts?
Best,
Gábor
---
t/Makefile | 7 ++-----
t/test-lib.sh | 4 ++--
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/t/Makefile b/t/Makefile
index 0d65ced..2e6e205 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -14,14 +14,11 @@ SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
T = $(wildcard t[0-9][0-9][0-9][0-9]-*.sh)
TSVN = $(wildcard t91[0-9][0-9]-*.sh)
-all: pre-clean $(T) aggregate-results clean
+all: $(T) aggregate-results clean
$(T):
@echo "*** $@ ***"; GIT_CONFIG=.git/config '$(SHELL_PATH_SQ)' $@ $(GIT_TEST_OPTS)
-pre-clean:
- $(RM) -r test-results
-
clean:
$(RM) -r 'trash directory' test-results
@@ -33,5 +30,5 @@ full-svn-test:
$(MAKE) $(TSVN) GIT_SVN_NO_OPTIMIZE_COMMITS=1 LC_ALL=C
$(MAKE) $(TSVN) GIT_SVN_NO_OPTIMIZE_COMMITS=0 LC_ALL=en_US.UTF-8
-.PHONY: pre-clean $(T) aggregate-results clean
+.PHONY: $(T) aggregate-results clean
.NOTPARALLEL:
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 0bd24d5..d82c784 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -418,9 +418,9 @@ test_done () {
trap - exit
test_results_dir="$TEST_DIRECTORY/test-results"
mkdir -p "$test_results_dir"
- test_results_path="$test_results_dir/${0%.sh}-$$"
+ test_results_path="$test_results_dir/${0%.sh}"
- echo "total $test_count" >> $test_results_path
+ echo "total $test_count" > $test_results_path
echo "success $test_success" >> $test_results_path
echo "fixed $test_fixed" >> $test_results_path
echo "broken $test_broken" >> $test_results_path
^ permalink raw reply related
* Re: Transparently encrypt repository contents with GPG
From: Jeff King @ 2009-03-13 17:13 UTC (permalink / raw)
To: Michael J Gruber
Cc: Sverre Rabbelier, Thomas Rast, Michael J Gruber,
Matthias Nothhaft, git
In-Reply-To: <49BA6606.1070403@fastmail.fm>
On Fri, Mar 13, 2009 at 02:56:22PM +0100, Michael J Gruber wrote:
> Sverre was being prophetic with the somehow. Here's a working setup
> (though I still don't know why not to use luks):
>
> In .gitattributes (or.git/info/a..) use
>
> * filter=gpg diff=gpg
>
> In your config:
>
> [filter "gpg"]
> smudge = gpg -d -q --batch --no-tty
> clean = gpg -ea -q --batch --no-tty -r C920A124
> [diff "gpg"]
> textconv = decrypt
>
> This gives you textual diffs even in log! You want use gpg-agent here.
This is not going to work very well in general. Smudging and cleaning
is about putting the canonical version of a file in the git repo, and
munging it for the working tree. Trying to go backwards is going to lead
to problems, including:
1. Git sometimes wants to look at content of special files inside
trees, like .gitignore. Now it can't.
2. Git uses timestamps and inodes to decide whether files need to be
looked at all to determine if they are different. So when you do
a checkout and "git diff", everything will look OK. But when it
does actually look at file contents, it compares canonical
versions. And your canonical versions are going to be _different_
everytime you encrypt, even if the content is the same:
echo content >file
git add file
git diff ;# no output
touch file
git diff ;# looks like file is totally rewritten
So you will probably end up with extra cruft in your commits if you
ever touch files.
> Now for Sverre's prophecy and the helper I haven't shown you yet: It
> turns out that blobs are not smudged before they are fed to textconv!
> [Also, it seems that the textconv config does allow parameters, bit I
> haven't checked thoroughly.]
I don't think they should be smudged. Smudging is about converting for
the working tree, and the diff is operating on canonical formats. If
anything, I think the error is that we feed smudged data from the
working tree to textconv; we should always be handing it clean data (and
this goes for external diff, too, which I suspect behaves the same way).
I haven't looked, but it probably is a result of the optimization to
reuse worktree files.
-Peff
PS If it isn't obvious, I don't think this smudge/filter technique is
the right way to go about this. But one final comment if you did want to
pursue this: you are using asymmetric encryption in your GPG invocation,
which is going to be a lot slower and the result will take up more
space. Try using a symmetric cipher.
^ permalink raw reply
* Re: git doc build failure on OS X 10.5.6 (Leopard) during xmlto phase
From: Michael J Gruber @ 2009-03-13 17:06 UTC (permalink / raw)
To: Jay Soffian; +Cc: Todd Zullinger, Alejandro Riveira, git, Tom Holaday
In-Reply-To: <76718490903130918r733e3ef4meae49311883969b5@mail.gmail.com>
Jay Soffian venit, vidit, dixit 13.03.2009 17:18:
> On Fri, Mar 13, 2009 at 6:29 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> On a related issue: Does anybody know which asciidoc versions need
>> asciidoc7compatible to be set? 8.2.5 and above certainly don't, so we
>> should not advise using it. asciidoc's hg repo doesn't go back much more
>> (the initial revision does not need it either), and I haven't dug for
>> their earlier history yet.
>
> I'm using 8.3.1 and set asciidoc7compatible. I don't recall why I set
> it, but I'm sure I had a good reason for it. :-)
And you don't have any issues with _emphasis_? E.g. in git help
filter-branch, "positive" in the second paragraph should be emphasized,
possibly underlined.
OK, I just checked myself. At least 8.2.7 still had problems, but 8.3.0
is fine, even 8.4.1 is. asciidoc needs to be convinced forcibly to look
for its config in its own location (rather than /etc), which is what
tripped off my first tests...
So, asciidoc version 8.3.0 and above is fine with asciidoc7compatible
(at least regarding emphasis), 8.2.4~23 through 8.2.7 is not. Below
their hg history ends.
Oh well, the doc tool chain. Dig into it and feel chained to a stool, in
need to see a doc. Lame pun, time to go home :|
Michael
^ permalink raw reply
* Re: Not pushing all branches?
From: Jeff King @ 2009-03-13 16:49 UTC (permalink / raw)
To: Peter Krefting; +Cc: git
In-Reply-To: <alpine.DEB.2.00.0903130846410.17450@perkele.intern.softwolves.pp.se>
On Fri, Mar 13, 2009 at 08:48:55AM +0100, Peter Krefting wrote:
> Doing "git push remote" pushes all my local branches by default. Is there
> a way to set it to *not* do that, and (for this particular remote
> repository) just push the current branch? Or failing that, not allow me to
> run "git push" without specifying a branch?
>
> The git-config manual page leads me to believe that I should recofigure
> "remote.<name>.push", but it points me to the "refspec" spec on git-push,
> which is a tad cryptic.
There seem to be a lot of responses in this thread, but nobody has
suggested:
git config remote.$remote.push HEAD
It isn't mentioned in the git-push manpage; maybe a documentation patch
to give an example using HEAD would make sense?
-Peff
^ permalink raw reply
* Re: [PATCH] test-lib: write test results to test-results/<basename>-<pid>
From: Johannes Schindelin @ 2009-03-13 16:36 UTC (permalink / raw)
To: git, gitster; +Cc: Sverre Rabbelier
In-Reply-To: <3728317206182c4d4539f3d20b8441cb160e72e3.1236961524u.git.johannes.schindelin@gmx.de>
Hi,
On Fri, 13 Mar 2009, Johannes Schindelin wrote:
> The earlier code meant to attempt to strip everything except the test
> number, but only stripped the part starting with the last dash.
>
> However, there is no reason why we should not use the whole basename.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> Even if this is not strictly necessary after Hannes' test cleanup,
> it would still be nice.
Just to clarify: it fixes the issue that these two tests share the same
file in test-results/: t5521-pull-options.sh t5521-pull-symlink.sh
As a consequence, one's results overwrite the other one's.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] test-lib: write test results to test-results/<basename>-<pid>
From: Johannes Schindelin @ 2009-03-13 16:26 UTC (permalink / raw)
To: git, gitster; +Cc: Sverre Rabbelier
In-Reply-To: <cover.1236961524u.git.johannes.schindelin@gmx.de>
The earlier code meant to attempt to strip everything except the test
number, but only stripped the part starting with the last dash.
However, there is no reason why we should not use the whole basename.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Even if this is not strictly necessary after Hannes' test cleanup,
it would still be nice.
The alternative fix would be to use two percent signs instead of
just one.
t/test-lib.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 75b5a89..ccb5d0a 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -477,7 +477,7 @@ test_done () {
trap - EXIT
test_results_dir="$TEST_DIRECTORY/test-results"
mkdir -p "$test_results_dir"
- test_results_path="$test_results_dir/${0%-*}-$$"
+ test_results_path="$test_results_dir/${0%.sh}-$$"
echo "total $test_count" >> $test_results_path
echo "success $test_success" >> $test_results_path
--
1.6.2.240.g23c7
^ permalink raw reply related
* RE: newb: Given a commit id, find which branches have it as an ancestor
From: John Dlugosz @ 2009-03-13 16:20 UTC (permalink / raw)
To: git
=== Re: ===
What I'm beginning to suspect is that all the commits that should have
gone to master went to some unnamed branch.
Is that reasonable/possible/likely? This commit has a full ancestry,
but doesn't appear to be on any branch.
=== end===
Both gitk (comes with git) and QGit showthe branches on the GUI when you highlight the commit of interest.
As for recovering lost commits, I've been down that road, and using fsck or worse yet looking at all the files in the objects directory is no fun. The 'reflog' is your friend! Use reflog to spot which one is interesting, and then use something like
git tag here HEAD@{5}
and then bring up gitk with "all branches" and sort it out.
--John
(please excuse the footer; it's not my idea)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: git doc build failure on OS X 10.5.6 (Leopard) during xmlto phase
From: Jay Soffian @ 2009-03-13 16:18 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Todd Zullinger, Alejandro Riveira, git, Tom Holaday
In-Reply-To: <49BA356D.8050007@drmicha.warpmail.net>
On Fri, Mar 13, 2009 at 6:29 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> On a related issue: Does anybody know which asciidoc versions need
> asciidoc7compatible to be set? 8.2.5 and above certainly don't, so we
> should not advise using it. asciidoc's hg repo doesn't go back much more
> (the initial revision does not need it either), and I haven't dug for
> their earlier history yet.
I'm using 8.3.1 and set asciidoc7compatible. I don't recall why I set
it, but I'm sure I had a good reason for it. :-)
j.
^ permalink raw reply
* Re: Not pushing all branches?
From: Johannes Schindelin @ 2009-03-13 16:00 UTC (permalink / raw)
To: John Tapsell; +Cc: Peter Krefting, git
In-Reply-To: <43d8ce650903130656p73e1e149s702f70466bbdb182@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 729 bytes --]
Hi,
On Fri, 13 Mar 2009, John Tapsell wrote:
> 2009/3/13 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Fri, 13 Mar 2009, John Tapsell wrote:
> >
> >> Hopefully the first 5 will be applied and the 6 will debated, then
> >> grudgingly applied :-)
> >
> > No. If it has to be applied grudgingly, it is most likely wrong.
>
> If there's an email about this every week from yet another person that
> has been bitten by the current default, then the current default is most
> likely wrong :-)
I suggest a different tack:
- try to come up with a solution that does not bite anybody,
- continue to modify the proposal until there are no objections left, and
- continue to be liked on the list.
;-)
Ciao,
Dscho
^ permalink raw reply
* Re: Not pushing all branches?
From: Michael J Gruber @ 2009-03-13 15:48 UTC (permalink / raw)
To: John Tapsell; +Cc: Johannes Schindelin, Peter Krefting, git
In-Reply-To: <43d8ce650903130656p73e1e149s702f70466bbdb182@mail.gmail.com>
John Tapsell venit, vidit, dixit 13.03.2009 14:56:
> 2009/3/13 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> Hi,
>>
>> On Fri, 13 Mar 2009, John Tapsell wrote:
>>
>>> Hopefully the first 5 will be applied and the 6 will debated, then
>>> grudgingly applied :-)
>>
>> No. If it has to be applied grudgingly, it is most likely wrong.
>
> If there's an email about this every week from yet another person that
> has been bitten by the current default, then the current default is
> most likely wrong :-)
I think I've used git every day this week, pushed several times, and
still have no bite-marks. Does this count as several votes in the other
direction?
Michael
^ permalink raw reply
* Re: [PATCH JGIT] Allow writeObject() write to OutputStream
From: Daniel Cheng @ 2009-03-13 15:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090313150806.GE22920@spearce.org>
On Fri, Mar 13, 2009 at 11:08 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> "Daniel Cheng (aka SDiZ)" <j16sdiz+freenet@gmail.com> wrote:
>>
>> This patch make factor out the object writing code in ObjectWriter,
>> allow it to write to any OutputStream.
>> Subclass class may then override
>> writeObject(final int type, long len, InputStream is, boolean store)
>> to make it write to alternative locations.
>>
>> There are some discussion on devl@freenetproject.org to use raw
>> (uncompressed) object to freenet. This patch allow the testing.
>
> Ok, I understand the code as-is, but I'm not sure I understand the
> reasoning for the change, or where you are trying to go with it.
In freenet (and most content-addressable network), file can be dropped
out when unused.
We need some method to "heal" the lost data.
The easiest way is to do this is re-insert the very same file we used
originally.
Pack files may change on different compression parameter, object order, etc.
It need some tricks to get the original file.
Loose object are immutable, so it is easier to use loose objects.
Nothing have finalized yet, we are just evaluating different approaches.
I know loose object are always larger, and have very large number of them.
So it may backfire ....
> Are you guys talking about making every object a loose object on
> freenet, and avoiding pack files? Or making a form of JGit that
> access a Repository directly stored on freenode?
>
> I ask because there's some folks starting to talk about putting JGit
> onto a distributed hash table sort of system like Hadoop HBase,
> to allow the underlying storage to scale efficiently for really
> big hosting sites. I would rather see a pooling of effort here
> than folks going in different directions.
>
> --
> Shawn.
>
^ permalink raw reply
* [PATCH 2/2] test-lib.sh: Allow running the test suite against installed git
From: Michael J Gruber @ 2009-03-13 15:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1236959116-3334-2-git-send-email-git@drmicha.warpmail.net>
Introduce variables externalpath and externalexecpath such that the test
suite can be run against a git which is installed at $externalpath with
subcommands at $externalexecpath. externalpath defaults to the git.git
checkout, externalexecpath defaults to $externalpath. Run the suite as
externalpath=somepath externalexecpath=someotherpath make test
but note that this requires and uses parts of a compiled git in the
git.git checkout: test helpers, templates and perl libraries are taken
from there.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
t/test-lib.sh | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index b9da86e..f6c467f 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -514,8 +514,14 @@ test_done () {
TEST_DIRECTORY=$(pwd)
if test -z "$valgrind"
then
- PATH=$TEST_DIRECTORY/..:$PATH
- GIT_EXEC_PATH=$TEST_DIRECTORY/..
+ if test -z "$externalpath"
+ then
+ PATH=$TEST_DIRECTORY/..:$PATH
+ GIT_EXEC_PATH=$TEST_DIRECTORY/..
+ else
+ PATH=$externalpath:$TEST_DIRECTORY/..:$PATH
+ GIT_EXEC_PATH=${externalexecpath:-$externalpath}
+ fi
else
make_symlink () {
test -h "$2" &&
--
1.6.2.149.g6462
^ permalink raw reply related
* [PATCH 1/2] test-lib.sh: Test for presence of git-init in the right path.
From: Michael J Gruber @ 2009-03-13 15:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1236959116-3334-1-git-send-email-git@drmicha.warpmail.net>
It just happens so that when GIT_EXEC_PATH points to a compiled checkout
of git.git it contains "git". Since this is not true in general make
test-lib check for "git-init" which is always in GIT_EXEC_PATH.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
t/test-lib.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 7a847ec..b9da86e 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -454,7 +454,7 @@ test_create_repo () {
repo="$1"
mkdir -p "$repo"
cd "$repo" || error "Cannot setup test environment"
- "$GIT_EXEC_PATH/git" init "--template=$owd/../templates/blt/" >&3 2>&4 ||
+ "$GIT_EXEC_PATH/git-init" "--template=$owd/../templates/blt/" >&3 2>&4 ||
error "cannot run git init -- have you built things yet?"
mv .git/hooks .git/hooks-disabled
cd "$owd"
--
1.6.2.149.g6462
^ permalink raw reply related
* [PATCH 0/2] Allow running the test suite against installed git
From: Michael J Gruber @ 2009-03-13 15:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Part 1 corrects only an inconsistency which does not matter as long as
you run tests against git compiled in a checkout only: There,
$GIT_EXEC_PATH contains git, in general it does not.
Part 2 allows running the test suite against a git installed anywhere in
the file system. This has at least 2 use cases:
- Test an installed distro package after the installation.
- Run easily current tests against older versions, or vice versa, if you
have those versions installed somewhere.
Note that one still needs git compiled in git.git for test helpers etc.,
and also because I did not adjust the paths to templates and such. I did
not really feel a need for that.
Also, t0000 there is still one explicit use of "../git" which is fine
because it simply tests for the presence of a built, which we need
anyways.
Michael J Gruber (2):
test-lib.sh: Test for presence of git-init in the right path.
test-lib.sh: Allow running the test suite against installed git
t/test-lib.sh | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
^ permalink raw reply
* [JGIT PATCH] Fix sorting of thin packs in PackWriter
From: Shawn O. Pearce @ 2009-03-13 15:45 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
We must retain the TOPO and COMMIT_TIME_DESC rules when we add in
BOUNDARY for a thin pack, otherwise the resulting thin pack won't
match the expected ordering.
Its a non-critical error to sort the pack wrong, but it may cause the
client to skip around the pack data more frequently during access.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/lib/PackWriter.java | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java b/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
index f9945c4..b878409 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
@@ -765,10 +765,10 @@ private ObjectWalk setUpWalker(
throws MissingObjectException, IOException,
IncorrectObjectTypeException {
final ObjectWalk walker = new ObjectWalk(db);
- walker.sort(RevSort.TOPO, true);
+ walker.sort(RevSort.TOPO);
walker.sort(RevSort.COMMIT_TIME_DESC, true);
if (thin)
- walker.sort(RevSort.BOUNDARY);
+ walker.sort(RevSort.BOUNDARY, true);
for (ObjectId id : interestingObjects) {
RevObject o = walker.parseAny(id);
--
1.6.2.288.gc3f22
^ permalink raw reply related
* Re: Generalised bisection
From: Steven Tweed @ 2009-03-13 15:19 UTC (permalink / raw)
To: Ealdwulf Wuffinga
Cc: Johannes Schindelin, John Tapsell, Christian Couder, Git List
In-Reply-To: <efe2b6d70903130549m63ae9bdeg1cd3f24a43b3e66f@mail.gmail.com>
On Fri, Mar 13, 2009 at 12:49 PM, Ealdwulf Wuffinga
<ealdwulf@googlemail.com> wrote:
> On Thu, Mar 12, 2009 at 6:02 PM, Steven Tweed <orthochronous@gmail.com> wrote:
>> I haven't even looked at the source code so a description of the
>> mathematical algorithm would help, but I'll just point out that
>> underflow (in the case of working with probabilities) and overflow
>> (when working with their negated logarithms) is inherent in most
>> multi-step Bayesian algorithms. The only solution is to rescale things
>> as you go so that things stay in a "computable" range. (You're almost
>> never interested in absolute probabilities anyway but rather relative
>> probabilities or, in extreme cases, just the biggest probability, so
>> rescaling isn't losing any useful information.)
>
> Are you sure you aren't thinking of when you are using fixed point? I
> was under the impression
> that Bayesian algorithms usually worked okay in floating point.
Underflow when using probabilities and lack of precision (rather than
overflow) when using negated logarithms are well known problems in the
kind of probabilistic object tracking, inference in graphical networks
and object identification processes I work with (in computer vision).
I there may well be other areas of Bayesian decision theory where this
doesn't happen, and indeed a _very_ quick scan through your document
suggests that you're adding to tallying information on each timestep
and recalcuating the entire model from those tallys, which is one of
the few cases where you can't really do rescaling. I'll try and have a
more detailled read over the weekend.
> One issue in BBChop which should be easy to fix, is that I use a dumb
> way of calculating Beta functions. These
> are ratios of factorials, so the subexpressions get stupidly big very
> quickly. But I don't think that is the only problem.
Yes, "Numerical Recipes" seems to suggest that computing with
log-factorials and exponentiating works reasonably, although I've
never tried it and NR does occasionally get things completely wrong...
^ permalink raw reply
* Re: [PATCH JGIT] Allow writeObject() write to OutputStream
From: Shawn O. Pearce @ 2009-03-13 15:08 UTC (permalink / raw)
To: Daniel Cheng (aka SDiZ); +Cc: git
In-Reply-To: <1236844931-12807-1-git-send-email-j16sdiz+freenet@gmail.com>
"Daniel Cheng (aka SDiZ)" <j16sdiz+freenet@gmail.com> wrote:
>
> This patch make factor out the object writing code in ObjectWriter,
> allow it to write to any OutputStream.
> Subclass class may then override
> writeObject(final int type, long len, InputStream is, boolean store)
> to make it write to alternative locations.
>
> There are some discussion on devl@freenetproject.org to use raw
> (uncompressed) object to freenet. This patch allow the testing.
Ok, I understand the code as-is, but I'm not sure I understand the
reasoning for the change, or where you are trying to go with it.
Are you guys talking about making every object a loose object on
freenet, and avoiding pack files? Or making a form of JGit that
access a Repository directly stored on freenode?
I ask because there's some folks starting to talk about putting JGit
onto a distributed hash table sort of system like Hadoop HBase,
to allow the underlying storage to scale efficiently for really
big hosting sites. I would rather see a pooling of effort here
than folks going in different directions.
--
Shawn.
^ permalink raw reply
* Re: [JGIT PATCH] Create a debugging tool "jgit rebuild-commitgraph"
From: Shawn O. Pearce @ 2009-03-13 14:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Robin Rosenberg, git
In-Reply-To: <alpine.DEB.1.00.0903131549200.6288@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Fri, 13 Mar 2009, Shawn O. Pearce wrote:
>
> > This is a command line tool which can be used to import only
> > the commit graph of another Git repository, to help debug a
> > topology related bug, without actually needing a clone of the
> > problematic repository.
> >
> > Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> > ---
> >
> > I used this yesterday to obtain a DAG from someone's private
> > repository and recreate the same structure on my own system,
> > to debug why RevWalk was busted in their case.
>
> Heh:
>
> http://repo.or.cz/w/git/dscho.git?a=blob;f=my-fake-history.sh;h=e108ce99a5ebd75230c3cfc56b88d9769fec8bc1;hb=master
Heh. I knew both you and Nico have written something like this in
the past, but I couldn't find it.
Your script is almost what I needed. But I also needed to force
GIT_COMMITTER_DATE to match the timestamp, as I suspected the commit
times had something to do with the problem I was seeing.
I also whack the entire ref space to match the source repository,
which mattered because I was trying to debug:
git rev-list $insha1 --not --all
in JGit...
--
Shawn.
^ permalink raw reply
* Re: [JGIT PATCH] Create a debugging tool "jgit rebuild-commitgraph"
From: Johannes Schindelin @ 2009-03-13 14:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Robin Rosenberg, git
In-Reply-To: <1236954901-30990-1-git-send-email-spearce@spearce.org>
Hi,
On Fri, 13 Mar 2009, Shawn O. Pearce wrote:
> This is a command line tool which can be used to import only
> the commit graph of another Git repository, to help debug a
> topology related bug, without actually needing a clone of the
> problematic repository.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
>
> I used this yesterday to obtain a DAG from someone's private
> repository and recreate the same structure on my own system,
> to debug why RevWalk was busted in their case.
Heh:
http://repo.or.cz/w/git/dscho.git?a=blob;f=my-fake-history.sh;h=e108ce99a5ebd75230c3cfc56b88d9769fec8bc1;hb=master
Ciao,
Dscho
^ permalink raw reply
* [JGIT PATCH] Create a debugging tool "jgit rebuild-commitgraph"
From: Shawn O. Pearce @ 2009-03-13 14:35 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
This is a command line tool which can be used to import only
the commit graph of another Git repository, to help debug a
topology related bug, without actually needing a clone of the
problematic repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
I used this yesterday to obtain a DAG from someone's private
repository and recreate the same structure on my own system,
to debug why RevWalk was busted in their case.
Its only meant for debugging weird cases, I can't see many
uses of it. But now that its written, maybe we should add
it to the project and keep it around.
.../services/org.spearce.jgit.pgm.TextBuiltin | 1 +
.../org/spearce/jgit/pgm/RebuildCommitGraph.java | 276 ++++++++++++++++++++
2 files changed, 277 insertions(+), 0 deletions(-)
create mode 100644 org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/RebuildCommitGraph.java
diff --git a/org.spearce.jgit.pgm/src/META-INF/services/org.spearce.jgit.pgm.TextBuiltin b/org.spearce.jgit.pgm/src/META-INF/services/org.spearce.jgit.pgm.TextBuiltin
index 1ba29e6..9bba156 100644
--- a/org.spearce.jgit.pgm/src/META-INF/services/org.spearce.jgit.pgm.TextBuiltin
+++ b/org.spearce.jgit.pgm/src/META-INF/services/org.spearce.jgit.pgm.TextBuiltin
@@ -11,6 +11,7 @@ org.spearce.jgit.pgm.LsRemote
org.spearce.jgit.pgm.LsTree
org.spearce.jgit.pgm.MergeBase
org.spearce.jgit.pgm.Push
+org.spearce.jgit.pgm.RebuildCommitGraph
org.spearce.jgit.pgm.ReceivePack
org.spearce.jgit.pgm.RevList
org.spearce.jgit.pgm.Rm
diff --git a/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/RebuildCommitGraph.java b/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/RebuildCommitGraph.java
new file mode 100644
index 0000000..ccee997
--- /dev/null
+++ b/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/RebuildCommitGraph.java
@@ -0,0 +1,276 @@
+/*
+ * Copyright (C) 2009, Google Inc.
+ *
+ * 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.pgm;
+
+import java.io.BufferedReader;
+import java.io.File;
+import java.io.FileInputStream;
+import java.io.IOException;
+import java.io.InputStreamReader;
+import java.util.ArrayList;
+import java.util.Date;
+import java.util.HashMap;
+import java.util.List;
+import java.util.ListIterator;
+import java.util.Map;
+
+import org.kohsuke.args4j.Argument;
+import org.spearce.jgit.errors.MissingObjectException;
+import org.spearce.jgit.errors.ObjectWritingException;
+import org.spearce.jgit.lib.Commit;
+import org.spearce.jgit.lib.Constants;
+import org.spearce.jgit.lib.LockFile;
+import org.spearce.jgit.lib.ObjectId;
+import org.spearce.jgit.lib.ObjectWriter;
+import org.spearce.jgit.lib.PersonIdent;
+import org.spearce.jgit.lib.ProgressMonitor;
+import org.spearce.jgit.lib.Ref;
+import org.spearce.jgit.lib.RefUpdate;
+import org.spearce.jgit.lib.RefWriter;
+import org.spearce.jgit.lib.TextProgressMonitor;
+import org.spearce.jgit.lib.Tree;
+import org.spearce.jgit.revwalk.RevWalk;
+
+/**
+ * Recreates a repository from another one's commit graph.
+ * <p>
+ * <b>Do not run this on a repository unless you want to destroy it.</b>
+ * <p>
+ * To create the input files, in the source repository use:
+ *
+ * <pre>
+ * git for-each-ref >in.refs
+ * git log --all '--pretty=format:%H %ct %P' >in.dag
+ * </pre>
+ * <p>
+ * Run the rebuild in either an empty repository, or a clone of the source. Any
+ * missing commits (which might be the entire graph) will be created. All refs
+ * will be modified to match the input exactly, which means some refs may be
+ * deleted from the current repository.
+ * <p>
+ */
+class RebuildCommitGraph extends TextBuiltin {
+ @Argument(index = 0, required = true, metaVar = "REFS", usage = "for-each-ref output")
+ File refList;
+
+ @Argument(index = 1, required = true, metaVar = "DAG", usage = "log --all '--pretty=format:%H %ct %P' output")
+ File graph;
+
+ private final ProgressMonitor pm = new TextProgressMonitor();
+
+ private Map<ObjectId, ObjectId> rewrites = new HashMap<ObjectId, ObjectId>();
+
+ @Override
+ protected void run() throws Exception {
+ recreateCommitGraph();
+ detachHead();
+ deleteAllRefs();
+ recreateRefs();
+ }
+
+ private void recreateCommitGraph() throws IOException {
+ final RevWalk rw = new RevWalk(db);
+ final Map<ObjectId, ToRewrite> toRewrite = new HashMap<ObjectId, ToRewrite>();
+ List<ToRewrite> queue = new ArrayList<ToRewrite>();
+ final BufferedReader br = new BufferedReader(new InputStreamReader(
+ new FileInputStream(graph), Constants.CHARSET));
+ try {
+ String line;
+ while ((line = br.readLine()) != null) {
+ final String[] parts = line.split("[ \t]{1,}");
+ final ObjectId oldId = ObjectId.fromString(parts[0]);
+ try {
+ rw.parseCommit(oldId);
+ // We have it already. Don't rewrite it.
+ continue;
+ } catch (MissingObjectException mue) {
+ // Fall through and rewrite it.
+ }
+
+ final long time = Long.parseLong(parts[1]) * 1000L;
+ final ObjectId[] parents = new ObjectId[parts.length - 2];
+ for (int i = 0; i < parents.length; i++) {
+ parents[i] = ObjectId.fromString(parts[2 + i]);
+ }
+
+ final ToRewrite t = new ToRewrite(oldId, time, parents);
+ toRewrite.put(oldId, t);
+ queue.add(t);
+ }
+ } finally {
+ br.close();
+ }
+
+ pm.beginTask("Rewriting commits", queue.size());
+ final ObjectWriter ow = new ObjectWriter(db);
+ final ObjectId emptyTree = ow.writeTree(new Tree(db));
+ final PersonIdent me = new PersonIdent("jgit rebuild-commitgraph",
+ "rebuild-commitgraph@localhost");
+ while (!queue.isEmpty()) {
+ final ListIterator<ToRewrite> itr = queue
+ .listIterator(queue.size());
+ queue = new ArrayList<ToRewrite>();
+ REWRITE: while (itr.hasPrevious()) {
+ final ToRewrite t = itr.previous();
+ final ObjectId[] newParents = new ObjectId[t.oldParents.length];
+ for (int k = 0; k < t.oldParents.length; k++) {
+ final ToRewrite p = toRewrite.get(t.oldParents[k]);
+ if (p != null) {
+ if (p.newId == null) {
+ // Must defer until after the parent is rewritten.
+ queue.add(t);
+ continue REWRITE;
+ } else {
+ newParents[k] = p.newId;
+ }
+ } else {
+ // We have the old parent object. Use it.
+ //
+ newParents[k] = t.oldParents[k];
+ }
+ }
+
+ final Commit newc = new Commit(db);
+ newc.setTreeId(emptyTree);
+ newc.setAuthor(new PersonIdent(me, new Date(t.commitTime)));
+ newc.setCommitter(newc.getAuthor());
+ newc.setParentIds(newParents);
+ newc.setMessage("ORIGINAL " + t.oldId.name() + "\n");
+ t.newId = ow.writeCommit(newc);
+ rewrites.put(t.oldId, t.newId);
+ pm.update(1);
+ }
+ }
+ pm.endTask();
+ }
+
+ private static class ToRewrite {
+ final ObjectId oldId;
+
+ final long commitTime;
+
+ final ObjectId[] oldParents;
+
+ ObjectId newId;
+
+ ToRewrite(final ObjectId o, final long t, final ObjectId[] p) {
+ oldId = o;
+ commitTime = t;
+ oldParents = p;
+ }
+ }
+
+ private void detachHead() throws IOException {
+ final String head = db.getFullBranch();
+ final ObjectId id = db.resolve(Constants.HEAD);
+ if (!ObjectId.isId(head) && id != null) {
+ final LockFile lf;
+ lf = new LockFile(new File(db.getDirectory(), Constants.HEAD));
+ if (!lf.lock())
+ throw new IOException("Cannot lock HEAD");
+ lf.write(id);
+ if (!lf.commit())
+ throw new IOException("Cannot deatch HEAD");
+ }
+ }
+
+ private void deleteAllRefs() throws Exception {
+ final RevWalk rw = new RevWalk(db);
+ for (final Ref r : db.getAllRefs().values()) {
+ if (Constants.HEAD.equals(r.getName()))
+ continue;
+ final RefUpdate u = db.updateRef(r.getName());
+ u.setForceUpdate(true);
+ u.delete(rw);
+ }
+ }
+
+ private void recreateRefs() throws Exception {
+ final Map<String, Ref> refs = computeNewRefs();
+ new RefWriter(refs.values()) {
+ @Override
+ protected void writeFile(final String name, final byte[] content)
+ throws IOException {
+ final File file = new File(db.getDirectory(), name);
+ final LockFile lck = new LockFile(file);
+ if (!lck.lock())
+ throw new ObjectWritingException("Can't write " + file);
+ try {
+ lck.write(content);
+ } catch (IOException ioe) {
+ throw new ObjectWritingException("Can't write " + file);
+ }
+ if (!lck.commit())
+ throw new ObjectWritingException("Can't write " + file);
+ }
+ }.writePackedRefs();
+ }
+
+ private Map<String, Ref> computeNewRefs() throws IOException {
+ final RevWalk rw = new RevWalk(db);
+ final Map<String, Ref> refs = new HashMap<String, Ref>();
+ final BufferedReader br = new BufferedReader(new InputStreamReader(
+ new FileInputStream(refList), Constants.CHARSET));
+ try {
+ String line;
+ while ((line = br.readLine()) != null) {
+ final String[] parts = line.split("[ \t]{1,}");
+ final ObjectId origId = ObjectId.fromString(parts[0]);
+ final String type = parts[1];
+ final String name = parts[2];
+
+ ObjectId id = rewrites.get(origId);
+ if (id == null)
+ id = origId;
+ try {
+ rw.parseAny(id);
+ } catch (MissingObjectException mue) {
+ if (!Constants.TYPE_COMMIT.equals(type)) {
+ System.err.println("skipping " + type + " " + name);
+ continue;
+ }
+ throw new MissingObjectException(id, type);
+ }
+ refs.put(name, new Ref(Ref.Storage.PACKED, name, id));
+ }
+ } finally {
+ br.close();
+ }
+ return refs;
+ }
+}
--
1.6.2.288.gc3f22
^ permalink raw reply related
* Re: Transparently encrypt repository contents with GPG
From: Sverre Rabbelier @ 2009-03-13 14:19 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Thomas Rast, Michael J Gruber, Matthias Nothhaft, git
In-Reply-To: <49BA6606.1070403@fastmail.fm>
Heya,
On Fri, Mar 13, 2009 at 14:56, Michael J Gruber
<michaeljgruber+gmane@fastmail.fm> wrote:
> Sverre was being prophetic with the somehow. Here's a working setup
> (though I still don't know why not to use luks):
Glad to hear I was right ;). Also awesome that you looked into this
and shared your findings, thanks!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git checkout -b origin/mybranch origin/mybranch
From: Michael J Gruber @ 2009-03-13 14:08 UTC (permalink / raw)
To: John Tapsell; +Cc: Sverre Rabbelier, Johannes Schindelin, Git List
In-Reply-To: <43d8ce650903120714g782b98e8t81340546547fe98d@mail.gmail.com>
John Tapsell venit, vidit, dixit 12.03.2009 15:14:
> 2009/3/12 Sverre Rabbelier <srabbelier@gmail.com>:
>> Heya,
>>
>> On Thu, Mar 12, 2009 at 14:18, John Tapsell <johnflux@gmail.com> wrote:
>>> Is probably a mistake by the user. We should warn the user and point
>>> them in the right direction.
>>
>> The point is that we _already_ warned the user (like Dscho pointed
>> out), and that(as you pointed out), it didn't work :P.
>
> Just doing:
>
> git branch -b origin/master origin/master
>
> gives no error or warning at all.
...and it really should not. If you have a repo with lots of remotes and
tracking branches, it makes a lot of sense to have a local branch
reponame/branchname which tracks the remote branch reponame/branchname.
Note that the first is refs/heads/reponame/branchname whereas the latter
is refs/remotes/reponame/branchname. It gives warnings when it's
ambiguous, yay.
Michael J Gruber
^ 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