* Re: git guidance
From: Al Boldi @ 2007-11-29 5:27 UTC (permalink / raw)
To: linux-kernel; +Cc: git
In-Reply-To: <200711282130.12864.a1426z@gawab.com>
Jakub Narebski wrote:
> Al Boldi wrote:
> > Johannes Schindelin wrote:
> >> By that definition, no SCM, not even CVS, is transparent. Nothing
> >> short of unpacked directories of all versions (wasting a lot of disk
> >> space) would.
> >
> > Who said anything about unpacking?
> >
> > I'm talking about GIT transparently serving a Virtual Version Control
> > dir to be mounted on the client.
>
> Are you talking about something like (in alpha IIRC) gitfs?
>
> http://www.sfgoth.com/~mitch/linux/gitfs/
This looks like a good start.
> Besides, you can always use "git show <revision>:<file>". For example
> gitweb (and I think other web interfaces) can show any version of a file
> or a directory, accessing only repository.
Sure, browsing is the easy part, but Version Control starts when things
become writable.
Thanks for the link!
--
Al
^ permalink raw reply
* Re: [PATCH/RFC] Teach repack to optionally retain otherwise lost objects
From: Junio C Hamano @ 2007-11-29 6:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <Pine.LNX.4.64.0711290340470.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Besides, a completely different idea just struck me: before
> repacking, .git/objects/pack/* could be _hard linked_ to the
> forkee's object stores. Then nothing in git-repack's code
> needs to be changed.
>
> Oh, well. I just wasted 1.5 hours.
Your 1.5 hours was spent wisely to come up with that idea ;-).
To make sure I understand your idea correctly, the procedure to repack a
repository in a fork-friendly way is:
(1) find the project directly forked from you;
(2) hardlink all packs under your object store to their object store;
(3) repack -a -l and prune.
I think that would work as long as you do the above as a unit and handle
one repository at a time. Otherwise I think you risk losing necessary
objects when hierarchical forks are involved. E.g. if you have a
project X that has a fork Y which in turn has fork Z.
* Step 1 is run for X, Y and Z.
* Step 2 is run for Y and Z.
* Step 3 is run for Z.
At this point, Z is still borrowing objects from Y and X through Y, and
it will not keep objects it is borrowing from X through Y. Then if the
procedure is intermixed like this, a bad thing happens.
* Step 2 is run for X.
* Step 3 is run for Y.
* Step 3 is run for X.
Step 3 for Y would lose objects Y was borrowing from X that were not
used by Y itself. At this point, Z is still usable as the objects it is
borrowing from X though Y have not been pruned from X. But Step 3 for X
will lose them, rendering Z unusable.
^ permalink raw reply
* Re: [PATCH v3] Allow update hooks to update refs on their own
From: Steven Grimm @ 2007-11-29 6:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vve7m0wfo.fsf@gitster.siamese.dyndns.org>
On Nov 28, 2007, at 3:42 PM, Junio C Hamano wrote:
> I do not think reporting back the rewritten object name makes much
> sense
> nor adds any value; it won't be useful information until you fetch the
> object.
Right, this was mostly in anticipation of doing an automatic fetch, so
that I would avoid fetching anything but the rewritten revisions; if I
just fetched the remote ref as normal, then I'd potentially pick up
unrelated changes that happened to hit just after my pack was
accepted, which wouldn't maintain the "update the tracking ref to
point to what I just pushed" semantics.
Since it sounds like that's a nonstarter, I agree this part of the
patch isn't useful.
> I do not think reporting back _anything_ other than "ok" adds much
> value
> at all. Sure, if the update hook did something funky you would get
> such
> a report, but the situation is not any different if some warm body is
> sitting on the other end and building on top of what you pushed
> immediately he sees any push into the repository, and in such a case
> your git-push would not get any such reporting anyway.
I disagree that it's the same. In this case the updated ref happens as
a component of the push operation (which of course includes running
update hooks and at the very least looking at their exit codes to see
if a change should be rejected), not as a result of some other process
that happens to occur at nearly the same time. Reporting back the new
ref, at the very least, tells you that it's not useful to update the
tracking ref since it's 100% guaranteed to be wrong by the time the
push finishes.
> We do not even have to worry about this reporting at all if we do not
> allow munging the refs in the update hook. In a sense, this patch is
> creating a problem that does not need to be solved. Perhaps modifying
> update hook to allow so makes it possible to munge refs while
> holding a
> lock, but is it really worth this hassle? Isn't there a better way, I
> wonder?
If there is, I'm happy to hear it; for me this patch is a means, not
an end. What I actually want is to be able to have a particular set of
branches in a particular git repository be as-transparent-as-possible
conduits to corresponding branches in an svn repository.
I arrived at this approach by following this train of thought:
1. The update hook is the only hook that allows me to reject the push,
which I need to do if svn refuses to accept the change.
2. To tell whether svn accepts a change, I need to run git-svn
dcommit; thanks to #1, I need to do that from inside the update hook.
3. When I commit, git-svn needs to track that the git revision now
corresponds to an svn revision. It does that by modifying the commit
message to add its git-svn-id: line.
4. Modifying the commit comment causes the revision's SHA1 to change.
5. Out-of-the-box push thinks a push has failed if the ref's SHA1
changes in the update hook.
6. Therefore push needs to be modified to not do that.
If any one of #1-5 wasn't true or was solvable in a different way,
then #6 wouldn't be needed. For example, if git-svn kept its mapping
of git revisions to svn revisions somewhere else it could leave the
commit messages untouched, meaning the SHA1s wouldn't change.
-Steve
^ permalink raw reply
* Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)
From: Jan Hudec @ 2007-11-29 6:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0711282345500.27959@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]
On Wed, Nov 28, 2007 at 23:48:12 +0000, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 29 Nov 2007, Jan Hudec wrote:
>
> > On Wed, Nov 28, 2007 at 12:32:10 +0000, Johannes Schindelin wrote:
> > > On Wed, 28 Nov 2007, Jakub Narebski wrote:
> > > > 4. If git-gui would use other language/toolkit, would you
> > > > contribute?
> > > > Yes/No
> > >
> > > Yes, as long as it is a language/toolkit that is available on all
> > > platforms that I (have to) work. That pretty much excludes C# and
> > > Python as a language.
> >
> > Out of interest, where does neither of those two work and Qt and tcl/tk do?
> > Mono and python both seem to be quite portable.
>
> IRIX (an ancient one).
>
> Besides, Mono is darned slow. Even Tcl/Tk is faster.
On the shootout Mono seems to be an order of magnitude faster in most tests.
But maybe they are performing very poorly on some strange platform where they
don't have JIT.
> Furthermore, my complaint was not about a platform where neither C# nor
> Python work. That is irrelevant. If you have one platform where only one
> works, and another platform where only the other works, you cannot have a
> single program for both platforms. Right?
Right.
I probably shouldn't be surprised that mono does not work on older unices,
but I am a bit surprised python does not.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] scripts: do not get confused with HEAD in work tree
From: Mike Hommey @ 2007-11-29 7:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbq9d29h3.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 28, 2007 at 04:15:04PM -0800, Junio C Hamano wrote:
> When you have a file called HEAD in your work tree, many commands that
> our scripts feed "HEAD" to would complain about the rev vs path
> ambiguity. A solution is to form command line more carefully by
> appending -- to them, which makes it clear that we mean HEAD rev not
> HEAD file.
Shouldn't this be done for anything else, then ? You could have a file
with the same name as a branch and have some commands using branch names
fail too.
Mike
^ permalink raw reply
* Re: Adding Git to Better SCM Initiative : Comparison
From: Jan Hudec @ 2007-11-29 7:17 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jakub Narebski, git
In-Reply-To: <200711290248.23239.robin.rosenberg.lists@dewire.com>
On Thu, Nov 29, 2007 at 02:48:22 +0100, Robin Rosenberg wrote:
> I did start doing this so here's my version (pre-msysgit). Please try to bring up the defintion
> of "atomic" again with the author. I did complain a little but nothing happened. The issue is
> that Clearcase is listed as having "atomic" commits which is not true for any usable definition
> of atomic in SCM context. With the definition in use there I think CVS should be considered
> having atomic commits too, at least I've never seen a half-committed file there.
Actually, I did. Or rather, I did see a commit, that didn't make it to the
server, but the client thought it did!
Maybe instead of asking the author to change the definition of atomic, ask
him to add an item for whole-tree commits. That more precisely describes what
is the point.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: [PATCH v2] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: Johannes Sixt @ 2007-11-29 7:39 UTC (permalink / raw)
To: David Kastrup
Cc: Junio C Hamano, Johannes Schindelin, Wincent Colaiuta,
Benoit Sigoure, Git Mailing List
In-Reply-To: <85sl2q6kyu.fsf@lola.goethe.zz>
David Kastrup schrieb:
> Junio C Hamano <gitster@pobox.com> writes:
>> I thought somebody already mention that ash mishandles "export VAR=VAL"
>> but otherwise Ok.
>
> dak@lola:~$ ash
> $ export JUNK=woozle
> $ sh -c 'echo $JUNK'
> woozle
> $ exit
> dak@lola:~$ dash
> $ export JUNK=woozle
> $ sh -c 'echo $JUNK'
> woozle
> $ exit
>
> What problem are we talking about exactly, and with what shell?
$ export foo="bar baz"
$ bash
bash$ export JUNK=$foo
bash$ sh -c 'echo "$JUNK"'
bar baz
bash$ exit
exit
$ ash
ash$ export JUNK=$foo
ash$ sh -c 'echo "$JUNK"'
bar
ash$ exit
The problem is $foo not being quoted on the RHS of the assignment of the
export command: bash doesn't word-split, but ash does. Hence, *if*
export VAR=VAL is used, always quote VAL.
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-svn now reads settings even if called in subdirectory
From: Eric Wong @ 2007-11-29 7:41 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: git, gitster
In-Reply-To: <1195912076-3903-1-git-send-email-hendeby@isy.liu.se>
Gustaf Hendeby <hendeby@isy.liu.se> wrote:
> Previously, git-svn first read the .git/config file for settings as if
> current working directory was the repository top-directory, and after
> that made sure to cd into top-directory. The result was a silent
> failur to read configuration settings. This patch changes the order
> these two things are done.
>
> Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
>
> ---
>
> This fix seems a bit too obvious, which makes me think I missed
> something conceptual here. However, the patch passes "make test" and
> "make full-svn-test", and the problems I had with the svn.authorsfile
> setting not being honored while fetching from a subdirectory are gone.
Thanks Gustaf,
Seems right to me (note: I never use the authors file feature myself).
Acked-by: Eric Wong <normalperson@yhbt.net>
--
Eric Wong
^ permalink raw reply
* Re: git-svn rebase issues (the commiter gets changed)
From: Eric Wong @ 2007-11-29 7:52 UTC (permalink / raw)
To: Kelvie Wong; +Cc: git
In-Reply-To: <94ccbe710711220815j663d22e0v3c744244d0a87b66@mail.gmail.com>
Kelvie Wong <kelvie@ieee.org> wrote:
> When using git-svn rebase (I'm not sure if this happens with a regular
> rebase as well, I use use git-svn primarily at work), the following
> oddity happens:
>
> kelvie@mudd (working) qt $ git-cat-file commit
> c27e6207c9078d4225288d55454d6577f0135c16
> tree 13d9ef9cc67f5e6381d7697e5794c0ab5f72c729
> parent b9eb187d3029c5f9a816cb8f5473d9b239952d53
> author kwong <kwong@e2d93294-a71b-0410-9dca-e2ea525a67c9> 1195596864 +0000
> committer cscrimgeour
> <cscrimgeour@e2d93294-a71b-0410-9dca-e2ea525a67c9> 1195691944 +0000
This is strange. Does this commit end below? or did you truncate
the git-svn-id: line from this message?
>
> Qt/FME Extensions: QFMEDialog/QFMEWizard -> Windows only, for now
>
> This is also a reapplication of r39657, which got rolled back.
>
> These have dependencies on QWinWidget (which is a part of the MFC/Qt Migration
> Solution), and thus, it does not build without it.
> <kw>
> kelvie@mudd (working) qt $ git-cat-file commit
> 7075991c67c6d409ec2315dfeef6f45dd328485b
> tree 13d9ef9cc67f5e6381d7697e5794c0ab5f72c729
> parent b9eb187d3029c5f9a816cb8f5473d9b239952d53
> author kwong <kwong@e2d93294-a71b-0410-9dca-e2ea525a67c9> 1195596864 +0000
> committer Kelvie Wong <Kelvie.Wong@safe.com> 1195747291 +0000
This commit hasn't made it into SVN, yet, right? If so, then that's
alright.
>
> Qt/FME Extensions: QFMEDialog/QFMEWizard -> Windows only, for now
>
> This is also a reapplication of r39657, which got rolled back.
>
> These have dependencies on QWinWidget (which is a part of the MFC/Qt Migration
> Solution), and thus, it does not build without it.
> <kw>
>
>
> These are both the exact same commit (the tree, parent, and author are
> equivalent).
>
> Sometimes (not always), the committer in a commit changes to be the
> committer of the parent (svn) commit. This only happens to the
> commits whose parent is the SVN commit. In the above example,
> cscrimgeour is a SVN user, who obviously could not have changed my
> code; the proper commit is the one at the bottom.
>
> Both of these are the first local commit that I have rebased onto SVN.
Did you get these commits by cherry-picking (or format-patch + am)
from another SVN branch? Have these commits been made to SVN already?
`gitk --reflog --all' may reveal some answers or clarify
things for you (assuming you have reflogs enabled in .git/config).
Rebase (all forms of it) *does* rewrite committer info, but how you got
cscrimgeour in there is very strange to me.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-svn: add support for pulling author from From: and Signed-off-by:
From: Eric Wong @ 2007-11-29 7:55 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <1195739082.0@pinky>
Andy Whitcroft <apw@shadowen.org> wrote:
>
> Add support for pulling the real author of a commit from the From:
> and first Signed-off-by: fields of the SVN commit message.
>
> Signed-off-by: Andy Whitcroft <apw@shadowen.org>
A minor whitespace fix with an Acked patch below. Thanks.
> ---
> git-svn.perl | 36 +++++++++++++++++++++++++++++-------
> 1 files changed, 29 insertions(+), 7 deletions(-)
> diff --git a/git-svn.perl b/git-svn.perl
> index 5b1deea..a99982d 100755
> @@ -2165,7 +2173,16 @@ sub make_log_entry {
> $log_entry{log} .= "\n";
> my $author = $log_entry{author} = check_author($log_entry{author});
> my ($name, $email) = defined $::users{$author} ? @{$::users{$author}}
> - : ($author, undef);
> + : ($author, undef);
> +
> + my ($commit_name, $commit_email) = ($name, $email);
> + if ($_use_log_author) {
> + if ($log_entry{log} =~ /From:\s+(.*?)\s+<(.*)>\s*\n/) {
> + ($name, $email) = ($1, $2);
> + } elsif ($log_entry{log} =~ /Signed-off-by:\s+(.*?)\s+<(.*)>\s*\n/) {
> + ($name, $email) = ($1, $2);
> + }
> + }
> if (defined $headrev && $self->use_svm_props) {
> if ($self->rewrite_root) {
> die "Can't have both 'useSvmProps' and 'rewriteRoot' ",
>From 40fb9135d644f3a1fc47ae9b94ad62ec52b1234b Mon Sep 17 00:00:00 2001
From: Andy Whitcroft <apw@shadowen.org>
Date: Thu, 22 Nov 2007 13:44:42 +0000
Subject: [PATCH] git-svn: add support for pulling author from From: and Signed-off-by:
Add support for pulling the real author of a commit from the From:
and first Signed-off-by: fields of the SVN commit message.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 37 ++++++++++++++++++++++++++++++-------
1 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 640a45a..61f0c1a 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -81,6 +81,7 @@ my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
'quiet|q' => \$_q,
'repack-flags|repack-args|repack-opts=s' =>
\$Git::SVN::_repack_flags,
+ 'use-log-author' => \$Git::SVN::_use_log_author,
%remote_opts );
my ($_trunk, $_tags, $_branches, $_stdlayout);
@@ -1220,7 +1221,8 @@ 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 $_minimize_url/;
+ $_use_svnsync_props $no_reuse_existing $_minimize_url
+ $_use_log_author/;
use Carp qw/croak/;
use File::Path qw/mkpath/;
use File::Copy qw/copy/;
@@ -2060,11 +2062,17 @@ sub do_git_commit {
croak "$log_entry->{revision} = $c already exists! ",
"Why are we refetching it?\n";
}
- $ENV{GIT_AUTHOR_NAME} = $ENV{GIT_COMMITTER_NAME} = $log_entry->{name};
- $ENV{GIT_AUTHOR_EMAIL} = $ENV{GIT_COMMITTER_EMAIL} =
- $log_entry->{email};
+ $ENV{GIT_AUTHOR_NAME} = $log_entry->{name};
+ $ENV{GIT_AUTHOR_EMAIL} = $log_entry->{email};
$ENV{GIT_AUTHOR_DATE} = $ENV{GIT_COMMITTER_DATE} = $log_entry->{date};
+ $ENV{GIT_COMMITTER_NAME} = (defined $log_entry->{commit_name})
+ ? $log_entry->{commit_name}
+ : $log_entry->{name};
+ $ENV{GIT_COMMITTER_EMAIL} = (defined $log_entry->{commit_email})
+ ? $log_entry->{commit_email}
+ : $log_entry->{email};
+
my $tree = $log_entry->{tree};
if (!defined $tree) {
$tree = $self->tmp_index_do(sub {
@@ -2352,7 +2360,17 @@ sub make_log_entry {
$log_entry{log} .= "\n";
my $author = $log_entry{author} = check_author($log_entry{author});
my ($name, $email) = defined $::users{$author} ? @{$::users{$author}}
- : ($author, undef);
+ : ($author, undef);
+
+ my ($commit_name, $commit_email) = ($name, $email);
+ if ($_use_log_author) {
+ if ($log_entry{log} =~ /From:\s+(.*?)\s+<(.*)>\s*\n/) {
+ ($name, $email) = ($1, $2);
+ } elsif ($log_entry{log} =~
+ /Signed-off-by:\s+(.*?)\s+<(.*)>\s*\n/) {
+ ($name, $email) = ($1, $2);
+ }
+ }
if (defined $headrev && $self->use_svm_props) {
if ($self->rewrite_root) {
die "Can't have both 'useSvmProps' and 'rewriteRoot' ",
@@ -2375,23 +2393,28 @@ sub make_log_entry {
remove_username($full_url);
$log_entry{metadata} = "$full_url\@$r $uuid";
$log_entry{svm_revision} = $r;
- $email ||= "$author\@$uuid"
+ $email ||= "$author\@$uuid";
+ $commit_email ||= "$author\@$uuid";
} elsif ($self->use_svnsync_props) {
my $full_url = $self->svnsync->{url};
$full_url .= "/$self->{path}" if length $self->{path};
remove_username($full_url);
my $uuid = $self->svnsync->{uuid};
$log_entry{metadata} = "$full_url\@$rev $uuid";
- $email ||= "$author\@$uuid"
+ $email ||= "$author\@$uuid";
+ $commit_email ||= "$author\@$uuid";
} else {
my $url = $self->metadata_url;
remove_username($url);
$log_entry{metadata} = "$url\@$rev " .
$self->ra->get_uuid;
$email ||= "$author\@" . $self->ra->get_uuid;
+ $commit_email ||= "$author\@" . $self->ra->get_uuid;
}
$log_entry{name} = $name;
$log_entry{email} = $email;
+ $log_entry{commit_name} = $commit_name;
+ $log_entry{commit_email} = $commit_email;
\%log_entry;
}
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH] git-svn: Remove unnecessary Git::SVN::Util package
From: Eric Wong @ 2007-11-29 8:01 UTC (permalink / raw)
To: David D. Kilzer; +Cc: ask, git
In-Reply-To: <1195759080-20132-1-git-send-email-ddkilzer@kilzer.net>
"David D. Kilzer" <ddkilzer@kilzer.net> wrote:
> Digest::MD5 is loaded regardless of the package in which it's
> declared, so move its 'use' statement and the md5sum() function
> into the main package.
>
> Signed-off-by: David D. Kilzer <ddkilzer@kilzer.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
> ---
>
> Ask Bjørn Hansen <ask@develooper.com> wrote:
> > On Nov 21, 2007, at 11:57, David D. Kilzer wrote:
> > > Created new Git::SVN::Util package with an md5sum() function. A
> > > new package was created so that Digest::MD5 did not have to be
> > > loaded in the main package.
> > Huh? It's all in the same file anyway, so what difference does it
> > make?
>
> None!
I have floated the idea of splitting git-svn into several files to make
it easier to maintain and navigate. However, I'm not looking foward to
doing a install system for that...
Maybe it'll just cat all the files together during build and
still install as one file... *shrug*
> git-svn.perl | 23 +++++++++--------------
> 1 files changed, 9 insertions(+), 14 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 62801c8..17d3020 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -35,6 +35,7 @@ push @Git::SVN::Ra::ISA, 'SVN::Ra';
> push @SVN::Git::Editor::ISA, 'SVN::Delta::Editor';
> push @SVN::Git::Fetcher::ISA, 'SVN::Delta::Editor';
> use Carp qw/croak/;
> +use Digest::MD5;
> use IO::File qw//;
> use File::Basename qw/dirname basename/;
> use File::Path qw/mkpath/;
> @@ -48,8 +49,7 @@ BEGIN {
> foreach (qw/command command_oneline command_noisy command_output_pipe
> command_input_pipe command_close_pipe/) {
> for my $package ( qw(SVN::Git::Editor SVN::Git::Fetcher
> - Git::SVN::Migration Git::SVN::Log Git::SVN
> - Git::SVN::Util),
> + Git::SVN::Migration Git::SVN::Log Git::SVN),
> __PACKAGE__) {
> *{"${package}::$_"} = \&{"Git::$_"};
> }
> @@ -835,19 +835,19 @@ sub cmd_info {
> command_output_pipe(qw(cat-file blob), "HEAD:$path");
> if ($file_type eq "link") {
> my $file_name = <$fh>;
> - $checksum = Git::SVN::Util::md5sum("link $file_name");
> + $checksum = md5sum("link $file_name");
> } else {
> - $checksum = Git::SVN::Util::md5sum($fh);
> + $checksum = md5sum($fh);
> }
> command_close_pipe($fh, $ctx);
> } elsif ($file_type eq "link") {
> my $file_name =
> command(qw(cat-file blob), "HEAD:$path");
> $checksum =
> - Git::SVN::Util::md5sum("link " . $file_name);
> + md5sum("link " . $file_name);
> } else {
> open FILE, "<", $path or die $!;
> - $checksum = Git::SVN::Util::md5sum(\*FILE);
> + $checksum = md5sum(\*FILE);
> close FILE or die $!;
> }
> $result .= "Checksum: " . $checksum . "\n";
> @@ -1187,11 +1187,6 @@ sub find_file_type_and_diff_status {
> return ("file", $diff_status);
> }
>
> -package Git::SVN::Util;
> -use strict;
> -use warnings;
> -use Digest::MD5;
> -
> sub md5sum {
> my $arg = shift;
> my $ref = ref $arg;
> @@ -2926,7 +2921,7 @@ sub apply_textdelta {
>
> if (defined $exp) {
> seek $base, 0, 0 or croak $!;
> - my $got = Git::SVN::Util::md5sum($base);
> + my $got = ::md5sum($base);
> die "Checksum mismatch: $fb->{path} $fb->{blob}\n",
> "expected: $exp\n",
> " got: $got\n" if ($got ne $exp);
> @@ -2945,7 +2940,7 @@ sub close_file {
> if (my $fh = $fb->{fh}) {
> if (defined $exp) {
> seek($fh, 0, 0) or croak $!;
> - my $got = Git::SVN::Util::md5sum($fh);
> + my $got = ::md5sum($fh);
> if ($got ne $exp) {
> die "Checksum mismatch: $path\n",
> "expected: $exp\n got: $got\n";
> @@ -3300,7 +3295,7 @@ sub chg_file {
> $fh->flush == 0 or croak $!;
> seek $fh, 0, 0 or croak $!;
>
> - my $exp = Git::SVN::Util::md5sum($fh);
> + my $exp = ::md5sum($fh);
> seek $fh, 0, 0 or croak $!;
>
> my $pool = SVN::Pool->new;
> --
> 1.5.3.4
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-svn: add a show-externals command.
From: Eric Wong @ 2007-11-29 8:04 UTC (permalink / raw)
To: Vineet Kumar; +Cc: git
In-Reply-To: <1195512975-3647-1-git-send-email-vineet@doorstop.net>
Vineet Kumar <vineet@doorstop.net> wrote:
> show-externals can be used by scripts to provide svn:externals-like
> functionality. For example, a script can list all of the externals and then
> use check out the listed URLs at the appropriate paths, similar to what the svn
> client does. Said script (or perhaps git-svn itself, in the future) could
> simply invoke svn export on the paths, or it could go one further, using
> git-svn clone and even git-submodule together to better integrate externals
> checkouts.
>
> The implementation is shamelessly copied from show-ignores. A more general
> command to list user-specified properties is probably a better idea.
>
> Signed-off-by: Vineet Kumar <vineet@doorstop.net>
Thanks.
Acked-by: Eric Wong <normalperson@yhbt.net>
I'm close to having svn:externals supported in git-svn, too. But
previously cloned repositories probably won't support them
out-of-the-box, so this can still be useful.
> ---
> git-svn.perl | 18 ++++++++++++++++++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 5b1deea..74966ed 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -141,6 +141,9 @@ my %cmd = (
> 'show-ignore' => [ \&cmd_show_ignore, "Show svn:ignore listings",
> { 'revision|r=i' => \$_revision
> } ],
> + 'show-externals' => [ \&cmd_show_externals, "Show svn:externals listings",
> + { 'revision|r=i' => \$_revision
> + } ],
> 'multi-fetch' => [ \&cmd_multi_fetch,
> "Deprecated alias for $0 fetch --all",
> { 'revision|r=s' => \$_revision, %fc_opts } ],
> @@ -560,6 +563,21 @@ sub cmd_show_ignore {
> });
> }
>
> +sub cmd_show_externals {
> + my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
> + $gs ||= Git::SVN->new;
> + my $r = (defined $_revision ? $_revision : $gs->ra->get_latest_revnum);
> + $gs->prop_walk($gs->{path}, $r, sub {
> + my ($gs, $path, $props) = @_;
> + print STDOUT "\n# $path\n";
> + my $s = $props->{'svn:externals'} or return;
> + $s =~ s/[\r\n]+/\n/g;
> + chomp $s;
> + $s =~ s#^#$path#gm;
> + print STDOUT "$s\n";
> + });
> +}
> +
> sub cmd_create_ignore {
> my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
> $gs ||= Git::SVN->new;
> --
> 1.5.3.4
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Eric Wong
^ permalink raw reply
* Re: git-svn: surprising behaviors/bugs?
From: Eric Wong @ 2007-11-29 8:10 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: git
In-Reply-To: <bf7b2dda0711220537h3f37c84ag899b74daa9a8fe1f@mail.gmail.com>
Gustaf Hendeby <hendeby@gmail.com> wrote:
> I've been running git for most my stuff for some time now, and am
> really pleased with what it has to offer. However, all my coworkers
> aren't gitified yet, and therefore I sometimes have to work with svn.
> I've learned to appreciate git-svn for this, since it lets me utilize
> the strengths of git and still allows for my coworkers to think I use
> their svn setup. Thanks to all who contribute to this wonderful
> tools!
>
> In my work with git-svn I have stumbled upon the following two
> unexpected behaviors. Basically, am I doing/understanding something
> wrong, or is this buggy behavior in git-svn? (I'm presently using git
> 1.5.3.6, but have been experiencing these things for a while.)
>
>
> 1. I don't really like svn's committer info, so I got an authorsfile
> set. This works great when I'm fetching/dcommitting from the
> top-directory in my git checkout (the one with .git in), however, if
> I'm in a subdirectory the authorsfile doesn't kick in and I get the
> svn commiter info. This is not a big deal, but a bit surprising and
> my history gets a bit ugly.
I see you've already fixed that. Thanks.
> 2. My second problem involves getting the support in git-svn for tags
> and branches to work. Having a standard layout of the svn repository,
> in this case
> /source/project/(trunk|branch|tags)
> svn clone -s only works as expected sometimes. Sometimes I only get
> the revision history, not including any actual content (ie none files
> of the files under control turns up in git) from the clone. When I
> get this problem I usually clone the trunk only, and add tags myself.
> This is far from optimal, and also error prone. Other times, the
> clone works as expected and gives me the tags and branches and all the
> content.
Any chance there's a BOFH at the other end playing around with
permissions while you were testing?
> I think the problem occurs when I'm not the owner of the svn
> repository, and only have access (read/write) to the
> project/(trunk|branch|tag) part, and don't have any access at all to
> source. Ie, svn ls works for /source/project and
> /source/project/trunk etc, but not /source (where I returns 403
> Forbidden access). All svn access is through a svn-server that I
> can't control myself.
I'll have to look into that some other time.
Does `svn log -v' work for /source/project ?
Am I correct in what you have is currently like this?
[svn-remote "svn"]
url = http://domain/
branches = source/project/branches/*:refs/remotes/*
tags = source/project/tags/*:refs/remotes/tags/*
fetch = source/project/trunk:refs/remotes/trunk
If so, can you change it to something like this?
[svn-remote "svn"]
url = http://domain/source/project
branches = branches/*:refs/remotes/*
tags = tags/*:refs/remotes/tags/*
fetch = trunk:refs/remotes/trunk
And see if that works all the time?
Thanks,
--
Eric Wong
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johan Herland @ 2007-11-29 8:24 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Nicolas Pitre, J. Bruce Fields, Johannes Schindelin,
しらいしななこ ,
Andreas Ericsson, Jakub Narebski
In-Reply-To: <7vlk8hzx0g.fsf@gitster.siamese.dyndns.org>
On Thursday 29 November 2007, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
> > ... In all the tutorials for $job I've done so
> > far, I simply never talk about pull nor clone, but rather about init,
> > "git remote", fetch and merge, with explicit and meaningful branch
> > names. I think that basic commands, even if there is a bit more of
> > them, make Git easier to learn and understand than talking about those
> > magic meta commands hiding the truth away.
>
> That's actually a quite interesting approach for teaching.
>
> The original "tutorial" (now core-tutorial) was similar in spirit; it
> built the user experience by starting at sequence of low level commands,
> and then finally said "since this is so often used combination, there is
> a short-hand for it that does all". I think the approach would work
> quite well for people who want to use the tool with deep understanding.
>
> However, I am not so sure about people who just want canned set of
> instructions and follow them blindly to get their work done. And I do
> not think the latter classes of users are necessarily wrong.
>
> Such a canned set of instructions would (if the project that supplies
> the cheat-sheet encourages merges instead of rebases) talk about "clone
> then commit then push then pull and repeat", without mentioning what
> pull does is fetch+merge nor what fetch means and what merge means, and
> that would let people get started without deeper understanding.
>
> But the lack of deeper understanding would hurt them in the longer run
> (e.g. "my push was rejected with something called non-fast-forward ---
> what does that mean and what would I do now?").
What about ending the cheat-sheet with a big fat link to a FAQ? The FAQ
answers common questions like the above (resulting from the cheat-sheet
glossing over the details) with links to appropriate sections in the more
thorough introduction (core-tutorial), explaining what's _really_ going on.
Just a thought.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH v2] Teach 'git pull' about --rebase
From: Andreas Ericsson @ 2007-11-29 8:36 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, J. Bruce Fields, Lars Hjemli, Steven Grimm,
Linus Torvalds, git
In-Reply-To: <7v1waa2bfi.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> So my rationale was: if we already have an existing framework to integrate
>> remote changes with our current branch, why not just go ahead and use it?
>> That's the reason BTW why I originally wanted a "rebase" merge stragegy.
>> Even if it is not technically a merge.
>>
>> I really rather have no user-friendly support for fetch+rebase (and utter
>> a friendly, but loud curse everytime I made a "git pull" by mistake) than
>> yet another command.
>
> I suspect that people who do not like the two modes of checkout will
> certainly not appreciate the overloading two behaviours to create
> different kind of histories and two different ways to continue when the
> integration do not go smoothly upon conflicts these two behaviours have.
>
> However, I agree very much with an earlier comment made by Daniel about
> our UI being task oriented instead of being command oriented, and I
> actually consider it a good thing. So it does not bother me too much
> that "git pull --rebase" has a quite different workflow from the regular
> "merge" kind of pull.
>
> So let's queue "pull --rebase" and see what happens.
>
I've used the --rebase option to git pull, explained it to my co-workers
and also made sure they're using a version of git that has it. So far
there hasn't been a single complaint about "git pull" being any harder
to grok.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Rollback of git commands
From: Karl Hasselström @ 2007-11-29 8:42 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jon Smirl, Sean, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.99999.0711281125320.9605@xanadu.home>
On 2007-11-28 11:26:45 -0500, Nicolas Pitre wrote:
> On Wed, 28 Nov 2007, Jon Smirl wrote:
>
> > The state contained in the other config files in .git/* is not
> > getting check pointed. I can use reflog to move my branch heads
> > around. But doing that does not undo the changes to the state
> > recorded in .git/*. After the error I encountered I moved my
> > branch head back, but the state stgit had stored in .git/* was out
> > of sync with where the branch had been moved to.
>
> It's up to stgit to version control its state then. It may even use
> a reflog for it. All the machinery is there already.
I agree -- this is StGit's job.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 1/3] Add basic cvsimport tests
From: Andreas Ericsson @ 2007-11-29 9:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Emanuele Giaquinta, git
In-Reply-To: <7v8x4i3tn4.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
>> + cat <<EOF >o_fortuna &&
>> +O Fortuna
>> + ...
>
> Copyrights?
>
>> +add "O Fortuna" lyrics
>> +
>> +These public domain lyrics make an excellent sample text.
>> +EOF
>
> Ah, really? Ok...
The poet, whoever he/she was (no-one knows today), has been dead
nearly 800 years, so any copyrights that might once have been in
place have expired.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Rollback of git commands
From: Theodore Tso @ 2007-11-29 8:28 UTC (permalink / raw)
To: Jon Smirl
Cc: Daniel Barkalow, Karl Hasselström, Junio C Hamano,
Git Mailing List
In-Reply-To: <9e4733910711281542r5b1e5dd9o68ff8565f9000453@mail.gmail.com>
On Wed, Nov 28, 2007 at 06:42:56PM -0500, Jon Smirl wrote:
> I'm a patch developer. You need to change the patches continuously to
> track feedback on the lkml type lists. You also have to rebase in
> order to keep tracking head. Other people often work on the same
> things and this triggers merges against the pending patches.
Yeah, I use guilt for projects where I have a patch queue that takes a
while to merge into the mainline, due to quality control or review
guidelines that still need to be met. Basically the kernel has a
different workflow than git, where each project or developer has a
separate patch queue that is maintained inside git (possibly with
guilt or stgit as helpers) or quilt, instead of a centrally managed pu
branch. This is I suspect mainly a scaling issue; it's hard to keep a
centrally maintained pu branch because anytime someone wants to make a
change to one of their topic branches, they have to go through the
central maintainer. The closest analogue to the pu branch is Andrew
Morton's akpm, and he gets grumpy when there are merge conflicts
between the various branches and patch queues that he pulls from in
order to make the -mm tree for integration testing.
> I'd just like for stgit to become a core part of git so that is can be
> made more bullet proof. I'm losing my patch stack every couple of
> weeks. It's normally a "user error" but it is way to easy to make
> these user errors.
I haven't tried using stgit in quite a while mainly because I was
finding it too easy to lose my patch queue. It was happening to me
*way* to often, and while it sounds like it's gotten better due to
adding more sanity checks --- and when I tried it last, "stg repair"
didn't exist --- it sounds like it is still possible for someone who
typo's a command to get themselves into trouble. I'm sure it's not an
issue for the stgit developers because they know which commands to
avoid, but if something isn't 100% bulletproof --- I get nervous.
So my solution to this problem is I use guilt. I *like* the fact that
the primary storage mechanism is actual flat ASCII patch files, since
as a result I've never lost a patch stack --- ASCII patch files are
much more robust. My way of rebasing a set of patches is very simple;
I just do "guilt pop -a; git merge master; guilt push -a" --- and if
there are any conflicts, then I do a "guilt push -f", fix up the
conflicts, follow it with a "guilt refresh", and then resume pushing
the rest of my patches sing "guilt push -a". It just works; no muss,
no fuss, no dirty dishes.
Another thing this allows me to do is that it is possible to put the
guilt patch stack itself under git control. This allows me to go
backwards in time and see what the patch stack looked like n days or n
weeks ago. A comment in the patch header indicates what version of
the kernel the patch stack was meant against.
For example for ext4 development the guilt patch stack is themselves
stored using git on repo.or.cz, with multiple people having access to
push updates to the patch queue. Before I start hacking the ext4,
I'll do run the command "(cd .git/patches/ext4dev; git pull") to check
for new updates in the ext4 patch queue, and if it has changed, I'll
do a "guilt pop -a; guilt push -a" to refresh the working directory
and ext4dev branch in my Linux git tree. When I'm done making
changes, by using commands such as "guilt pop", "guilt refresh",
"guilt pop", et. al., I'll commit changes in the .git/patches/ext4dev
tree, and then push them back to repo.or.cz.
We also have a system where an automated build/test server checks
every few hours if the patch queue on repo.or.cz has changed, and if
so, it pulls the patch queue, and then builds and tests the patch
queue on a wide variety of hardware architectures (i386, x86_64, ia64,
ppc64, s390, etc.) and sends an e-mail pack to the developers list
telling us which test hardware platforms passed, and which platforms
fail. Actually, we do two such tests --- one up to the "stable" point
in the patch series, which represents the next set of patches we plan
to push to Linus during the next merge window, and one for the entire
patch queue (stable plus unstable patches that need more work).
It works quite well for us --- and while there are some advanced
feature that stgit has which guilt doesn't, the feeling of safety of
knowing that the ASCII patch files won't get lost, and the ability to
do things such as shared patch queue maintenance and ability to keep
the patch queue under SCM are enough of a win that at least for my
purposes guilt is the better choice.
> stgit is what you need for this work flow. It lets me easily rebase or
> edit specific patches. It also lets me easily maintain private debug
> patches that I can apply as needed.
As mentioned above, I use guilt for major patch queues. For smaller
sets of patches, such as private debug patches, I just use a separate
git branch for those, and keep them up-to-date by using "git rebase"
and "git rebase -i". Then when I want to enable some debug patch,
I'll just do a "git merge" in a scratch branch.
- Ted
^ permalink raw reply
* Re: [PATCH] rebase -i: give rerere a chance
From: David Kastrup @ 2007-11-29 9:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711290021280.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Wed, 28 Nov 2007, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > @@ -166,13 +167,13 @@ pick_one_preserving_merges () {
>> > msg="$(git cat-file commit $sha1 | sed -e '1,/^$/d')"
>> > # No point in merging the first parent, that's HEAD
>> > new_parents=${new_parents# $first_parent}
>> > - # NEEDSWORK: give rerere a chance
>> > if ! GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
>> > GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
>> > GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
>> > output git merge $STRATEGY -m "$msg" \
>> > $new_parents
>> > then
>> > + git rerere
>>
>> This comment is not about this rerere change, but output is a shell
>> function and I vaguely recall we had a discussion on "VAR=VAL cmd" form
>> of single-shot export not working for them as expected...
>
> Hmm. What do you propose? In the long run, I _want_ to have rebase as a
> builtin, which would solve this problem, probably. But in the short run?
Well, something like
if ! ( GIT_xxx=A; export GIT_xxx; output git merge ... )
should likely work.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: git-svn: surprising behaviors/bugs?
From: Gustaf Hendeby @ 2007-11-29 9:59 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20071129081031.GF32277@soma>
On Nov 29, 2007 9:10 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Gustaf Hendeby <hendeby@gmail.com> wrote:
> > 1. I don't really like svn's committer info, so I got an authorsfile
> > set. This works great when I'm fetching/dcommitting from the
> > top-directory in my git checkout (the one with .git in), however, if
> > I'm in a subdirectory the authorsfile doesn't kick in and I get the
> > svn commiter info. This is not a big deal, but a bit surprising and
> > my history gets a bit ugly.
>
> I see you've already fixed that. Thanks.
Yes, it turned out to be easier than I thought. The fix indicates
that other options are lost as well, but I don't know how to test for
that or it would have been easier for others to verify the problem.
> > 2. My second problem involves getting the support in git-svn for tags
> > and branches to work. Having a standard layout of the svn repository,
> > in this case
> > /source/project/(trunk|branch|tags)
> > svn clone -s only works as expected sometimes. Sometimes I only get
> > the revision history, not including any actual content (ie none files
> > of the files under control turns up in git) from the clone. When I
> > get this problem I usually clone the trunk only, and add tags myself.
> > This is far from optimal, and also error prone. Other times, the
> > clone works as expected and gives me the tags and branches and all the
> > content.
>
> Any chance there's a BOFH at the other end playing around with
> permissions while you were testing?
This time I think BOFH is innocent, unless for maybe setting up the
SVN repository in a stupid way.
> > I think the problem occurs when I'm not the owner of the svn
> > repository, and only have access (read/write) to the
> > project/(trunk|branch|tag) part, and don't have any access at all to
> > source. Ie, svn ls works for /source/project and
> > /source/project/trunk etc, but not /source (where I returns 403
> > Forbidden access). All svn access is through a svn-server that I
> > can't control myself.
>
> I'll have to look into that some other time.
Would be great, thanks, let me know how I can help. I've tried to
answer your questions about the setup below.
>
> Does `svn log -v' work for /source/project ?
Works just fine.
>
> Am I correct in what you have is currently like this?
>
> [svn-remote "svn"]
> url = http://domain/
> branches = source/project/branches/*:refs/remotes/*
> tags = source/project/tags/*:refs/remotes/tags/*
> fetch = source/project/trunk:refs/remotes/trunk
>
>
> If so, can you change it to something like this?
>
> [svn-remote "svn"]
> url = http://domain/source/project
> branches = branches/*:refs/remotes/*
> tags = tags/*:refs/remotes/tags/*
> fetch = trunk:refs/remotes/trunk
>
> And see if that works all the time?
I just made three different setups to get the same (problematic) project.
PLAIN TRUNK (works as expected, but lacks tags/branches)
git svn init https://svn.isy.liu.se/rt/tidefelt/source/shapes shapes.trunk
cd shapes.trunk
git svn fetch # Now gives me the history of the trunk with all content
cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[svn-remote "svn"]
url = https://svn.isy.liu.se/rt/tidefelt/source/shapes/trunk
fetch = :refs/remotes/git-svn
WITH STANDARD LAYOUT (gets no content)
git svn init -s https://svn.isy.liu.se/rt/tidefelt/source/shapes shapes
cd shapes
git svn fetch # No files present in any commit
cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[svn-remote "svn"]
url = https://svn.isy.liu.se/rt
fetch = tidefelt/source/shapes/trunk:refs/remotes/trunk
branches = tidefelt/source/shapes/branches/*:refs/remotes/*
tags = tidefelt/source/shapes/tags/*:refs/remotes/tags/*
What seems to complicate things here, and that I didn't realize
before, is that I have access to https://svn.isy.liu.se/rt (at least
read), so if git-svn starts from the bottom and checks for premissions
it will find this root directory.
WITH CHANGED STANDARD LAYOUT (retrieves neither content nor tags)
git svn init -s https://svn.isy.liu.se/rt/tidefelt/source/shapes shapes.fix
cd shapes.fix
# Edit .git/config
git svn fetch
cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[svn-remote "svn"]
url = https://svn.isy.liu.se/rt/tidefelt/source/shapes
fetch = trunk:refs/remotes/trunk
branches = branches/*:refs/remotes/*
tags = tags/*:refs/remotes/tags/*
The version where I make changes in .git/config file fails also for a
project that I don't have any problems with just using the -s option.
Do I have to do anything more than just change the config file?
All of the above git svn fetch complains a bit the first time with a
message similar to:
W: Ignoring error from SVN, path probably does not exist: (175007):
HTTP Path Not Found: REPORT request failed on
'/rt/!svn/bc/100/tidefelt/source/shapes':
'/rt/!svn/bc/100/tidefelt/source/shapes' path not found
Please, let me know if there is any other information that would be useful.
/Gustaf
^ permalink raw reply
* Re: [PATCH v2] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: David Kastrup @ 2007-11-29 10:17 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Johannes Schindelin, Wincent Colaiuta,
Benoit Sigoure, Git Mailing List
In-Reply-To: <474E6CC8.8000301@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
>> What problem are we talking about exactly, and with what shell?
>
> $ export foo="bar baz"
> $ bash
> bash$ export JUNK=$foo
> bash$ sh -c 'echo "$JUNK"'
> bar baz
> bash$ exit
> exit
> $ ash
> ash$ export JUNK=$foo
> ash$ sh -c 'echo "$JUNK"'
> bar
> ash$ exit
>
> The problem is $foo not being quoted on the RHS of the assignment of
> the export command: bash doesn't word-split, but ash does. Hence, *if*
> export VAR=VAL is used, always quote VAL.
I much prefer the quoting solution over the quite more invasive rewrites
proposed here.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [PATCH] per-directory-exclude: lazily read .gitignore files
From: Junio C Hamano @ 2007-11-29 10:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <7vr6i9y6ju.fsf@gitster.siamese.dyndns.org>
Operations that walk directories or trees, which potentially need to
consult the .gitignore files, used to always try to open the .gitignore
file every time they entered a new directory, even when they ended up
not needing to call excluded() function to see if a path in the
directory is ignored.
This changes the directory walking API to remove the need to call these
two functions. Instead, the directory walk data structure caches the
data used by excluded() function the last time, and lazily reuses it as
much as possible. Among the data the last check used, the ones from
deeper directories that the path we are checking is outside are
discarded, data from the common leading directories are reused, and then
the directories between the common directory and the directory the path
being checked is in are checked for .gitignore file. This is very
similar to the way gitattributes are handled.
This API change also fixes "ls-files -c -i", which called excluded()
without setting up the gitignore data via the old push/pop functions.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> Less than a hundredth of a second may not sound much, but when we have
>> 1700+ directories in the kernel trees, doing that for each possible
>> .gitignore file is really really expensive!
>
> The only thing that wants to use excluded() in the unpack_trees()
> codepath is the code to allow overwriting an existing, untracked file in
> verify_absent(). When we find an untracked file at the same path as we
> are just trying to check out a file, we allow overwriting it only if
> that file is "ignored".
> ...
> The newer gitattributes subsystem maintains a similar per-directory data
> structure but this is purely done on-demand; until somebody asks "what
> are the attrs for this path", we do not read .gitattributes file. We
> should be able to restructure exclude-per-directory code in a similar
> way.
I haven't seriously benched this, other than the same read-tree test
you mentioned. With the good locality the directory walking (both by
read_directory() aka ls-files and unpack_trees() aka read-tree) tends
to have, checks for paths from the same directory come next to each
other, and that seems to help.
dir.c | 103 +++++++++++++++++++++++++++++---------------------------
dir.h | 32 ++++++++++-------
unpack-trees.c | 6 ---
3 files changed, 72 insertions(+), 69 deletions(-)
diff --git a/dir.c b/dir.c
index 7c97483..d448902 100644
--- a/dir.c
+++ b/dir.c
@@ -151,6 +151,7 @@ void add_exclude(const char *string, const char *base,
static int add_excludes_from_file_1(const char *fname,
const char *base,
int baselen,
+ char **buf_p,
struct exclude_list *which)
{
struct stat st;
@@ -171,6 +172,8 @@ static int add_excludes_from_file_1(const char *fname,
goto err;
close(fd);
+ if (buf_p)
+ *buf_p = buf;
buf[size++] = '\n';
entry = buf;
for (i = 0; i < size; i++) {
@@ -192,31 +195,63 @@ static int add_excludes_from_file_1(const char *fname,
void add_excludes_from_file(struct dir_struct *dir, const char *fname)
{
- if (add_excludes_from_file_1(fname, "", 0,
+ if (add_excludes_from_file_1(fname, "", 0, NULL,
&dir->exclude_list[EXC_FILE]) < 0)
die("cannot use %s as an exclude file", fname);
}
-int push_exclude_per_directory(struct dir_struct *dir, const char *base, int baselen)
+static void prep_exclude(struct dir_struct *dir, const char *base, int baselen)
{
- char exclude_file[PATH_MAX];
- struct exclude_list *el = &dir->exclude_list[EXC_DIRS];
- int current_nr = el->nr;
-
- if (dir->exclude_per_dir) {
- memcpy(exclude_file, base, baselen);
- strcpy(exclude_file + baselen, dir->exclude_per_dir);
- add_excludes_from_file_1(exclude_file, base, baselen, el);
+ struct exclude_list *el;
+ struct exclude_stack *stk = NULL;
+ int current;
+
+ if ((!dir->exclude_per_dir) ||
+ (baselen + strlen(dir->exclude_per_dir) >= PATH_MAX))
+ return; /* too long a path -- ignore */
+
+ /* Pop the ones that are not the prefix of the path being checked. */
+ el = &dir->exclude_list[EXC_DIRS];
+ while ((stk = dir->exclude_stack) != NULL) {
+ if (stk->baselen <= baselen &&
+ !strncmp(dir->basebuf, base, stk->baselen))
+ break;
+ dir->exclude_stack = stk->prev;
+ while (stk->exclude_ix < el->nr)
+ free(el->excludes[--el->nr]);
+ free(stk->filebuf);
+ free(stk);
}
- return current_nr;
-}
-void pop_exclude_per_directory(struct dir_struct *dir, int stk)
-{
- struct exclude_list *el = &dir->exclude_list[EXC_DIRS];
+ /* Read from the parent directories and push them down. */
+ current = stk ? stk->baselen : -1;
+ while (current < baselen) {
+ struct exclude_stack *stk = xcalloc(1, sizeof(*stk));
+ const char *cp;
- while (stk < el->nr)
- free(el->excludes[--el->nr]);
+ if (current < 0) {
+ cp = base;
+ current = 0;
+ }
+ else {
+ cp = strchr(base + current + 1, '/');
+ if (!cp)
+ die("oops in prep_exclude");
+ cp++;
+ }
+ stk->prev = dir->exclude_stack;
+ stk->baselen = cp - base;
+ stk->exclude_ix = el->nr;
+ memcpy(dir->basebuf + current, base + current,
+ stk->baselen - current);
+ strcpy(dir->basebuf + stk->baselen, dir->exclude_per_dir);
+ add_excludes_from_file_1(dir->basebuf,
+ dir->basebuf, stk->baselen,
+ &stk->filebuf, el);
+ dir->exclude_stack = stk;
+ current = stk->baselen;
+ }
+ dir->basebuf[baselen] = '\0';
}
/* Scan the list and let the last match determines the fate.
@@ -283,6 +318,7 @@ int excluded(struct dir_struct *dir, const char *pathname)
const char *basename = strrchr(pathname, '/');
basename = (basename) ? basename+1 : pathname;
+ prep_exclude(dir, pathname, basename-pathname);
for (st = EXC_CMDL; st <= EXC_FILE; st++) {
switch (excluded_1(pathname, pathlen, basename, &dir->exclude_list[st])) {
case 0:
@@ -500,13 +536,10 @@ static int read_directory_recursive(struct dir_struct *dir, const char *path, co
int contents = 0;
if (fdir) {
- int exclude_stk;
struct dirent *de;
char fullname[PATH_MAX + 1];
memcpy(fullname, base, baselen);
- exclude_stk = push_exclude_per_directory(dir, base, baselen);
-
while ((de = readdir(fdir)) != NULL) {
int len, dtype;
int exclude;
@@ -580,8 +613,6 @@ static int read_directory_recursive(struct dir_struct *dir, const char *path, co
}
exit_early:
closedir(fdir);
-
- pop_exclude_per_directory(dir, exclude_stk);
}
return contents;
@@ -650,37 +681,9 @@ static void free_simplify(struct path_simplify *simplify)
int read_directory(struct dir_struct *dir, const char *path, const char *base, int baselen, const char **pathspec)
{
struct path_simplify *simplify = create_simplify(pathspec);
- char *pp = NULL;
-
- /*
- * Make sure to do the per-directory exclude for all the
- * directories leading up to our base.
- */
- if (baselen) {
- if (dir->exclude_per_dir) {
- char *p;
- pp = xmalloc(baselen+1);
- memcpy(pp, base, baselen+1);
- p = pp;
- while (1) {
- char save = *p;
- *p = 0;
- push_exclude_per_directory(dir, pp, p-pp);
- *p++ = save;
- if (!save)
- break;
- p = strchr(p, '/');
- if (p)
- p++;
- else
- p = pp + baselen;
- }
- }
- }
read_directory_recursive(dir, path, base, baselen, 0, simplify);
free_simplify(simplify);
- free(pp);
qsort(dir->entries, dir->nr, sizeof(struct dir_entry *), cmp_name);
qsort(dir->ignored, dir->ignored_nr, sizeof(struct dir_entry *), cmp_name);
return dir->nr;
diff --git a/dir.h b/dir.h
index 82009dc..d8814dc 100644
--- a/dir.h
+++ b/dir.h
@@ -1,17 +1,6 @@
#ifndef DIR_H
#define DIR_H
-/*
- * We maintain three exclude pattern lists:
- * EXC_CMDL lists patterns explicitly given on the command line.
- * EXC_DIRS lists patterns obtained from per-directory ignore files.
- * EXC_FILE lists patterns from fallback ignore files.
- */
-#define EXC_CMDL 0
-#define EXC_DIRS 1
-#define EXC_FILE 2
-
-
struct dir_entry {
unsigned int len;
char name[FLEX_ARRAY]; /* more */
@@ -34,6 +23,13 @@ struct exclude_list {
} **excludes;
};
+struct exclude_stack {
+ struct exclude_stack *prev;
+ char *filebuf;
+ int baselen;
+ int exclude_ix;
+};
+
struct dir_struct {
int nr, alloc;
int ignored_nr, ignored_alloc;
@@ -48,6 +44,18 @@ struct dir_struct {
/* Exclude info */
const char *exclude_per_dir;
struct exclude_list exclude_list[3];
+ /*
+ * We maintain three exclude pattern lists:
+ * EXC_CMDL lists patterns explicitly given on the command line.
+ * EXC_DIRS lists patterns obtained from per-directory ignore files.
+ * EXC_FILE lists patterns from fallback ignore files.
+ */
+#define EXC_CMDL 0
+#define EXC_DIRS 1
+#define EXC_FILE 2
+
+ struct exclude_stack *exclude_stack;
+ char basebuf[PATH_MAX];
};
extern int common_prefix(const char **pathspec);
@@ -58,8 +66,6 @@ extern int common_prefix(const char **pathspec);
extern int match_pathspec(const char **pathspec, const char *name, int namelen, int prefix, char *seen);
extern int read_directory(struct dir_struct *, const char *path, const char *base, int baselen, const char **pathspec);
-extern int push_exclude_per_directory(struct dir_struct *, const char *, int);
-extern void pop_exclude_per_directory(struct dir_struct *, int);
extern int excluded(struct dir_struct *, const char *);
extern void add_excludes_from_file(struct dir_struct *, const char *fname);
diff --git a/unpack-trees.c b/unpack-trees.c
index aea16ad..e9eb795 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -71,12 +71,8 @@ static int unpack_trees_rec(struct tree_entry_list **posns, int len,
int remove;
int baselen = strlen(base);
int src_size = len + 1;
- int i_stk = i_stk;
int retval = 0;
- if (o->dir)
- i_stk = push_exclude_per_directory(o->dir, base, strlen(base));
-
do {
int i;
const char *first;
@@ -255,8 +251,6 @@ static int unpack_trees_rec(struct tree_entry_list **posns, int len,
} while (1);
leave_directory:
- if (o->dir)
- pop_exclude_per_directory(o->dir, i_stk);
return retval;
}
--
1.5.3.6.2064.g2e22f
^ permalink raw reply related
* Re: Adding push configuration to .git/config
From: Nico -telmich- Schottelius @ 2007-11-28 22:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711221120300.27959@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]
Hello guys,
I'm replying a bit late, had much to work in the last days.
I really like some ideas discussed here and want to state that
- "git push" without options is much easier and does nothing wrong,
if you configured the branch.$name.pushto correctly
- I also think that having support for multiple push destinations
per branch would be excellent for a distributed version control system
like git
- doing 'git push origin master:myremote/myname' just covers to much
redundant data, which imho can (but not must) be put into .git/config
- I don't care about the configuration names, we can even stick to
"merge" for now and add simply add "push" and rename them in git 2.x
I currently would like this variant mostly, allowing high flexibility:
--------------------------------------------------------------------------------
[remote "myremote"]
url = git+ssh://.... # no change
ref = refs/heads/ # renamed fetch = ...
# that way we can use the remote for fetch and push:
[branch "master"]
merge = myremote
push = myremote
push = anotherremote
[branch "otherbranch"]
merge = otherremote
push = otherremote
push = classmate
push = myremote
--------------------------------------------------------------------------------
What do you think about that approach?
Sincerly
Nico
--
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/
PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] Teach repack to optionally retain otherwise lost objects
From: Johannes Schindelin @ 2007-11-29 11:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vaboxy3va.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 28 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Besides, a completely different idea just struck me: before
> > repacking, .git/objects/pack/* could be _hard linked_ to the
> > forkee's object stores. Then nothing in git-repack's code
> > needs to be changed.
> >
> > Oh, well. I just wasted 1.5 hours.
>
> Your 1.5 hours was spent wisely to come up with that idea ;-).
Thanks ;-)
> To make sure I understand your idea correctly, the procedure to repack a
> repository in a fork-friendly way is:
>
> (1) find the project directly forked from you;
>
> (2) hardlink all packs under your object store to their object store;
>
> (3) repack -a -l and prune.
Yep.
> I think that would work as long as you do the above as a unit and handle
> one repository at a time.
Exactly. See
http://repo.or.cz/w/repo.git?a=commitdiff;h=fba501deabd349afbe3b8bf89f385889889e04ac
for a tired proposal.
Note that "prune" is not (yet) an option, since it could possibly destroy
objects which are needed in an ongoing push operation.
However, we could do exactly the same as with reflogs: introduce a grace
period (with loose objects, we can use the ctime...)
> Otherwise I think you risk losing necessary objects when hierarchical
> forks are involved. E.g. if you have a project X that has a fork Y
> which in turn has fork Z.
Well, in theory you could also iterate over all projects and hard link the
packs/objects of their alternates, and _then_ iterate and repack. But it
is simpler and more obvious in the case of repo.or.cz to do all in one
iteration, because we can order the repository names easily so that
forkees come first, _and_ we have an easy way to find out what are the
forks of a project.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)
From: Johannes Schindelin @ 2007-11-29 12:01 UTC (permalink / raw)
To: Jan Hudec; +Cc: Jakub Narebski, Shawn O. Pearce, git
In-Reply-To: <20071129065706.GA24070@efreet.light.src>
Hi,
On Thu, 29 Nov 2007, Jan Hudec wrote:
> On Wed, Nov 28, 2007 at 23:48:12 +0000, Johannes Schindelin wrote:
>
> > Furthermore, my complaint was not about a platform where neither C#
> > nor Python work. That is irrelevant. If you have one platform where
> > only one works, and another platform where only the other works, you
> > cannot have a single program for both platforms. Right?
>
> Right.
>
> I probably shouldn't be surprised that mono does not work on older unices,
> but I am a bit surprised python does not.
*Sigh* I managed again to make myself misunderstood.
Even if newer Python does not easily compile on that IRIX, I have an old
Python there (2.2). But I don't have any Python on MSys. (Yes, there is
a _MinGW_ port, but no _MSys_ one.) So for me, Python is out.
Hth,
Dscho
^ 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