* Re: [BUG] git-svn dcommit fails (connection closed unexpectedly)
From: Eric Wong @ 2007-05-13 17:17 UTC (permalink / raw)
To: git
In-Reply-To: <vpq7irfengj.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Hi,
>
> I'm using git-svn, which usually works fine, but I occasionally get
> this:
>
> $ git-svn dcommit
> A file1
> A file2
> Network connection closed unexpectedly: Connection closed unexpectedly at /path/to/git-svn line 401
> $
>
> The failure seems to depend on the commit's I'm pushing, since this is
> reproducible when running several times "dcommit" for the same commit,
> but the same command also usually works fine on the same repositories
> (same git repo, same svn target).
>
> The svn repository is accessed with svn+ssh://user@machine/path/.
Does the patch in
http://permalink.gmane.org/gmane.comp.version-control.git/47126
help?
If so, I'm not sure why it should be failing sometimes and not
all the time. If your local username the same as the username
you're using for svn it shouldn't fail for the reason that patch
above is needed.
Using the native svn or svn+ssh protocol is definitely flakier in my
experience, and there are still known issues with connections closing
during *fetch*. dcommit is actually a lot more straightforward
as it only connects once, whereas fetch can reconnect to different
parts of the repo for --follow-parent.
> exporting the patch, applying it to an svn checkout, and "svn commit"
> works fine.
>
> Let me know if I can provide any other usefull information for
> debugging.
>
> Thanks,
>
> Debian etch (stable)
> Reproducible with both git 1.5.1.1 and the latest from git:
>
> $ git-svn --version
> git-svn version 1.5.2.rc3.3.ge347 (svn 1.4.2)
Which version of SVN is running on the server?
--
Eric Wong
^ permalink raw reply
* [PATCH] git-svn: don't attempt to minimize URLs by default
From: Eric Wong @ 2007-05-13 16:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20070508193455.GA14602@muzzle>
For tracking branches and tags, git-svn prefers to connect
to the root of the repository or at least the level that
houses branches and tags as well as trunk. However, users
that are accustomed to tracking a single directory have
no use for this feature.
As pointed out by Junio, users may not have permissions to
connect to connect to a higher-level path in the repository.
While the current minimize_url() function detects lack of
permissions to certain paths _after_ successful logins, it
cannot effectively determine if it is trying to access a
login-only portion of a repo when the user expects to
connect to a part where anonymous access is allowed.
For people used to the git-svnimport switches of
--trunk, --tags, --branches, they'll already pass the
repository root (or root+subdirectory), so minimize URL
isn't of too much use to them, either.
For people *not* used to git-svnimport, git-svn also
supports:
git svn init --minimize-url \
--trunk http://repository-root/foo/trunk \
--branches http://repository-root/foo/branches \
--tags http://repository-root/foo/tags
And this is where the new --minimize-url command-line switch
comes in to allow for this behavior to continue working.
---
git-svn.perl | 5 +++--
t/t9100-git-svn-basic.sh | 2 +-
t/t9104-git-svn-follow-parent.sh | 13 +++++++------
t/t9105-git-svn-commit-diff.sh | 2 +-
t/t9110-git-svn-use-svm-props.sh | 7 ++++---
t/t9111-git-svn-use-svnsync-props.sh | 6 +++---
6 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 5352470..e38811a 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -80,6 +80,7 @@ my %icv;
my %init_opts = ( 'template=s' => \$_template, 'shared:s' => \$_shared,
'trunk|T=s' => \$_trunk, 'tags|t=s' => \$_tags,
'branches|b=s' => \$_branches, 'prefix=s' => \$_prefix,
+ 'minimize-url|m' => \$Git::SVN::_minimize_url,
'no-metadata' => sub { $icv{noMetadata} = 1 },
'use-svm-props' => sub { $icv{useSvmProps} = 1 },
'use-svnsync-props' => sub { $icv{useSvnsyncProps} = 1 },
@@ -820,7 +821,7 @@ use strict;
use warnings;
use vars qw/$default_repo_id $default_ref_id $_no_metadata $_follow_parent
$_repack $_repack_flags $_use_svm_props $_head
- $_use_svnsync_props $no_reuse_existing/;
+ $_use_svnsync_props $no_reuse_existing $_minimize_url/;
use Carp qw/croak/;
use File::Path qw/mkpath/;
use File::Copy qw/copy/;
@@ -1037,7 +1038,7 @@ sub init_remote_config {
"[svn-remote \"$existing\"]\n";
}
$self->{repo_id} = $existing;
- } else {
+ } elsif ($_minimize_url) {
my $min_url = Git::SVN::Ra->new($url)->minimize_url;
$existing = find_existing_remote($min_url, $r);
if ($existing) {
diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
index eb628fe..70c3669 100755
--- a/t/t9100-git-svn-basic.sh
+++ b/t/t9100-git-svn-basic.sh
@@ -229,7 +229,7 @@ test_expect_failure 'exit if init-ing a would clobber a URL' "
test_expect_success \
'init allows us to connect to another directory in the same repo' "
- git-svn init -i bar $svnrepo/bar &&
+ git-svn init --minimize-url -i bar $svnrepo/bar &&
git config --get svn-remote.svn.fetch \
'^bar:refs/remotes/bar$' &&
git config --get svn-remote.svn.fetch \
diff --git a/t/t9104-git-svn-follow-parent.sh b/t/t9104-git-svn-follow-parent.sh
index bd4f366..35aa45c 100755
--- a/t/t9104-git-svn-follow-parent.sh
+++ b/t/t9104-git-svn-follow-parent.sh
@@ -28,7 +28,7 @@ test_expect_success 'initialize repo' "
"
test_expect_success 'init and fetch a moved directory' "
- git-svn init -i thunk $svnrepo/thunk &&
+ git-svn init --minimize-url -i thunk $svnrepo/thunk &&
git-svn fetch -i thunk &&
test \"\`git-rev-parse --verify refs/remotes/thunk@2\`\" \
= \"\`git-rev-parse --verify refs/remotes/thunk~1\`\" &&
@@ -68,7 +68,8 @@ test_expect_success 'follow larger parent' "
echo hi > import/trunk/thunk/bump/thud/file &&
svn import -m 'import a larger parent' import $svnrepo/larger-parent &&
svn cp -m 'hi' $svnrepo/larger-parent $svnrepo/another-larger &&
- git-svn init -i larger $svnrepo/another-larger/trunk/thunk/bump/thud &&
+ git-svn init --minimize-url -i larger \
+ $svnrepo/another-larger/trunk/thunk/bump/thud &&
git-svn fetch -i larger &&
git-rev-parse --verify refs/remotes/larger &&
git-rev-parse --verify \
@@ -90,14 +91,14 @@ test_expect_success 'follow higher-level parent' "
cd ..
svn mkdir -m 'new glob at top level' $svnrepo/glob &&
svn mv -m 'move blob down a level' $svnrepo/blob $svnrepo/glob/blob &&
- git-svn init -i blob $svnrepo/glob/blob &&
+ git-svn init --minimize-url -i blob $svnrepo/glob/blob &&
git-svn fetch -i blob
"
test_expect_success 'follow deleted directory' "
svn mv -m 'bye!' $svnrepo/glob/blob/hi $svnrepo/glob/blob/bye &&
svn rm -m 'remove glob' $svnrepo/glob &&
- git-svn init -i glob $svnrepo/glob &&
+ git-svn init --minimize-url -i glob $svnrepo/glob &&
git-svn fetch -i glob &&
test \"\`git cat-file blob refs/remotes/glob:blob/bye\`\" = hi &&
test \"\`git ls-tree refs/remotes/glob | wc -l \`\" -eq 1
@@ -127,7 +128,7 @@ test_expect_success 'follow-parent avoids deleting relevant info' "
poke native/t/c.t &&
svn commit -m 'reorg test' &&
cd .. &&
- git-svn init -i r9270-t \
+ git-svn init --minimize-url -i r9270-t \
$svnrepo/r9270/trunk/subversion/bindings/swig/perl/native/t &&
git-svn fetch -i r9270-t &&
test \`git rev-list r9270-t | wc -l\` -eq 2 &&
@@ -137,7 +138,7 @@ test_expect_success 'follow-parent avoids deleting relevant info' "
test_expect_success "track initial change if it was only made to parent" "
svn cp -m 'wheee!' $svnrepo/r9270/trunk $svnrepo/r9270/drunk &&
- git-svn init -i r9270-d \
+ git-svn init --minimize-url -i r9270-d \
$svnrepo/r9270/drunk/subversion/bindings/swig/perl/native/t &&
git-svn fetch -i r9270-d &&
test \`git rev-list r9270-d | wc -l\` -eq 3 &&
diff --git a/t/t9105-git-svn-commit-diff.sh b/t/t9105-git-svn-commit-diff.sh
index c668dd1..318e172 100755
--- a/t/t9105-git-svn-commit-diff.sh
+++ b/t/t9105-git-svn-commit-diff.sh
@@ -33,7 +33,7 @@ test_expect_success 'test the commit-diff command' "
test_expect_success 'commit-diff to a sub-directory (with git-svn config)' "
svn import -m 'sub-directory' import $svnrepo/subdir &&
- git-svn init $svnrepo/subdir &&
+ git-svn init --minimize-url $svnrepo/subdir &&
git-svn fetch &&
git-svn commit-diff -r3 '$prev' '$head' &&
svn cat $svnrepo/subdir/readme > readme.2 &&
diff --git a/t/t9110-git-svn-use-svm-props.sh b/t/t9110-git-svn-use-svm-props.sh
index 9db0d8f..59e17f2 100755
--- a/t/t9110-git-svn-use-svm-props.sh
+++ b/t/t9110-git-svn-use-svm-props.sh
@@ -9,9 +9,10 @@ test_description='git-svn useSvmProps test'
test_expect_success 'load svm repo' "
svnadmin load -q $rawsvnrepo < ../t9110/svm.dump &&
- git-svn init -R arr -i bar $svnrepo/mirror/arr &&
- git-svn init -R argh -i dir $svnrepo/mirror/argh &&
- git-svn init -R argh -i e $svnrepo/mirror/argh/a/b/c/d/e &&
+ git-svn init --minimize-url -R arr -i bar $svnrepo/mirror/arr &&
+ git-svn init --minimize-url -R argh -i dir $svnrepo/mirror/argh &&
+ git-svn init --minimize-url -R argh -i e \
+ $svnrepo/mirror/argh/a/b/c/d/e &&
git-config svn.useSvmProps true &&
git-svn fetch --all
"
diff --git a/t/t9111-git-svn-use-svnsync-props.sh b/t/t9111-git-svn-use-svnsync-props.sh
index 483d7f8..e523214 100755
--- a/t/t9111-git-svn-use-svnsync-props.sh
+++ b/t/t9111-git-svn-use-svnsync-props.sh
@@ -9,9 +9,9 @@ test_description='git-svn useSvnsyncProps test'
test_expect_success 'load svnsync repo' "
svnadmin load -q $rawsvnrepo < ../t9111/svnsync.dump &&
- git-svn init -R arr -i bar $svnrepo/bar &&
- git-svn init -R argh -i dir $svnrepo/dir &&
- git-svn init -R argh -i e $svnrepo/dir/a/b/c/d/e &&
+ git-svn init --minimize-url -R arr -i bar $svnrepo/bar &&
+ git-svn init --minimize-url -R argh -i dir $svnrepo/dir &&
+ git-svn init --minimize-url -R argh -i e $svnrepo/dir/a/b/c/d/e &&
git-config svn.useSvnsyncProps true &&
git-svn fetch --all
"
--
Eric Wong
^ permalink raw reply related
* Re: suggestions for gitweb
From: Lars Hjemli @ 2007-05-13 16:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Michael Niedermayer, Aaron Gray
In-Reply-To: <f25mic$1b1$2@sea.gmane.org>
On 5/13/07, Jakub Narebski <jnareb@gmail.com> wrote:
> Aaron Gray wrote:
>
> >>> * the history/log pages could contain some statistics for the commits
> >>> like the number of files changed and lines added/removed
> >>
> >> Probably.
> >>
> >> The three last items should be relatively easy, if somebody is
> >> interested. Pasky, Jakub, what do you think?
> >
> > I would like to see lines of code and file sizes too.
>
> Diff statistics for difftree / whatchanged, or diff shortstat is a bit
> costly, as it needs to generate and examine diff, and not only compare
> trees. Besides --numstat doesn't support renames well now, but that
> might not be an obstacle.
>
> Lines of code and file sizes: file size needs additional invocation
> per each file for gitweb; it would be easier for cgit. Costly! Counting
> LOC is even more costly
I've implemented number of files/lines changed in cgit's log view and
pushed it to http://hjemli.net/git/
It does consume some cpu (especially on the linux-2.6 repo), but it's
not terribly bad (and the caching helps out). But I felt like changing
the number of commits per page to 50, so I added a knob for this in
the config file while at it.
I'll try to get a proper diffstat on the commit page + file history
via tree view next (filesize has always been part of cgits tree view
btw).
--
larsh
^ permalink raw reply
* [StGIT PATCH v3] Document patch syntax.
From: Yann Dirson @ 2007-05-13 14:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Acked-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
Documentation/stg.txt | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/Documentation/stg.txt b/Documentation/stg.txt
index af57c37..4f9d18e 100644
--- a/Documentation/stg.txt
+++ b/Documentation/stg.txt
@@ -51,6 +51,31 @@ Development branch::
In such a setup, not all commits on your branch need to be StGIT
patches; there may be regular GIT commits below your stack base.
+Patches
+~~~~~~~
+
+Many StGIT commands take references to StGIT patches as arguments.
+Patches in the stack are identified with short names, each of which
+must be unique in the stack.
+
+Patches in the current stack are just referred to by their name. Some
+commands allow you to specify a patch in another stack of the repository;
+this is done by suffixing the patch name with an '@' sign followed by the
+branch name (eg. 'thispatch@otherbranch').
+
+A number of positions in the stack related to the patch are also
+accessible through '//' suffixes. For example, 'patch//top' is
+equivalent to 'patch', and 'patch//bottom' refers to the commit below
+'patch' (i.e. the patch below, or the stack base if this is the
+bottom-most patch). Similarly '//top.old' and '//bottom.old'
+refer to the previous version of the patch (before the last
+stglink:push[] or stglink:refresh[] operation). When referring to the
+current patch, its name can be omitted (eg. 'currentpatch//bottom.old'
+can be abbreviated as 'bottom.old').
+
+If you need to pass a given StGIT reference to a git command,
+stglink:id[] will convert it to a git commit id.
+
OPTIONS
-------
^ permalink raw reply related
* Re: [StGIT PATCH v2] Document patch syntax.
From: Karl Hasselström @ 2007-05-13 13:58 UTC (permalink / raw)
To: Yann Dirson; +Cc: Catalin Marinas, git
In-Reply-To: <20070513130354.GG16903@nan92-1-81-57-214-146.fbx.proxad.net>
On 2007-05-13 15:03:54 +0200, Yann Dirson wrote:
> My LC_CTYPE is "french", which is an iso8859-1 locale.
I bit the bullet a year or so ago and switched over to a utf8 locale.
It's becoming increasingly hard to use non-utf8 locales: Gnome wants
utf8, Ubuntu comes with only utf8 locales installed by default, etc. I
figured that it had become less work to convert than to stay with
latin1 (but I still have a few relics, such as the system I'm writing
this mail on).
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Possible bug in git-svn
From: Martin Eisenhardt @ 2007-05-13 13:22 UTC (permalink / raw)
To: Eric Wong; +Cc: Adam Roben, Git Mailing List
In-Reply-To: <20070512214035.GA18560@muzzle>
[-- Attachment #1: Type: text/plain, Size: 304 bytes --]
Hi Eric,
hi list,
On Saturday 12 May 2007 23:40:35 Eric Wong wrote:
> Thanks for the bug report. I haven't tested the patch below, so
> let me know if it works:
Works like a charm for me, as others have already pointed out. Thanks you for
the quick patch.
Kind regards
Martin Eisenhardt
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [StGIT PATCH v2] Document patch syntax.
From: Yann Dirson @ 2007-05-13 13:03 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20070512204352.GE28039@diana.vm.bytemark.co.uk>
On Sat, May 12, 2007 at 10:43:52PM +0200, Karl Hasselström wrote:
> On 2007-05-12 20:59:30 +0200, Yann Dirson wrote:
>
> > Acked-by: Karl Hasselstr?m <kha@treskal.com>
>
> Your mail headers say
>
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: QUOTED-PRINTABLE
>
> but the body contains
>
> Acked-by: Karl Hasselstr=F6m <kha@treskal.com>
>
> which is QP-encoded latin1, not utf8. (It's an illegal utf8 byte
> sequence, which is why it showed up as a question mark in my MUA.)
Right, I have seen that in gitk as well. My LC_CTYPE is "french",
which is an iso8859-1 locale. I have not touched i18n.commitEncoding,
which should then default to utf-8. Shouldn't a conversion to utf8
have happenned ? Things may be made different from standard git,
since this commit was handled by stgit - we may have something to fix
here :)
> s/refered/referred/. I missed this the first time -- sorry.
OK
Jeff wrote:
>Karl's version is more correct (but your version might be used by many
>native speakers). The second half of the sentence is correct because
>'must' conjugates the same for singular and plural use; however, it
>might be more clear to say "...short name, each of which must be unique
>in the stack."
OK as well
Best regards,
--
Yann.
^ permalink raw reply
* Re: [PATCH] Make git compile with SUNs forte12 compiler
From: matthieu castet @ 2007-05-13 12:52 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git, junkio
In-Reply-To: <20070513103038.GC18546@cip.informatik.uni-erlangen.de>
[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]
Hi Thomas,
Thomas Glanzmann wrote:
> Hello,
>
> [ Junio please drop the patch, if you thought about putting it upstream ]
>
>> Did you understand what you did ?
>
> I do. But my objective wasn't get that function inline but get git to compile
> under forte12. However. After you pushed me in the right direction I read the
> compiler documentation and found a compiler option called "-features=no%extinl"
> which makes it possible to compile git as is using forte12.
What's strange with your compiler is that it seems to not take care of
the "static" keyword and thinks about an "extern inline".
Now it could be interesting to understand why.
Let's look at your error [1].
First it only complain about tree_entry_extract not tree_entry_len.
Let's see why ?
If you look in tree-walk.h and search for tree_entry_extract, you will see :
static inline const unsigned char *tree_entry_extract(struct tree_desc
*desc, const char **pathp, unsigned int *modep)
[...]
const unsigned char *tree_entry_extract(struct tree_desc *, const char
**, unsigned int *);
This is bad, tree_entry_extract is declared as static inline and as extern.
If you remove the "const unsigned char *tree_entry_extract(struct
tree_desc *, const char **, unsigned int *);", I bet everybody will be
happy and no need to extra option for the sun compiler. [2]
Matthieu
[1]
LINK git-convert-objects
ld: fatal: symbol `tree_entry_extract' is multiply-defined:
(file libgit.a(sha1_name.o) type=FUNC; file libgit.a(tree.o)
type=FUNC);
ld: fatal: symbol `tree_entry_extract' is multiply-defined:
(file libgit.a(sha1_name.o) type=FUNC; file
libgit.a(tree-walk.o) type=FUNC);
ld: fatal: File processing errors. No output written to git-convert-objects
[2] see attached patch
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 489 bytes --]
--- a/tree-walk.h 2007-05-13 14:51:01.451827585 +0200
+++ b/tree-walk.h 2007-05-13 14:51:07.450235889 +0200
@@ -27,7 +27,6 @@
void update_tree_entry(struct tree_desc *);
void init_tree_desc(struct tree_desc *desc, const void *buf, unsigned long size);
-const unsigned char *tree_entry_extract(struct tree_desc *, const char **, unsigned int *);
/* Helper function that does both of the above and returns true for success */
int tree_entry(struct tree_desc *, struct name_entry *);
^ permalink raw reply
* Re: RFD Use git for off-site backups
From: Jan Hudec @ 2007-05-13 12:34 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20070513093417.GA18546@cip.informatik.uni-erlangen.de>
[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]
On Sun, May 13, 2007 at 11:34:17 +0200, Thomas Glanzmann wrote:
> I am thinking about using git for doing differential backups of a whole
> machines. And I would like to know what is necessary to obtain that. In
> such a scenario the machine to be backed up should have a local index
> file but sends its objects directly to the remote machine via git-via-ssh
> or git protocol. Is it possible to store extra information like extended
> attributes / acls in git? I don't care about named pipes, sockets and
> device files for the moment.
I don't actually think git is a good match for whole-machine backups. It's
strenghts are in distributedness and branching, but you don't need either of
those for large-scale backups (monitoring changes say in /etc is a different
thing -- git is sensible match there -- see http://www.isisetup.ch/).
I can suggest two solutions:
- Use CVS on the client (machine to back up) and git-cvsserver on the
server. You will probably be able to find some scripts that do backups to
CVS. On server you will still have git for digging in history. Git is also
very space efficient.
CVS does not cache any data on the client. It only keeps metadata to
detect which files were modified. Therefore it will have minimal overhead
in storage, but needs to transfer the modified files in their entirety.
- Use Subversion. There is summer of code project to create git-svnserver,
so you might be able to use git on the server-side in future with
subversion client too. But for backups you should not need any of the
version control features subversion does not have, so subversion should be
suitable.
Subversion stores copy of the previous revision on the client, so all data
under it's control will take twice as much space on client, but it will
only transfer deltas over the network.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] RPM spec: include files in technical/ to package.
From: Quy Tonthat @ 2007-05-13 11:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Not only that they are interesting to users, some of the
files are linked to by the included "Git User's Manual"
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
---
git.spec.in | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/git.spec.in b/git.spec.in
index 16148d4..3a45eb8 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -185,8 +185,13 @@ rm -rf $RPM_BUILD_ROOT
%{_datadir}/git-core/
%doc README COPYING Documentation/*.txt
%{!?_without_docs: %doc Documentation/*.html Documentation/howto}
+%{!?_without_docs: %doc Documentation/technical}
%changelog
+* Tue May 13 2007 Quy Tonthat <qtonthat@gmail.com>
+- Added lib files for git-gui
+- Added Documentation/technical (As needed by Git Users Manual)
+
* Tue May 8 2007 Quy Tonthat <qtonthat@gmail.com>
- Added howto files
--
1.5.2.rc3.1q
^ permalink raw reply related
* [PATCH] Remove protoype for inline function so that forte12 doesn't choke on it
From: Thomas Glanzmann @ 2007-05-13 11:22 UTC (permalink / raw)
To: git
Signed-off-by: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
---
tree-walk.h | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/tree-walk.h b/tree-walk.h
index 43458cf..ee747ab 100644
--- a/tree-walk.h
+++ b/tree-walk.h
@@ -27,7 +27,6 @@ static inline int tree_entry_len(const char *name, const unsigned char *sha1)
void update_tree_entry(struct tree_desc *);
void init_tree_desc(struct tree_desc *desc, const void *buf, unsigned long size);
-const unsigned char *tree_entry_extract(struct tree_desc *, const char **, unsigned int *);
/* Helper function that does both of the above and returns true for success */
int tree_entry(struct tree_desc *, struct name_entry *);
--
1.5.2.rc1.9.g6644
^ permalink raw reply related
* Re: RFD Use git for off-site backups
From: Thomas Glanzmann @ 2007-05-13 11:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: GIT
In-Reply-To: <Pine.LNX.4.64.0705131251370.6410@racer.site>
Hello,
> I think that this setup (have objects remotely) will kill performance
> pretty quickly. You have to compare to other blobs in order to find
> reasonable deltas...
so true. I thought about that myself just after I sent the eMail.
> There has been talk about pre-commit scripts which put this
> information into a file, and a post-checkout script to resurrect these
> metadata, but I haven't seen functional versions of these scripts yet.
I thought there is a way to add information without loosing compability
with current git versions. But maybe I am just mistaken.
Thomas
^ permalink raw reply
* Re: RFD Use git for off-site backups
From: Johannes Schindelin @ 2007-05-13 11:16 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20070513093417.GA18546@cip.informatik.uni-erlangen.de>
Hi,
On Sun, 13 May 2007, Thomas Glanzmann wrote:
> I am thinking about using git for doing differential backups of a whole
> machines. And I would like to know what is necessary to obtain that. In
> such a scenario the machine to be backed up should have a local index
> file but sends its objects directly to the remote machine via git-via-ssh
> or git protocol.
I think that this setup (have objects remotely) will kill performance
pretty quickly. You have to compare to other blobs in order to find
reasonable deltas...
> Is it possible to store extra information like extended attributes /
> acls in git?
There has been talk about pre-commit scripts which put this information
into a file, and a post-checkout script to resurrect these metadata, but I
haven't seen functional versions of these scripts yet.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make git compile with SUNs forte12 compiler
From: Thomas Glanzmann @ 2007-05-13 10:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705131238420.6410@racer.site>
Hello,
> A better solution (IMHO) is to make it "static inline".
they're already static inline. Maybe the sun compiler got confused by
the prototype which is a few lines below and missing the "static". Let
me check ... actually that's it. I make a patch ready.
Thomas
^ permalink raw reply
* Re: [BUG] git config gets confused
From: Johannes Schindelin @ 2007-05-13 10:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Frank Lichtenheld, git
In-Reply-To: <7vtzuhtjj6.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 12 May 2007, Junio C Hamano wrote:
> Oh, boy.
>
> Why am I not surprised by another bug in config writer?
>
> Dscho, does this look good?
Yes, it does. This part of the config writer dates slightly prior to our
allowing hierarchical section names, which explains this bug, methinks.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make git compile with SUNs forte12 compiler
From: Johannes Schindelin @ 2007-05-13 10:39 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git
In-Reply-To: <11790057101792-git-send-email-sithglan@stud.uni-erlangen.de>
Hi,
On Sat, 12 May 2007, Thomas Glanzmann wrote:
> This patch moves two inline functions from a header file to the
> corresponding c file.
I think that it is wrong to move inline functions out of a header file.
Many C compilers will not be able to inline it then.
A better solution (IMHO) is to make it "static inline".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/3] Fix assorted white space damage
From: Johannes Schindelin @ 2007-05-13 10:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Costalba, Git Mailing List
In-Reply-To: <7vzm49ts2f.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 12 May 2007, Junio C Hamano wrote:
> In the above I explicitly "saved" t/ because we have some test vectors
> that need to have trailing whitespaces.
AFAICT the documentation has trailing whitespace also, to indicate that
the paragraph does not end here. Correct me if I'm wrong, and these
trailing whitespaces are not necessary.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make git compile with SUNs forte12 compiler
From: Thomas Glanzmann @ 2007-05-13 10:30 UTC (permalink / raw)
To: Matthieu CASTET; +Cc: git, junkio
In-Reply-To: <pan.2007.05.13.09.47.32@free.fr>
Hello,
[ Junio please drop the patch, if you thought about putting it upstream ]
> Did you understand what you did ?
I do. But my objective wasn't get that function inline but get git to compile
under forte12. However. After you pushed me in the right direction I read the
compiler documentation and found a compiler option called "-features=no%extinl"
which makes it possible to compile git as is using forte12.
So if anyone tries to build git for Solaris using forte12 try this
commandline:
export PATH="/opt/forte12/x86/SUNWspro/bin:/usr/ccs/bin:/usr/bin:/usr/openwin/bin"
/opt/csw/bin/gmake \
CFLAGS='-O -features=no%extinl' \
CC=/opt/forte12/x86/SUNWspro/bin/cc \
DESTDIR=/var/tmp/sithglan-pkg/git-1.5.1.4-buildroot \
ETC_GITCONFIG=/etc/gitconfig \
INSTALL=/opt/csw/bin/ginstall \
NO_CURL=1 \
NO_EXPAT=1 \
NO_ICONV=1 \
NO_OPENSSL=1 \
TAR=/opt/csw/bin/gtar \
mandir=/usr/share/man \
prefix=/usr \
install
Thanks,
Thomas
^ permalink raw reply
* Re: [PATCH] Make git compile with SUNs forte12 compiler
From: Matthieu CASTET @ 2007-05-13 9:47 UTC (permalink / raw)
To: git
In-Reply-To: <11790057101792-git-send-email-sithglan@stud.uni-erlangen.de>
Hi,
On Sat, 12 May 2007 23:35:10 +0200, Thomas Glanzmann wrote:
> This patch moves two inline functions from a header file to the
> corresponding c file. Otherwise forte12 refuses to compile git with the
> following error:
>
Did you understand what you did ?
You can't put a inline global function in a *.c : you need to put it in
the header so that when parsing other files the compiler finds the
definition and can inline it.
In your patch, you transform a static inline function to a global
function whith is not the same thing...
Matthieu
^ permalink raw reply
* git.or.cz IPv6
From: Thomas Glanzmann @ 2007-05-13 9:40 UTC (permalink / raw)
To: GIT; +Cc: pasky
Hello,
git.or.cz has an AAAA record but is not reachable via IPv6 which drives
me crazy because my IPv6 is working and my browser tries to connect
git.or.cz via IPv6 and falls back after a considerable amount of time.
So could someone please get IPv6 working at git.or.cz or delete the AAAA
record. Oh and the download link to
"http://git.kernel.org/pub/software/scm/git/" is broken.
Thomas
^ permalink raw reply
* RFD Use git for off-site backups
From: Thomas Glanzmann @ 2007-05-13 9:34 UTC (permalink / raw)
To: GIT
Hello,
I am thinking about using git for doing differential backups of a whole
machines. And I would like to know what is necessary to obtain that. In
such a scenario the machine to be backed up should have a local index
file but sends its objects directly to the remote machine via git-via-ssh
or git protocol. Is it possible to store extra information like extended
attributes / acls in git? I don't care about named pipes, sockets and
device files for the moment.
Thomas
^ permalink raw reply
* Re: [PATCH] Document patch syntax.
From: Jeff King @ 2007-05-13 8:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Karl Hasselström, Yann Dirson, Catalin Marinas, git
In-Reply-To: <7vodkpzwzj.fsf@assigned-by-dhcp.cox.net>
On Sat, May 12, 2007 at 12:02:24PM -0700, Junio C Hamano wrote:
> For tutorial/walkthru type of documentation, my usual preference
> is "we", not "you". "Now our little repository should be in
> this shape." "Let's change our Makefile to do a bit more."
> That sets the tone that a slightly more knowledgeable friend is
> helping the user by working together with him, instead of an
> expert talking to a stupid user from a high place, but that is a
> bit offtopic.
I like that, too, but I don't think "we're" following it very well. Try
grepping through git/Documentation.
-Peff
^ permalink raw reply
* Re: [PATCH] Document patch syntax.
From: Jeff King @ 2007-05-13 8:27 UTC (permalink / raw)
To: Yann Dirson; +Cc: Karl Hasselström, Catalin Marinas, git
In-Reply-To: <20070512143827.GE16903@nan92-1-81-57-214-146.fbx.proxad.net>
On Sat, May 12, 2007 at 04:38:27PM +0200, Yann Dirson wrote:
> > > +Patches in the stack are identified with a short name, which must be
> > > +unique in the stack.
> > s/a short name/short names/, maybe.
> Hm, not sure how that would play with the end of the sentence - any
> native english speaker with an opinion ?
Karl's version is more correct (but your version might be used by many
native speakers). The second half of the sentence is correct because
'must' conjugates the same for singular and plural use; however, it
might be more clear to say "...short name, each of which must be unique
in the stack."
> No strong opinion here. However, that makes me think we should
> probably use guideline for the docs - here comes the question of which
> convention to use when refering to the user. Do we address her
> directly ("you"), indirectly ("the user", "her" - don't remember where
> the "female user" use comes from, but we could maybe follow this),
> even more indirectly ("one"), or any other way ?
Most of the git docs already use direct address (just grep for 'you' in
Documentation). It's less formal, but it tends to read much more easily.
-Peff
^ permalink raw reply
* Re: Segmentation fault in git-svn
From: Eric Wong @ 2007-05-13 8:21 UTC (permalink / raw)
To: Steven Grimm, git; +Cc: Peter Baumann
In-Reply-To: <20070503123512.GA6500@xp.machine.xx>
Peter Baumann <waste.manager@gmx.de> wrote:
> On Mon, Apr 16, 2007 at 03:17:55PM -0700, Steven Grimm wrote:
> > I expect this is really a libsvn bug, but git-svn triggers it, so I'm hoping
> > someone else has run into and solved it, or at least that someone can
> > reproduce it.
> >
> > If I try to clone the "memcached" public repository with the command line
> >
> > git-svn clone --branches=branches --trunk=trunk
> > http://code.sixapart.com/svn/memcached
>
> I'm getting segfaults in git-svn, too.
>
> This command segfaults reproducably in r55 while running
>
> git svn clone svn://svn.berlios.de/vermont vermont \
> -T trunk -b branches -t tags
>
Both repositories seem to be cloning fine after the
patch here:
http://permalink.gmane.org/gmane.comp.version-control.git/47128
I really don't know what's going on with libsvn, either :(
--
Eric Wong
^ permalink raw reply
* [PATCH 2/2] git-svn: fix segfaults due to initial SVN pool being cleared
From: Eric Wong @ 2007-05-13 8:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <11790434841909-git-send-email-normalperson@yhbt.net>
Some parts of SVN always seem to use it, even if the SVN::Ra
object we're using is no longer used and we've created a new one
in its place. It's also true that only one SVN::Ra connection
can exist at once... Using SVN::Pool->new_default when the
SVN::Ra object is created doesn't seem to help very much,
either...
Hopefully this fixes all segfault problems users have been
experiencing over the past few months.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index ee69598..5352470 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2904,7 +2904,6 @@ sub new {
my ($class, $url) = @_;
$url =~ s!/+$!!;
return $RA if ($RA && $RA->{url} eq $url);
- $RA->{pool}->clear if $RA;
SVN::_Core::svn_config_ensure($config_dir, undef);
my ($baton, $callbacks) = SVN::Core::auth_open_helper([
--
1.5.2.rc3.18.gf0c86
^ 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