* Re: GIT on MinGW problem
From: Han-Wen Nienhuys @ 2007-05-27 17:04 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt
In-Reply-To: <Pine.LNX.4.64.0705271149450.4648@racer.site>
Johannes Schindelin escreveu:
>> ((Tcl_Obj **) objv) += (async + 3);
>
> Ah yes, I was using MinGW's own GCC, which is GCC 3.something.
>
> It is a new "feature" of GCC 4.x to disallow constructs like these.
> (Probably because GCC people think that other people are not intelligent
> enough to understand such constructs, and therefore prohibit their use.)
I very much doubt that. GCC uses type information to determine whether
pointers might be aliased. I think disallowing such constructs helps with
compiler optimization.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: t9107-git-svn-migrate.sh fails
From: Eric Wong @ 2007-05-27 17:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705261123420.4648@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sat, 26 May 2007, Eric Wong wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > I recently wanted to use git-svn, and installed the svn perl bindings.
> > > Since then, t9107 is failing:
> > >
> > > -- snip --
> > > [...]
> > > Rebuilding .git/svn/git-svn/.rev_db.f944dda1-3e31-0410-9475-8f268450faf6
> > > ...
> > > r1 = b9b82a419abdbb54f51a41bc8a3118b28c791ac1
> > > Done rebuilding
> > > .git/svn/git-svn/.rev_db.f944dda1-3e31-0410-9475-8f268450faf6
> > > diff --git
> > > a/home/gene099/my/git/t/trash/.git/svn/trunk/.rev_db.f944dda1-3e31-0410-9475-8f268450faf6
> > > b/home/gene099/my/git/t/trash/.git/svn/trunk/.rev_db
> > > index d3f1b6e..01d8afd 100644
> > > ---
> > > a/home/gene099/my/git/t/trash/.git/svn/trunk/.rev_db.f944dda1-3e31-0410-9475-8f268450faf6
> > > +++ b/home/gene099/my/git/t/trash/.git/svn/trunk/.rev_db
> > > @@ -1,2 +1 @@
> > > -0000000000000000000000000000000000000000
> > > -6aa651a66730888e854a8de54199d62ffa402739
> > > +.rev_db.f944dda1-3e31-0410-9475-8f268450faf6
> > > \ No newline at end of file
> > > * FAIL 7: .rev_db auto-converted to .rev_db.UUID
> > >
> > > git-svn fetch -i trunk &&
> > > [...]
> > > -- snap --
> > >
> > > Usually I try to fix things like this myself, but I really have to get
> > > some dinner now. Besides, other people than me seem to be way more clever
> > > with perl code.
> >
> > .git/svn/trunk/.rev_db should be
> > a symlink to
> > .git/svn/trunk/.rev_db.f944dda1-3e31-0410-9475-8f268450faf6
> >
> > I keep .rev_db around as a symlink for backwards compatibility in case
> > the user wants to downgrade.
> >
> > I'm running cmp(1) to compare the file and symlink. Are you running
> > diff2[1] replacements in your tree and it's not understanding symlinks?
>
> D'oh!
>
> Yes, I did a wholesale replacement of all cmp and diff invocations to
> git-diff.
>
> Two thoughts:
>
> - why don't you check it with readlink?
I'm not sure about the portability of readlink(1). cmp(1) is used in
several places already, whereas readlink(1) is not.
> - git diff should really output something when a file is compared
> to a symlink...
>
> I guess the second is something for my TODO list.
>
> > > Anybody knows how to fix this?
> >
> > Works for me(TM).
>
> Changing the check back to cmp make it work here, too.
>
> > [1] - I think that's what you called it. I have had trouble keeping
> > up-to-date with git things lately.
>
> Yep, I called it diff2. But we found out that we can DWIM git-diff to do
> it; if in doubt, just say "git diff --no-index".
Cool :)
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Fix git-svn to handle svn not reporting the md5sum of a file, and test.
From: Eric Wong @ 2007-05-27 17:23 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: James Y Knight, git, Junio C Hamano
In-Reply-To: <4659703B.8070101@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> wrote:
> James Y Knight wrote:
> >---
> > git-svn.perl | 2 +-
> > t/t9112-git-svn-md5less-file.sh | 45
> > +++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 46 insertions(+), 1 deletions(-)
> > create mode 100755 t/t9112-git-svn-md5less-file.sh
> [...]
>
> The new test fails here (Suse 9.3 fully patched) w/ the following:
>
> *** t9112-git-svn-md5less-file.sh ***
> * ok 1: load svn dumpfile
> * ok 2: initialize git-svn
> * FAIL 3: fetch revisions from svn
> git-svn fetch
> * failed 1 among 3 test(s)
> make[1]: *** [t9112-git-svn-md5less-file.sh] Error 1
I can't reproduce it here (on Debian Etch, SVN 1.4.2). Can you run with
the test with the -v switch? Thanks.
--
Eric Wong
^ permalink raw reply
* Re: t9107-git-svn-migrate.sh fails
From: Junio C Hamano @ 2007-05-27 18:50 UTC (permalink / raw)
To: Eric Wong; +Cc: Johannes Schindelin, git
In-Reply-To: <20070527172336.GA27725@muzzle>
Eric Wong <normalperson@yhbt.net> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>
>> Two thoughts:
>>
>> - why don't you check it with readlink?
>
> I'm not sure about the portability of readlink(1). cmp(1) is used in
> several places already, whereas readlink(1) is not.
You did a very sensible thing; avoidance of readlink has been
very deliberate. And I'd be happier if things stayed that way.
^ permalink raw reply
* Re: GIT on MinGW problem
From: Han-Wen Nienhuys @ 2007-05-27 18:50 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <f3a2ke$9s7$1@sea.gmane.org>
Han-Wen Nienhuys escreveu:
> The only solution is to x-compile wish and include it as well. I need several
> strong drinks to start trying this. Is there a MinGW wish port?
It turns out that spending a night in a brazilian/japanese karaoke bar
where thumping disco beats of the sadly deserted dance area permeates
the bleary out-of-tune portuguese singing of hormonally driven women did
enough to melt my mind.
There is a 1.5.2-3 installer which includes a cross-compiled tcltk.
http://lilypond.org/git/binaries/mingw/
What is the proper way to have the 'gitk' command start up with wish
automatically?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH] Fix git-svn to handle svn not reporting the md5sum of a file, and test.
From: A Large Angry SCM @ 2007-05-27 19:28 UTC (permalink / raw)
To: Eric Wong; +Cc: James Y Knight, git, Junio C Hamano
In-Reply-To: <20070527172351.GA27309@muzzle>
Eric Wong wrote:
> A Large Angry SCM <gitzilla@gmail.com> wrote:
>> James Y Knight wrote:
>>> ---
>>> git-svn.perl | 2 +-
>>> t/t9112-git-svn-md5less-file.sh | 45
>>> +++++++++++++++++++++++++++++++++++++++
>>> 2 files changed, 46 insertions(+), 1 deletions(-)
>>> create mode 100755 t/t9112-git-svn-md5less-file.sh
>> [...]
>>
>> The new test fails here (Suse 9.3 fully patched) w/ the following:
>>
>> *** t9112-git-svn-md5less-file.sh ***
>> * ok 1: load svn dumpfile
>> * ok 2: initialize git-svn
>> * FAIL 3: fetch revisions from svn
>> git-svn fetch
>> * failed 1 among 3 test(s)
>> make[1]: *** [t9112-git-svn-md5less-file.sh] Error 1
>
> I can't reproduce it here (on Debian Etch, SVN 1.4.2). Can you run with
> the test with the -v switch? Thanks.
>
~/GIT/git/t> sh ./t9112-git-svn-md5less-file.sh -v
* expecting success: svnadmin load /home/test/GIT/git/t/trash/svnrepo <
dumpfile.svn
<<< Started new transaction, based on original revision 1
* adding path : md5less-file ... done.
------- Committed revision 1 >>>
* ok 1: load svn dumpfile
* expecting success: git-svn init file:///home/test/GIT/git/t/trash/svnrepo
* ok 2: initialize git-svn
* expecting success: git-svn fetch
./test-lib.sh: line 141: 8163 Segmentation fault git-svn fetch
* FAIL 3: fetch revisions from svn
git-svn fetch
* failed 1 among 3 test(s)
~/GIT/git/t>
And here is the failing part of the test using sh -x:
+ test_expect_success 'fetch revisions from svn' 'git-svn fetch'
+ test 2 = 2
+ test_skip 'fetch revisions from svn' 'git-svn fetch'
++ expr ././t9112-git-svn-md5less-file.sh : '.*/\(t[0-9]*\)-[^/]*$'
+ this_test=t9112
++ expr 2 + 1
+ this_test=t9112.3
+ to_skip=
+ case "$to_skip" in
+ false
+ say 'expecting success: git-svn fetch'
+ echo '* expecting success: git-svn fetch'
* expecting success: git-svn fetch
+ test_run_ 'git-svn fetch'
+ eval 'git-svn fetch'
++ git-svn fetch
./test-lib.sh: line 141: 8276 Segmentation fault git-svn fetch
+ eval_ret=139
+ return 0
+ '[' 0 = 0 -a 139 = 0 ']'
+ test_failure_ 'fetch revisions from svn' 'git-svn fetch'
++ expr 2 + 1
+ test_count=3
++ expr 0 + 1
+ test_failure=1
+ say 'FAIL 3: fetch revisions from svn'
+ echo '* FAIL 3: fetch revisions from svn'
* FAIL 3: fetch revisions from svn
+ shift
+ echo 'git-svn fetch'
+ sed -e 's/^/ /'
git-svn fetch
+ test '' = ''
+ echo ''
This began after the 18bece4..99b5a79 update to master. Prior to that
the svn tests were passing.
^ permalink raw reply
* GIT on MinGW, with tcltk for gitk
From: Han-Wen Nienhuys @ 2007-05-27 19:52 UTC (permalink / raw)
To: git
In-Reply-To: <4659D306.6030803@xs4all.nl>
Han-Wen Nienhuys escreveu:
> There is a 1.5.2-3 installer which includes a cross-compiled tcltk.
>
> http://lilypond.org/git/binaries/mingw/
>
> What is the proper way to have the 'gitk' command start up with wish
> automatically?
I've just uploaded 1.5.2-5, which also writes a gitk.bat file, containing
proper paths. However, I can't get it working in Wine. Any windows user
that cares to test?
http://lilypond.org/git/binaries/mingw/git-1.5.2-5.mingw.exe
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH 00/15] git-note: A mechanisim for providing free-form after-the-fact annotations on commits
From: Junio C Hamano @ 2007-05-27 20:09 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Linus Torvalds
In-Reply-To: <200705271608.02122.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> I've been working on combining tag objects and --decorate into a useful
> proof-of-concept that provides the after-the-fact commit annotations I
> requested above, and here's the result:
> ...
Very nicely presented. I appreciate [PATCH 0/N] summary for a
series like this that talks about not just what and how it does,
but focus more on why it does it in a particular way, on design
issues, and decisions. It makes it very pleasant to comment on
the series to have a well written summary like this, because in
the early stage of a review cycle, we would want to talk about
the design, ignoring implementation details.
> However, there are still some remaining questions:
>
> - Is the creation of a unique tag name (i.e. the 'tag' field _inside_ the
> object) for note objects really necessary? Which parts of the system rely
> on these names to be unique across tag objects?
None. Although your use of note-X{40} would make "recovering"
easier, I would imagine.
> - Should notes have their own object type instead of piggy-backing on "tag"?
>
> - What about having a note object type with minimal header fields, and make
> tags just a special case of a note object with an extra tag name header?
Two things struck me:
- The "reverse" mapping 'note' tag uses uses FS as a database.
Clever but would not scale well.
- *BUT* the reverse mapping 'note' tag uses is exactly what we
would want to use for tags that are not notes, for tools
like gitk to attach little flags to commits.
So maybe we _should_ not even need to call this a new 'notes'
system. I am just saying your second point above in a different
way, but I suspect all what is needed is to make the filtering
and presentation of tag objects a bit more flexible, and making
use of the 'peeled' (see .git/packed-refs, for example) mapping
ultra cheap for ordinary tags.
What you would need are:
- Ultra-cheap reverse lookup: "I have an object; which tags
point at this?"
You solved it with refs/notes/<sha1-of-tagged>/, but it would
be useful to extend this to any tag in general.
- Easy way to filter the above question: "I have an object;
which tags of this particlar class point at this?"
You are essentially prefiltering by only making notes tags
available via refs/notes/ hierarchy, but you can also filter
with your naming convention "tag notes-<sha1>". We _could_
(I am not seriously suggesting this yet as I haven't thought
through the issues yet) allow "keyword" header to tag
objects, and allow --decorate='kwd1,kwd2,...' to limit the
tags we take object decorations from the ones that has one of
the specified keywords. If we do that, I suspect your
'notes' system would naturally fall out as regular tags that
happen to have a keyword header with 'note' on it.
> - What about notes on notes? How are tags on tags treated? How should they be
> treated?
You can create a tag object that points at another tag. When we
peel a tag using "^{}" notation, currently it is peeled all the
way until we hit a non tag, so if you need to look at
intermediate tags, you need to parse them yourself. IOW, there
is no Porcelain feature to let you take advantage of this
capability, easily. But we could use this to say "I attest that
he tagged that object".
> - Currently noted objects (notees?) are treated as reachable from their
> associated notes, i.e. like tags. This means that an otherwise dangling
> object will not be detected and removed if it has associated notes.
I think it largely depends on how you intend to use 'notes' if
this is a problem.
The reachability issue is not limited to cruft removal; it also
affects the fetching.
I would imagine the intended use of a 'note' is to annotate
objects (mostly commits, but not necessarily) after the fact,
e.g. "this is reported to fix the issue 35833". You may or may
not want to propagate this across repositories, and the way you
implemented it is to have a ref pointing at the note -- then it
would make it fetchable by other people. Otherwise it would not.
With your implementation, unfortunately, not having a ref under
refs/notes/ would also make the information unavailable to
yourself.
I think the semantics you would want, when a 'note' object that
points at another object (pointee) exists, is to allow creating
a fake (reverse) reachability that says "pointee points at the
note". When such a reachability exists:
- A fetch from such a repository that transfers out the pointee
will drag the note attached to it along with it (so you would
teach rev-list/upload-pack about the extended reachability).
- Incidentally, having a ref that points at the pointee is
enough to protect the note that points at the pointee from
getting pruned (so you would teach fsck/prune about the
extended reachability).
Othewise, the 'note' is subject to garbage collection. This is
pretty much an extension to the existing 'grafts' mechanism,
which can only override commit and its parents; what is done in
the above is to add (not override) to existing reachability to
any object (not just commit, but anything that can get 'noted').
^ permalink raw reply
* [PATCH] Add basic test-script for git-submodule
From: Lars Hjemli @ 2007-05-27 20:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
This test verifies the basic operations in git-submodule, i.e. that it is
able to clone and update a submodule repository, that its status output is
sane, and that it errors out when the submodule path is occupied during
init.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Finally the test-script emerges. Btw, thanks for fixing my broken submodule
patch :)
t/t7400-submodule-basic.sh | 82 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 82 insertions(+), 0 deletions(-)
create mode 100755 t/t7400-submodule-basic.sh
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
new file mode 100755
index 0000000..2212b29
--- /dev/null
+++ b/t/t7400-submodule-basic.sh
@@ -0,0 +1,82 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Lars Hjemli
+#
+
+test_description='Basic submodule support in porcelain
+
+This test tries to run the init, update and status commands of git-submodule
+with a known good setup (and two known bad)
+'
+
+. ./test-lib.sh
+
+
+# create a submodule repository
+mkdir lib && cd lib
+git-init >/dev/null
+echo a >a && git-add a && git-commit -q -m "submodule commit 1"
+git-tag -a -m "rev-1" rev-1
+rev1=$(git-rev-parse HEAD)
+cd ..
+
+# add submodule and other files to super repo
+echo a >a && echo z >z
+git-add a lib z && git-commit -q -m "super commit 1"
+
+# move submodule to another location, register repo url in .gitmodules
+mv lib .subrepo
+GIT_CONFIG=.gitmodules git-config module.lib.url ./.subrepo
+
+test_expect_success 'status is "missing"' \
+ 'git-submodule status | grep "^-$rev1"'
+
+# make sure 'init' will not overwrite a regular file
+touch lib
+test_expect_failure 'init fails when path is used by a file' \
+ 'git-submodule init'
+
+# make sure 'init' will not overwrite a nonempty directory
+rm lib
+mkdir -p lib/foo
+test_expect_failure 'init fails when path is used by a nonempty directory' \
+ 'git-submodule init'
+
+# turn lib into an empty directory, just like git-checkout would do
+rmdir lib/foo
+test_expect_success 'init works when path is an empty dir' \
+ 'git-submodule init && test -d lib/.git && git-diff --exit-code'
+
+head=$(cd lib && git-rev-parse HEAD)
+test_expect_success 'submodule HEAD should match rev1' \
+ 'test "$head" = "$rev1"'
+
+test_expect_success 'status is "up-to-date" after init' \
+ 'git-submodule status | grep "^ $rev1"'
+
+# change the submodule HEAD
+cd lib
+echo b >b && git-add b && git-commit -q -m "submodule commit 2"
+rev2=$(git-rev-parse HEAD)
+cd ..
+
+test_expect_success 'status is "modified" after submodule commit' \
+ 'git-submodule status | grep "^\+$rev2"'
+
+test_expect_success 'the --cached sha1 should be rev1' \
+ 'git-submodule --cached status | grep "^\+$rev1"'
+
+test_expect_failure 'git-diff --exit-code reports local modifications' \
+ 'git-diff --exit-code'
+
+test_expect_success 'update should checkout the correct commit' \
+ 'git-submodule update && git-diff --exit-code'
+
+head=$(cd lib && git-rev-parse HEAD)
+test_expect_success 'submodule HEAD should match rev1' \
+ 'test "$head" = "$rev1"'
+
+test_expect_success 'status is "up-to-date" after update' \
+ 'git-submodule status | grep "^ $rev1"'
+
+test_done
--
1.5.2.74.g6b2d
^ permalink raw reply related
* Re: [RFC] Fourth round of support for cloning submodules
From: Martin Waitz @ 2007-05-27 20:34 UTC (permalink / raw)
To: Johannes Schindelin
Cc: skimo, Shawn O. Pearce, Junio C Hamano, git, Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0705241201270.4648@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]
hoi :)
On Thu, May 24, 2007 at 12:02:41PM +0100, Johannes Schindelin wrote:
> On Thu, 24 May 2007, Sven Verdoolaege wrote:
> > On Thu, May 24, 2007 at 10:41:30AM +0100, Johannes Schindelin wrote:
> > > On Thu, 24 May 2007, Sven Verdoolaege wrote:
> > > > You mean like a tag "submodules" that points to a text file
> > > > describing the submodules?
> > > > That's a bit of a pain to set up since you would want that
> > > > to be independent of your project.
> > >
> > > I could imagine this to be another extension of ls-remote.
> >
> > You mean extending upload-pack ? Junio mentioned this possibility as well.
> > This only solves the git:// and ssh:// case though.
> > What to do with the other protocols?
>
> As we do for the refs: put it into .git/info/refs. This file is already
> meant to "cache" the output of ls-remote for dumb protocols.
why on earth do you want to store a subproject SHA1 in the
superproject.git?
The subproject only exists as a part of the superproject tree and thus
there is no "the subproject SHA1 which is used by the superproject".
It just doesn't work as you can have several superproject branches with
different subproject. And even the superproject can itself be a
subproject.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: GIT on MinGW, with tcltk for gitk
From: Aaron Gray @ 2007-05-27 20:39 UTC (permalink / raw)
To: hanwen, git
In-Reply-To: <f3cnm6$gda$1@sea.gmane.org>
> Han-Wen Nienhuys escreveu:
>> There is a 1.5.2-3 installer which includes a cross-compiled tcltk.
>>
>> http://lilypond.org/git/binaries/mingw/
>>
>> What is the proper way to have the 'gitk' command start up with wish
>> automatically?
>
> I've just uploaded 1.5.2-5, which also writes a gitk.bat file, containing
> proper paths. However, I can't get it working in Wine. Any windows user
> that cares to test?
>
> http://lilypond.org/git/binaries/mingw/git-1.5.2-5.mingw.exe
>
git clone or git-clone are not accessable still.
C:\Work\test>git init
warning: templates not found C:/Program Files/Git/usr/bin@template_dir@
Initialized empty Git repository in .git/
Aaron
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-27 20:40 UTC (permalink / raw)
To: Martin Waitz
Cc: Johannes Schindelin, Shawn O. Pearce, Junio C Hamano, git,
Alex Riesen
In-Reply-To: <20070527203442.GC8361@admingilde.org>
On Sun, May 27, 2007 at 10:34:42PM +0200, Martin Waitz wrote:
> On Thu, May 24, 2007 at 12:02:41PM +0100, Johannes Schindelin wrote:
> > As we do for the refs: put it into .git/info/refs. This file is already
> > meant to "cache" the output of ls-remote for dumb protocols.
>
> why on earth do you want to store a subproject SHA1 in the
> superproject.git?
Did you read that sentence after writing it?
Anyway, we already concluded further down the thread that
it wouldn't make sense to put any particular subproject SHA-1
in the superproject's info/refs.
skimo
^ permalink raw reply
* Re: GIT on MinGW problem
From: Han-Wen Nienhuys @ 2007-05-27 20:44 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt
In-Reply-To: <Pine.LNX.4.64.0705262311380.4648@racer.site>
Johannes Schindelin escreveu:
> There's a bash src in the Snapshot package of MinGW:
>
> http://prdownloads.sf.net/mingw/bash-2.05b-MSYS-src.tar.bz2?download
this thoroughly confuses me.
Does it require MSYS? If yes, where can I find the MSYS source code?
What does it mean that:
However, it is important to remember that NO executables other than
what ships with MSYS should be placed in the MSYS " bin"
subdirectory. Therefore, do not attempt to "merge" the two packages.
(http://www.mingw.org/mingwfaq.shtml#faq-msys)
If this is true, this will mess up my installers.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: GIT on MinGW, with tcltk for gitk
From: Han-Wen Nienhuys @ 2007-05-27 21:19 UTC (permalink / raw)
To: Aaron Gray; +Cc: git
In-Reply-To: <00a601c7a09f$218c1020$0200a8c0@AMD2500>
Aaron Gray escreveu:
> C:\Work\test>git init
> warning: templates not found C:/Program Files/Git/usr/bin@template_dir@
> Initialized empty Git repository in .git/
>
> Aaron
Thanks for the report. Can you try again with 1.5.2-7 ? It should be available
in a few minutes.
Also, can you tell me if gitk.bat works for you?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: GIT on MinGW, with tcltk for gitk
From: Aaron Gray @ 2007-05-27 21:24 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <4659F5D0.2070406@xs4all.nl>
> Aaron Gray escreveu:
>
>> C:\Work\test>git init
>> warning: templates not found C:/Program Files/Git/usr/bin@template_dir@
>> Initialized empty Git repository in .git/
>>
>> Aaron
>
> Thanks for the report. Can you try again with 1.5.2-7 ? It should be
> available
> in a few minutes.
Okay, I'm up for all the testing thats needed. Just dont know the territory
that well though, as I am a Windozer :)
> Also, can you tell me if gitk.bat works for you?
Okay, I just type 'gitk' ?
And what happens ?
Thanks,
Aaron
^ permalink raw reply
* Re: GIT on MinGW problem
From: Johannes Schindelin @ 2007-05-27 21:26 UTC (permalink / raw)
To: hanwen; +Cc: Johannes Sixt, git
In-Reply-To: <f329bf540705271417k1874c1f2u3acc98dc25e058b9@mail.gmail.com>
Hi,
On Sun, 27 May 2007, Han-Wen Nienhuys wrote:
> there is a
>
> bin/msys-1.0.dll
> bin/libW11.dll
>
> inside the tarball. I want to know what they are, and how to build them.
Oops. I missed that. I guess that msys-1.0.dll is built from
http://downloads.sourceforge.net/mingw/msys-1.0.10-src.tar.bz2
and that libW11.dll is built from some package in
http://sourceforge.net/project/showfiles.php?group_id=37352
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/3] Lazily open pack index files on demand
From: Shawn O. Pearce @ 2007-05-27 21:35 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Dana How, Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.99.0705271127110.3366@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Sat, 26 May 2007, Dana How wrote:
>
> > On 5/26/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> > > In pack v4 we're likely to move the SHA-1 table from the .idx file
> > > into the front of the .pack file. This makes the .idx file hold
> > > only the offsets and the CRC checkums of each object. If we start
> > > making a super index, we have to duplicate the SHA-1 table twice
> > > (once in the .pack, again in the super index).
> >
> > Hmm, hopefully the SHA-1 table can go at the _end_
> > since with split packs that's the only time we know the number
> > of objects in the pack... ;-)
>
> Hmmm good point to consider.
The problem with putting the SHA-1 table at the end of the pack is
it ruins the streaming for both unpack-objects and index-pack if
we were to ever use pack v4 as a transport format. Or just try
to run a pack v4 packfile through unpack-objects, just locally,
say to extract megablobs. ;-)
--
Shawn.
^ permalink raw reply
* Re: GIT on MinGW, with tcltk for gitk
From: Aaron Gray @ 2007-05-27 21:39 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <00b901c7a0a5$77983420$0200a8c0@AMD2500>
>> Aaron Gray escreveu:
>>
>>> C:\Work\test>git init
>>> warning: templates not found C:/Program Files/Git/usr/bin@template_dir@
>>> Initialized empty Git repository in .git/
>>>
>>> Aaron
>>
>> Thanks for the report. Can you try again with 1.5.2-7 ? It should be
>> available
>> in a few minutes.
>
> Okay, I'm up for all the testing thats needed. Just dont know the
> territory that well though, as I am a Windozer :)
git init appears to work fine now, the template path is found.
git clone or git-clone is still not working.
'git clone' just gives a list of git's commands.
git-clone gives usual :-
C:\Work\test2>git-clone git://git.kernel.org/pub/scm/git/git.git
'git-clone' is not recognized as an internal or external command,
operable program or batch file.
>> Also, can you tell me if gitk.bat works for you?
>
> Okay, I just type 'gitk' ?
C:\Work>gitk
'"C:\Program Files\Git\usr\bin\wish.exe"' is not recognized as an internal
or external command, operable program or batch file.
Theres a file called 'wish84.exe' under 'C:\Program Files\Git\usr\bin', but
no wish.exe.
Aaron
Aaron
^ permalink raw reply
* Re: [PATCH 1/3] Lazily open pack index files on demand
From: Shawn O. Pearce @ 2007-05-27 21:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Dana How, Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.99.0705271110550.3366@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Sat, 26 May 2007, Shawn O. Pearce wrote:
>
> > Dana How <danahow@gmail.com> wrote:
> > > Shawn: When I first saw the index-loading code, my first
> > > thought was that all the index tables should be
> > > merged (easy since sorted) so callers only need to do one search.
>
> There is also the question of memory footprint. If you have a global
> index, then for each object you need to have a tupple containing SHA1 +
> pack offset + reference to corresponding pack. Right now we only need
> SHA1 + pack offset.
I'm about half-way through a super-index implementation. Right now
the super-index is defined to be just one index file per repository
(objects/pack/super.index) with a format that looks like the
following:
header:
uint32_t sdx_signature ('PSDX')
uint32_t sdx_version (1)
uint16_t sdx_packs
uint8_t sdx_prefix_len;
uint8_t __reserved;
pack table:
/* SHA-1 of each pack's sorted SHA-1 object list */
unsigned char pack_sha1[20][sdx_packs];
fan-out table:
/* This is the standard fan-out also used in a tOc/.idx */
uint32_t fan_out[256];
records:
unsigned char prefix[hdr.sdx_prefix_len - 1];
int8_t splits[hdr.sdx_packs];
trailer:
unsigned char sha1_of_the_above[20];
I build the super-index by merging the .idx of all available
packfiles; since they are already sorted the merge is obviously
quite trivial.
The sdx_prefix_len field is initialized to something that gives a
reasonably unique object name; e.g. in git.git an sdx_prefix_len
of 3 or 4 gets pretty good at narrowing the set of objects down
very small. The idea here is that the sdx_prefix_len should be
almost the unique abbreviation length for this repository.
We store 1 less byte of the prefix in the record because of the
fan-out table already accounting for the first byte of the prefix.
The splits array contains a single signed integer for each packfile;
if the integer is 0 then that packfile does not contain any object
that starts with that corresponding prefix. In such a case we
can completely avoid looking at that corresponding packfile.
With my lazy index loading change, I may not even need to open
that index. ;-)
If the splits array entry is non-zero and is negative, its the number
of times we need to halve down (towards 'lo') to get to entries
that start with this prefix and that are in that packfile's fan-out
table entry range. If its positive its the number of times we have
to halve up (towards 'hi'). This way we can jump more directly to
the relevant index records and avoid redoing binary search work we
have already accomplished in the super index.
So we can generally build super index records at a cost of 3 or
4 bytes + sdx_packs. We can also determine which packfile(s) we
need to scan quite quickly, and we can jump further into the part
of the index avoiding a number of expensive hashcmp() calls. It
may actually be a good savings at runtime, well worth the slightly
higher memory footprint.
My testing is not yet complete, so I cannot offer any hard numbers
against any interesting/common data sets...
> BTW I think the Newton-Raphson based index lookup approach should be
> revived at some point.
That doesn't help with 10 packfiles though, does it?
--
Shawn.
^ permalink raw reply
* Re: GIT on MinGW, with tcltk for gitk
From: Han-Wen Nienhuys @ 2007-05-27 21:55 UTC (permalink / raw)
To: Aaron Gray; +Cc: git
In-Reply-To: <00c401c7a0a7$8a5690a0$0200a8c0@AMD2500>
2007/5/27, Aaron Gray <angray@beeb.net>:
> '"C:\Program Files\Git\usr\bin\wish.exe"' is not recognized as an internal
> or external command, operable program or batch file.
>
> Theres a file called 'wish84.exe' under 'C:\Program Files\Git\usr\bin', but
> no wish.exe.
can you edit this .bat to say wish84.exe iso. wish.exe ?
thnks,
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: GIT on MinGW, with tcltk for gitk
From: Aaron Gray @ 2007-05-27 22:22 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <f329bf540705271455m4c0f5a55v14b9a8cc6bd7778d@mail.gmail.com>
> 2007/5/27, Aaron Gray <angray@beeb.net>:
>
>> '"C:\Program Files\Git\usr\bin\wish.exe"' is not recognized as an
>> internal
>> or external command, operable program or batch file.
>>
>> Theres a file called 'wish84.exe' under 'C:\Program Files\Git\usr\bin',
>> but
>> no wish.exe.
>
> can you edit this .bat to say wish84.exe iso. wish.exe ?
Getting message box saying :-
child process exited abnormally
while executing
"close $refd"
(proceedure "readrefs" line 47)
invoked from within
"readrefs"
(file "C:\Program Files\Git\usr\bin\gitk line 6369)
:(
Aaron
^ permalink raw reply
* Re: GIT on MinGW, with tcltk for gitk
From: Han-Wen Nienhuys @ 2007-05-27 22:22 UTC (permalink / raw)
To: git
In-Reply-To: <00c401c7a0a7$8a5690a0$0200a8c0@AMD2500>
Aaron Gray escreveu:
>>> Aaron Gray escreveu:
>>>
>>>> C:\Work\test>git init
>>>> warning: templates not found C:/Program Files/Git/usr/bin@template_dir@
>>>> Initialized empty Git repository in .git/
>>>>
>>>> Aaron
>>>
>>> Thanks for the report. Can you try again with 1.5.2-7 ? It should be
>>> available
>>> in a few minutes.
>>
>> Okay, I'm up for all the testing thats needed. Just dont know the
>> territory that well though, as I am a Windozer :)
>
> git init appears to work fine now, the template path is found.
>
> git clone or git-clone is still not working.
>
clone is a shell script. None of the shell scripts work; you'll have
to install msys bash yourself for now.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: GIT on MinGW, with tcltk for gitk
From: Han-Wen Nienhuys @ 2007-05-27 22:28 UTC (permalink / raw)
To: Aaron Gray; +Cc: git
In-Reply-To: <00ef01c7a0ad$78508e00$0200a8c0@AMD2500>
Aaron Gray escreveu:
>>>
>>> Theres a file called 'wish84.exe' under 'C:\Program
>>> Files\Git\usr\bin', but
>>> no wish.exe.
>>
>> can you edit this .bat to say wish84.exe iso. wish.exe ?
>
> Getting message box saying :-
>
> child process exited abnormally
> while executing
> "close $refd"
> (proceedure "readrefs" line 47)
> invoked from within
> "readrefs"
> (file "C:\Program Files\Git\usr\bin\gitk line 6369)
>
> :(
It seems that tcltk was executed; Unfortunately, it does work
flawlessly under wine, so there is little I can do. I invite windows
experts to have a closer look.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: GIT on MinGW - No symbolic links support
From: Aaron Gray @ 2007-05-27 22:56 UTC (permalink / raw)
To: hanwen, git
In-Reply-To: <465A061C.7010803@xs4all.nl>
Bit of a dampener on GIT on MinGW :-
$ git clone git://git.kernel.org/pub/scm/git/git.git
Initialized empty Git repository in C:/MSYS/src/git/.git/
error: git-checkout-index: unable to create symlink RelNotes
(Function not implemented)
No Symbolic links !
There are symbolic links provided by Windows by SFU (Services For Unix)
apparently.
Aaron
^ permalink raw reply
* Re: [PATCH] Fix git-svn to handle svn not reporting the md5sum of a file, and test.
From: Eric Wong @ 2007-05-27 23:04 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: James Y Knight, git, Junio C Hamano
In-Reply-To: <4659DBC8.2000105@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> wrote:
> Eric Wong wrote:
> > A Large Angry SCM <gitzilla@gmail.com> wrote:
> >> James Y Knight wrote:
> >>> ---
> >>> git-svn.perl | 2 +-
> >>> t/t9112-git-svn-md5less-file.sh | 45
> >>> +++++++++++++++++++++++++++++++++++++++
> >>> 2 files changed, 46 insertions(+), 1 deletions(-)
> >>> create mode 100755 t/t9112-git-svn-md5less-file.sh
> >> [...]
> >>
> >> The new test fails here (Suse 9.3 fully patched) w/ the following:
> >>
> >> *** t9112-git-svn-md5less-file.sh ***
> >> * ok 1: load svn dumpfile
> >> * ok 2: initialize git-svn
> >> * FAIL 3: fetch revisions from svn
> >> git-svn fetch
> >> * failed 1 among 3 test(s)
> >> make[1]: *** [t9112-git-svn-md5less-file.sh] Error 1
> >
> > I can't reproduce it here (on Debian Etch, SVN 1.4.2). Can you run with
> > the test with the -v switch? Thanks.
> >
>
>
> ~/GIT/git/t> sh ./t9112-git-svn-md5less-file.sh -v
> * expecting success: svnadmin load /home/test/GIT/git/t/trash/svnrepo <
> dumpfile.svn
> <<< Started new transaction, based on original revision 1
> * adding path : md5less-file ... done.
>
> ------- Committed revision 1 >>>
>
> * ok 1: load svn dumpfile
>
> * expecting success: git-svn init file:///home/test/GIT/git/t/trash/svnrepo
> * ok 2: initialize git-svn
>
> * expecting success: git-svn fetch
> ./test-lib.sh: line 141: 8163 Segmentation fault git-svn fetch
> * FAIL 3: fetch revisions from svn
> git-svn fetch
>
> * failed 1 among 3 test(s)
> ~/GIT/git/t>
>
>
> And here is the failing part of the test using sh -x:
>
> + test_expect_success 'fetch revisions from svn' 'git-svn fetch'
> + test 2 = 2
> + test_skip 'fetch revisions from svn' 'git-svn fetch'
> ++ expr ././t9112-git-svn-md5less-file.sh : '.*/\(t[0-9]*\)-[^/]*$'
> + this_test=t9112
> ++ expr 2 + 1
> + this_test=t9112.3
> + to_skip=
> + case "$to_skip" in
> + false
> + say 'expecting success: git-svn fetch'
> + echo '* expecting success: git-svn fetch'
> * expecting success: git-svn fetch
> + test_run_ 'git-svn fetch'
> + eval 'git-svn fetch'
> ++ git-svn fetch
> ./test-lib.sh: line 141: 8276 Segmentation fault git-svn fetch
> + eval_ret=139
> + return 0
> + '[' 0 = 0 -a 139 = 0 ']'
> + test_failure_ 'fetch revisions from svn' 'git-svn fetch'
> ++ expr 2 + 1
> + test_count=3
> ++ expr 0 + 1
> + test_failure=1
> + say 'FAIL 3: fetch revisions from svn'
> + echo '* FAIL 3: fetch revisions from svn'
> * FAIL 3: fetch revisions from svn
> + shift
> + echo 'git-svn fetch'
> + sed -e 's/^/ /'
> git-svn fetch
> + test '' = ''
> + echo ''
>
> This began after the 18bece4..99b5a79 update to master. Prior to that
> the svn tests were passing.
Thanks.
I'm definitely not able to reproduce this here, and I'm sure Junio
wouldn't have pushed out if he could, either... Which versions of SVN
and Perl (MD5) do you have?
A backtrace with debugging symbols could be helpful if the below
stab in the dark doesn't work out:
Maybe there's an off chance that the MD5 implementation you're using
can't handle zero-sized files?
Junio: can you apply the following patch regardless of whether or not it
fixes this issue? It just makes more sense, thanks.
>From 3229470be27589a0428994475b0a597cc549cf78 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Sun, 27 May 2007 15:59:01 -0700
Subject: [PATCH] git-svn: avoid md5 calculation entirely if SVN doesn't provide one
There's no point in calculating an MD5 if we're not going to use
it. We'll also avoid the possibility of there being a bug in the
Perl MD5 library not being able to handle zero-sized files.
This is a followup to 20b3d206acbbb042c7ad5f42d36ff8d036a538c5,
which allows us to track repositories that do not provide MD5
checksums.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index eeaeb2d..58f7dd0 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2472,12 +2472,16 @@ sub close_file {
my $hash;
my $path = $self->git_path($fb->{path});
if (my $fh = $fb->{fh}) {
- seek($fh, 0, 0) or croak $!;
- my $md5 = Digest::MD5->new;
- $md5->addfile($fh);
- my $got = $md5->hexdigest;
- die "Checksum mismatch: $path\n",
- "expected: $exp\n got: $got\n" if (defined $exp && $got ne $exp);
+ if (defined $exp) {
+ seek($fh, 0, 0) or croak $!;
+ my $md5 = Digest::MD5->new;
+ $md5->addfile($fh);
+ my $got = $md5->hexdigest;
+ if ($got ne $exp) {
+ die "Checksum mismatch: $path\n",
+ "expected: $exp\n got: $got\n";
+ }
+ }
sysseek($fh, 0, 0) or croak $!;
if ($fb->{mode_b} == 120000) {
sysread($fh, my $buf, 5) == 5 or croak $!;
--
Eric Wong
^ permalink raw reply related
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