* Re: Darcs
From: Linus Torvalds @ 2007-06-25 0:00 UTC (permalink / raw)
To: Dan Chokola; +Cc: Junio C Hamano, Martin Langhoff, Bu Bacoo, git
In-Reply-To: <61e816970706241638j60830741p2cd1a102a72ae226@mail.gmail.com>
On Sun, 24 Jun 2007, Dan Chokola wrote:
>
> What I have noticed is a lot of nitpicking, of which I'm guilty, too. The
> issue Linus brought up about Darcs and versioning is not one I typically see
> surface in real life. Users usually complain about some _release_ version
> or, "I updated last week."
Actually, in the kernel, we are getting quite a lot out of "git bisect",
and people throw git SHA1's around to describe where they are, or a
particular commit.
Which never happened with BK.
So I think that the _ability_ to name revisions easily across different
uses is quite important, because it then drives behaviour.
Without it, you'll never notice you need it. With it, you start wondering
how others handle it.
For example, we have people like Andrew, who don't really "use" git, and
he starts pointing to commits with their git ID, because he sees them
flying past, and he knows they are stable and useful for things like
gitweb.
Linus
^ permalink raw reply
* Re: problem pushing repository
From: Shawn O. Pearce @ 2007-06-24 23:47 UTC (permalink / raw)
To: Raimund Bauer; +Cc: Johannes Schindelin, Andrew Ruder, git
In-Reply-To: <1182593536.5937.14.camel@localhost>
Raimund Bauer <ray007@gmx.net> wrote:
> On Fri, 2007-06-22 at 18:47 -0400, Shawn O. Pearce wrote:
> > Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> > ---
> > contrib/completion/git-completion.bash | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
>
> Thanks a lot, your patch makes my life easier.
> Since you obviously know what you're doing here, maybe I can wish for
> something too?
Heh, sure. I wrote that "stock" bash completion package, but at
this point I largely consider it to be "complete and stable" and
therefore don't put a lot of effort into it anymore.
This recent thread has been interesting, as it has uncovered two
bugs related to the git-push completion.
> It would be really cool if completion also worked when I started the
> branchname with a '+' to force the push ...
How does this work? ;-)
I'm pushing it out to my fastimport tree shortly.
-->8--
Teach bash how to complete +refspec on git-push
Using `git push origin +foo` to forcefully overwrite the remote
branch named foo is a common idiom, especially since + is shorter
than the long option --force and can be specified on a per-branch
basis.
We now complete `git push origin +foo` just like we do the standard
`git push origin foo`. The leading + on a branch refspec does not
alter the completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/completion/git-completion.bash | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index c7c9963..f2b10fa 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -682,6 +682,9 @@ _git_push ()
esac
__gitcomp "$(__git_refs "$remote")" "" "${cur#*:}"
;;
+ +*)
+ __gitcomp "$(__git_refs)" + "${cur#+}"
+ ;;
*)
__gitcomp "$(__git_refs)"
;;
--
1.5.2.2.1334.g1625
--
Shawn.
^ permalink raw reply related
* Re: Darcs
From: Dan Chokola @ 2007-06-24 23:40 UTC (permalink / raw)
To: git
In-Reply-To: <61e816970706241638j60830741p2cd1a102a72ae226@mail.gmail.com>
Resent to the mailing list because my crappy mail client defaulted to
HTML. Sorry.
---------- Forwarded message ----------
From: Dan Chokola <dan@chokola.com>
Date: Jun 24, 2007 7:38 PM
Subject: Re: Darcs
To: Junio C Hamano <gitster@pobox.com>
Cc: Martin Langhoff <martin.langhoff@gmail.com>, Linus Torvalds
<torvalds@linux-foundation.org>, Bu Bacoo <bubacoo@gmail.com>,
git@vger.kernel.org
On 6/24/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
>
> >> "Academic".
> >
> > OTOH, and from the POV of someone closely following the SCM tools in
> > the last few years (and using almost all of them), darcs was the first
> > usable DSCM in the camp. I am not sure how much of its commandline
> > user interface was borrowed from BK or elsewhere, but darcs was
> > _easy_, where Arch was extremely hard to use.
>
> I second this. Before I started contributing to git in its
> early weeks, I staged my own changes to my day-job project in
> darcs to trickle them in to the company's central repository (I
> was sufficiently faster than other members of the project and I
> had to pace myself).
>
> It would have been much more difficult for me to grasp the basic
> concepts of how "distributed development" process works, if I
> did not have an exposure to Darcs before I started, especially
> because I never used BK.
This is an interesting thread. My own background with Git is that it's
the first SCM I've ever used. And it comes from XMMS2 being the first
open-source project I ever contributed back to. I joined shortly after
the kernel (and XMMS2 team, likewise) had switched from BitKeeper to
Git. So, as Linus said in his tech talk, "My brain didn't rot from
years of thinking CVS was doing something sane," and now I can't
imagine ever using a centralized SCM.
The interesting thing is that now I'm learning about all the other
distributed SCMs (most of which came before Git) now, after having
learned Git, so my experience is backwards from a lot of you. When I
first started, had I known about something like darcs, I probably
would have loved it much more than git, which was only usable to the
highest-level minds at first. I had to use cogito for almost
everything. But now it's as easy to use as its distributed friends and
so I don't think ease of use is much of an issue for anyone anymore.
What I have noticed is a lot of nitpicking, of which I'm guilty, too.
The issue Linus brought up about Darcs and versioning is not one I
typically see surface in real life. Users usually complain about some
_release_ version or, "I updated last week." The maintainer's reply is
almost always, "Between (release x.x.x|last week) and now we fixed
that problem, check out the latest source." While it could certainly
get annoying when trying to track down a very specific version, it's
not a make-or-break issue that's going to cause anyone to drop Darcs
and flock to Git.
I also saw another developer become upset about using Git over
Mercurial partly because of the lack of documentation on things like
the pack formats. And my own nitpick is that I would never use
Mercurial because it's slow and in Python (a language I despise). The
truth is there's a huge feature overlap between Git an Mecurial (as
well as Darcs and others) and the fundamental stuff remains constant.
In fact, I managed to clone, update, and diff some changes with
mercurial without ever reading any documentation.
Just thought I'd throw my observations in the ring instead of lurking
on the list. We'll see if any of it is relevant. :)
-Daniel "Puzzles" Chokola
^ permalink raw reply
* Re: [PATCH][RESEND] Escape some tilde characters causing spurious subscripts in documentation
From: Jason Sewall @ 2007-06-24 23:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v8xa9q9mb.fsf@assigned-by-dhcp.cox.net>
On 6/24/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Jason Sewall" <jasonsewall@gmail.com> writes:
>
> > I'd suggest that we put all inline revspecs inside $$...$$; this
> > "inline passthrough" quote obeys outside quoting,...
>
> Does that work with AsciiDoc 7?
I just downloaded AsciiDoc-7.2.1 and it seems to work fine (there are
some warnings missing tag definitions, but that's something else, I'm
pretty sure).
> > Is there a documentation 'style' file or something like that for git?
>
> Well, there isn't one as nobody really knows AsciiDoc well
> enough, and actually my message was to con you into writing one ;-).
>
I was afraid you were going to say that :)
I've wanted to contribute to this project for a while now, but I just
haven't had the time to familiarize myself with the codebase enough to
help out; I don't have to tell you that there's a lot of code in git,
and a fair amount of it is production-grade
'make-it-fast-screw-legibility' stuff that I'm not so good at reading
yet :p
So sure, I'll try to help out with this documentation stuff. I think
developing a style file and making the git docs conform to it would be
a good start.
To begin with:
1. What versions of Asciidoc are we interested in targeting? 7.0.2 and
up, or something else?
2. I think we should put all of the path, revspec stuff, and command
examples in monospace (grave quotes or plus delimiters) rather than
emphasis (single quotes) or what have you. This will make them
consistent with the way they are formatted in blocks. What's the
consensus?
The almost-markup-free nature of asciidoc does us more harm than good
in this particular case, since a little abstraction like
<revspec>HEAD^^</revspec> or whatever would let us just convert
everything and fight about presentation later.
Jason
^ permalink raw reply
* Re: [PATCH] diff: round down similarity index
From: Johannes Schindelin @ 2007-06-24 23:27 UTC (permalink / raw)
To: René Scharfe; +Cc: Junio C Hamano, David Kastrup, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0706250021250.4059@racer.site>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=utf-8, Size: 1068 bytes --]
Hi,
On Mon, 25 Jun 2007, Johannes Schindelin wrote:
> On Mon, 25 Jun 2007, René Scharfe wrote:
>
> > Rounding down the printed (dis)similarity index allows us to use
> > "100%" as a special value that indicates complete rewrites and
> > fully equal file contents, respectively.
> >
> > [...]
> >
> > +static int similarity_index(struct diff_filepair *p)
> > +{
> > + int result = p->score * 100.0 / MAX_SCORE;
> > +
> > + /* Paranoia: guard against floating point rounding errors. */
> > + if (p->score == MAX_SCORE)
> > + result = 100;
> > + else if (result == 100)
> > + result = 99;
> > +
> > + return result;
> > +}
>
> That's not even properly rounding down. The correct formula (correct in
> the sense for "what you want") would be
>
> p->score * 100.0 / MAX_SCORE
>
> if p->score == MAX_SCORE, iff the files are identical. And yes, that is
> the old formula.
Just ignore that, please.
> Besides, AFAIR p->score is not even calculated if the files are identical,
> because that hits a different code path.
But this still holds true.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] diff: round down similarity index
From: Johannes Schindelin @ 2007-06-24 23:25 UTC (permalink / raw)
To: René Scharfe; +Cc: Junio C Hamano, David Kastrup, Git Mailing List
In-Reply-To: <467EEEE6.3090100@lsrfire.ath.cx>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 904 bytes --]
Hi,
On Mon, 25 Jun 2007, René Scharfe wrote:
> Rounding down the printed (dis)similarity index allows us to use
> "100%" as a special value that indicates complete rewrites and
> fully equal file contents, respectively.
>
> [...]
>
> +static int similarity_index(struct diff_filepair *p)
> +{
> + int result = p->score * 100.0 / MAX_SCORE;
> +
> + /* Paranoia: guard against floating point rounding errors. */
> + if (p->score == MAX_SCORE)
> + result = 100;
> + else if (result == 100)
> + result = 99;
> +
> + return result;
> +}
That's not even properly rounding down. The correct formula (correct in
the sense for "what you want") would be
p->score * 100.0 / MAX_SCORE
if p->score == MAX_SCORE, iff the files are identical. And yes, that is
the old formula.
Besides, AFAIR p->score is not even calculated if the files are identical,
because that hits a different code path.
Ciao,
Dscho
^ permalink raw reply
* Re: Darcs
From: Linus Torvalds @ 2007-06-24 23:21 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Bu Bacoo, git
In-Reply-To: <46a038f90706241345m4b5ecb80p9f4ec840993023e0@mail.gmail.com>
On Mon, 25 Jun 2007, Martin Langhoff wrote:
>
> The darcs commandset (init, push, pull) is what git, hg and bzr have
> today in common.
I really think the credit goes to BK, not darcs.
BK is why a lot of git commands look like they do: I didn't want to
re-implement BK, but I definitely wanted to reimplement the flow. At least
for common stuff.
The fact that darcs may have been more usable than other open source scm's
says more about the other open source scm's than it says about darcs.
arch/tla in particular was (is?) horribly messy. I tried to look at it
before starting git, but even just a cursory look convinced me to look
away..
Linus
^ permalink raw reply
* Re: [PATCH] git-svnimport: added explicit merge graph option -G
From: Stas Maximov @ 2007-06-24 23:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 7497 bytes --]
Junio,
Below is what I got with
git-format-patch -p -M -s --stdout origin
I hope this is acceptable. I checked, I do not have a MUA which preserves whitespaces such that the result is suitable for applying the patch. So I am pasting the patch below for discussion and also attaching to be suitable for applying.
Stas.
>From fd83a4e003802b6cb4dc8a2d058310f235f65e17 Mon Sep 17 00:00:00 2001
From: Stas Maximov <smaximov@yahoo.com>
Date: Sat, 23 Jun 2007 09:06:30 -0700
Subject: [PATCH] git-svnimport: added explicit merge graph option -G
Allows explicit merge graph information to be provided. Each line
of merge graph file must contain a pair of SVN revision numbers
separated by space. The first number is child (merged to) SVN rev
number and the second is the parent (merged from) SVN rev number.
Comments can be started with '#' and continue to the end of line.
Empty and space-only lines are allowed and will be ignored.
Signed-off-by: Stas Maximov <smaximov@yahoo.com>
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
old mode 100644
new mode 100755
index e97d15e..c902b64
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -13,7 +13,8 @@ SYNOPSIS
'git-svnimport' [ -o <branch-for-HEAD> ] [ -h ] [ -v ] [ -d | -D ]
[ -C <GIT_repository> ] [ -i ] [ -u ] [-l limit_rev]
[ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]
- [ -s start_chg ] [ -m ] [ -r ] [ -M regex ]
+ [ -s start_chg ] [ -r ]
+ [ -m ] [ -M regex ] [-G merge_graph_file ]
[ -I <ignorefile_name> ] [ -A <author_file> ]
[ -R <repack_each_revs>] [ -P <path_from_trunk> ]
<SVN_repository_URL> [ <path> ]
@@ -102,6 +103,14 @@ repository without -A.
regex. It can be used with -m to also see the default regexes.
You must escape forward slashes.
+-G <merge_graph_file>::
+ Allows explicit merge graph information to be provided. Each line
+ of merge graph file must contain a pair of SVN revision numbers
+ separated by space. The first number is child (merged to) SVN rev
+ number and the second is the parent (merged from) SVN rev number.
+ Comments can be started with '#' and continue to the end of line.
+ Empty and space-only lines are allowed and will be ignored.
+
-l <max_rev>::
Specify a maximum revision number to pull.
+
diff --git a/git-svnimport.perl b/git-svnimport.perl
index f459762..113b252 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -32,7 +32,7 @@ $ENV{'TZ'}="UTC";
our($opt_h,$opt_o,$opt_v,$opt_u,$opt_C,$opt_i,$opt_m,$opt_M,$opt_t,$opt_T,
$opt_b,$opt_r,$opt_I,$opt_A,$opt_s,$opt_l,$opt_d,$opt_D,$opt_S,$opt_F,
- $opt_P,$opt_R);
+ $opt_P,$opt_R,$opt_G);
sub usage() {
print STDERR <<END;
@@ -40,12 +40,13 @@ Usage: ${\basename $0} # fetch/update GIT from SVN
[-o branch-for-HEAD] [-h] [-v] [-l max_rev] [-R repack_each_revs]
[-C GIT_repository] [-t tagname] [-T trunkname] [-b branchname]
[-d|-D] [-i] [-u] [-r] [-I ignorefilename] [-s start_chg]
- [-m] [-M regex] [-A author_file] [-S] [-F] [-P project_name] [SVN_URL]
+ [-m] [-M regex] [-G merge_graph_file] [-A author_file]
+ [-S] [-F] [-P project_name] [SVN_URL]
END
exit(1);
}
-getopts("A:b:C:dDFhiI:l:mM:o:rs:t:T:SP:R:uv") or usage();
+getopts("A:b:C:dDFhiI:l:mM:G:o:rs:t:T:SP:R:uv") or usage();
usage if $opt_h;
my $tag_name = $opt_t || "tags";
@@ -80,6 +81,39 @@ if ($opt_M) {
unshift (@mergerx, qr/$opt_M/);
}
+
+# merge_graph will be used for finding all parent SVN revisions for a given SVN
+# revision. It will be implemented as a hash of hashes. First level hash will
+# be keyed with the child SVN rev and contain a hash keyed with the parent SVN
+# revisions. Values of the second level hash are not important (1 will be
+# used). The keys will be used to store the parent revs for uniqueness.
+our %merge_graph;
+
+
+# read-in the explicit merge graph specified with -G option
+if ($opt_G) {
+ open(F,"cat $opt_G | sed -e 's/#.*\$//' -e '/^\$/d' |") or
+ die("Can not open $opt_G");
+ while(<F>) {
+ chomp;
+ die "ERROR: invalid line in $opt_G: $_" unless /^\s*(\d+)\s+(\d+)\s*$/;
+ # $merge_graph{child_rev}{parent_rev} = 1;
+ $merge_graph{$1}{$2} = 1;
+ }
+ close(F);
+}
+
+
+# Given an SVN revision (string), finds all its parent SVN revisions in the
+# merge graph.
+sub merge_graph_get_parents($)
+{
+ my $child_svnrev = shift;
+ my @parents = keys(%{$merge_graph{$child_svnrev}});
+ return @parents;
+}
+
+
# Absolutize filename now, since we will have chdir'ed by the time we
# get around to opening it.
$opt_A = File::Spec->rel2abs($opt_A) if $opt_A;
@@ -356,6 +390,24 @@ if ($opt_A) {
open BRANCHES,">>", "$git_dir/svn2git";
+
+# Given an SVN revision (string), returns all corresponding GIT revisions.
+#
+# Note that it is possible that one SVN revision needs to be split into two or
+# more GIT commits (revision). For example, this will happen if SVN user
+# commits two branches at once.
+sub svnrev_to_gitrevs($)
+{
+ my $svnrev = shift;
+ my @gitrevs;
+ for my $b (keys(%branches)) {
+ push (@gitrevs, $branches{$b}{$svnrev})
+ if defined($branches{$b}{$svnrev});
+ }
+ return @gitrevs;
+}
+
+
sub node_kind($$) {
my ($svnpath, $revision) = @_;
my $pool=SVN::Pool->new;
@@ -815,6 +867,19 @@ sub commit {
}
}
}
+
+ # add parents from explicit merge graph (-G)
+ {
+ my @svnpars = merge_graph_get_parents($revision);
+ foreach my $svnp (@svnpars) {
+ my @gitpars = svnrev_to_gitrevs($svnp);
+ foreach my $gitp (@gitpars) {
+ push (@parents, $gitp);
+ #print OUT "MG: $svnp -merge-> $revision\n";
+ }
+ }
+ }
+
my %seen_parents = ();
my @unique_parents = grep { ! $seen_parents{$_} ++ } @parents;
foreach my $bparent (@unique_parents) {
--
1.5.1.3
>From 7008a13f1fe00fdbd90be6a12ad1197dceedaebb Mon Sep 17 00:00:00 2001
From: Stas Maximov <smaximov@yahoo.com>
Date: Sun, 24 Jun 2007 14:23:29 -0700
Subject: [PATCH] Fixed permissions of Documentation/git-svnimport.txt
Signed-off-by: Stas Maximov <smaximov@yahoo.com>
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
old mode 100755
new mode 100644
--
1.5.1.3
----- Original Message ----
From: Junio C Hamano <gitster@pobox.com>
To: Stas Maximov <smaximov@yahoo.com>
Cc: git@vger.kernel.org; Peter Baumann <waste.manager@gmx.de>
Sent: Sunday, June 24, 2007 3:17:05 PM
Subject: Re: [PATCH] git-svnimport: added explicit merge graph option -G
Stas Maximov <smaximov@yahoo.com> writes:
> Attached are two patches:
>
> 1. resubmission of the original patch with proper sign-off; and
> 2. patch with permissions fix (thanks to Alex Reisen for pointing out);
As you are assuming that the original patch was rejected (by
resending that as the first one here), I do not think these
changes should be in two separate commits. Please redo them as
a single patch.
Also please do not "Attach". When you have N patches to send,
send N e-mail messages, numbered from [PATCH 1/N] to [PATCH
N/N], each with one patch in the message itself.
Please see Documentation/SubmittingPatches.
[-- Attachment #2: 0001-git-svnimport-added-explicit-merge-graph-option-G.patch --]
[-- Type: application/octet-stream, Size: 6094 bytes --]
From fd83a4e003802b6cb4dc8a2d058310f235f65e17 Mon Sep 17 00:00:00 2001
From: Stas Maximov <smaximov@yahoo.com>
Date: Sat, 23 Jun 2007 09:06:30 -0700
Subject: [PATCH] git-svnimport: added explicit merge graph option -G
Allows explicit merge graph information to be provided. Each line
of merge graph file must contain a pair of SVN revision numbers
separated by space. The first number is child (merged to) SVN rev
number and the second is the parent (merged from) SVN rev number.
Comments can be started with '#' and continue to the end of line.
Empty and space-only lines are allowed and will be ignored.
Signed-off-by: Stas Maximov <smaximov@yahoo.com>
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
old mode 100644
new mode 100755
index e97d15e..c902b64
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -13,7 +13,8 @@ SYNOPSIS
'git-svnimport' [ -o <branch-for-HEAD> ] [ -h ] [ -v ] [ -d | -D ]
[ -C <GIT_repository> ] [ -i ] [ -u ] [-l limit_rev]
[ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]
- [ -s start_chg ] [ -m ] [ -r ] [ -M regex ]
+ [ -s start_chg ] [ -r ]
+ [ -m ] [ -M regex ] [-G merge_graph_file ]
[ -I <ignorefile_name> ] [ -A <author_file> ]
[ -R <repack_each_revs>] [ -P <path_from_trunk> ]
<SVN_repository_URL> [ <path> ]
@@ -102,6 +103,14 @@ repository without -A.
regex. It can be used with -m to also see the default regexes.
You must escape forward slashes.
+-G <merge_graph_file>::
+ Allows explicit merge graph information to be provided. Each line
+ of merge graph file must contain a pair of SVN revision numbers
+ separated by space. The first number is child (merged to) SVN rev
+ number and the second is the parent (merged from) SVN rev number.
+ Comments can be started with '#' and continue to the end of line.
+ Empty and space-only lines are allowed and will be ignored.
+
-l <max_rev>::
Specify a maximum revision number to pull.
+
diff --git a/git-svnimport.perl b/git-svnimport.perl
index f459762..113b252 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -32,7 +32,7 @@ $ENV{'TZ'}="UTC";
our($opt_h,$opt_o,$opt_v,$opt_u,$opt_C,$opt_i,$opt_m,$opt_M,$opt_t,$opt_T,
$opt_b,$opt_r,$opt_I,$opt_A,$opt_s,$opt_l,$opt_d,$opt_D,$opt_S,$opt_F,
- $opt_P,$opt_R);
+ $opt_P,$opt_R,$opt_G);
sub usage() {
print STDERR <<END;
@@ -40,12 +40,13 @@ Usage: ${\basename $0} # fetch/update GIT from SVN
[-o branch-for-HEAD] [-h] [-v] [-l max_rev] [-R repack_each_revs]
[-C GIT_repository] [-t tagname] [-T trunkname] [-b branchname]
[-d|-D] [-i] [-u] [-r] [-I ignorefilename] [-s start_chg]
- [-m] [-M regex] [-A author_file] [-S] [-F] [-P project_name] [SVN_URL]
+ [-m] [-M regex] [-G merge_graph_file] [-A author_file]
+ [-S] [-F] [-P project_name] [SVN_URL]
END
exit(1);
}
-getopts("A:b:C:dDFhiI:l:mM:o:rs:t:T:SP:R:uv") or usage();
+getopts("A:b:C:dDFhiI:l:mM:G:o:rs:t:T:SP:R:uv") or usage();
usage if $opt_h;
my $tag_name = $opt_t || "tags";
@@ -80,6 +81,39 @@ if ($opt_M) {
unshift (@mergerx, qr/$opt_M/);
}
+
+# merge_graph will be used for finding all parent SVN revisions for a given SVN
+# revision. It will be implemented as a hash of hashes. First level hash will
+# be keyed with the child SVN rev and contain a hash keyed with the parent SVN
+# revisions. Values of the second level hash are not important (1 will be
+# used). The keys will be used to store the parent revs for uniqueness.
+our %merge_graph;
+
+
+# read-in the explicit merge graph specified with -G option
+if ($opt_G) {
+ open(F,"cat $opt_G | sed -e 's/#.*\$//' -e '/^\$/d' |") or
+ die("Can not open $opt_G");
+ while(<F>) {
+ chomp;
+ die "ERROR: invalid line in $opt_G: $_" unless /^\s*(\d+)\s+(\d+)\s*$/;
+ # $merge_graph{child_rev}{parent_rev} = 1;
+ $merge_graph{$1}{$2} = 1;
+ }
+ close(F);
+}
+
+
+# Given an SVN revision (string), finds all its parent SVN revisions in the
+# merge graph.
+sub merge_graph_get_parents($)
+{
+ my $child_svnrev = shift;
+ my @parents = keys(%{$merge_graph{$child_svnrev}});
+ return @parents;
+}
+
+
# Absolutize filename now, since we will have chdir'ed by the time we
# get around to opening it.
$opt_A = File::Spec->rel2abs($opt_A) if $opt_A;
@@ -356,6 +390,24 @@ if ($opt_A) {
open BRANCHES,">>", "$git_dir/svn2git";
+
+# Given an SVN revision (string), returns all corresponding GIT revisions.
+#
+# Note that it is possible that one SVN revision needs to be split into two or
+# more GIT commits (revision). For example, this will happen if SVN user
+# commits two branches at once.
+sub svnrev_to_gitrevs($)
+{
+ my $svnrev = shift;
+ my @gitrevs;
+ for my $b (keys(%branches)) {
+ push (@gitrevs, $branches{$b}{$svnrev})
+ if defined($branches{$b}{$svnrev});
+ }
+ return @gitrevs;
+}
+
+
sub node_kind($$) {
my ($svnpath, $revision) = @_;
my $pool=SVN::Pool->new;
@@ -815,6 +867,19 @@ sub commit {
}
}
}
+
+ # add parents from explicit merge graph (-G)
+ {
+ my @svnpars = merge_graph_get_parents($revision);
+ foreach my $svnp (@svnpars) {
+ my @gitpars = svnrev_to_gitrevs($svnp);
+ foreach my $gitp (@gitpars) {
+ push (@parents, $gitp);
+ #print OUT "MG: $svnp -merge-> $revision\n";
+ }
+ }
+ }
+
my %seen_parents = ();
my @unique_parents = grep { ! $seen_parents{$_} ++ } @parents;
foreach my $bparent (@unique_parents) {
--
1.5.1.3
From 7008a13f1fe00fdbd90be6a12ad1197dceedaebb Mon Sep 17 00:00:00 2001
From: Stas Maximov <smaximov@yahoo.com>
Date: Sun, 24 Jun 2007 14:23:29 -0700
Subject: [PATCH] Fixed permissions of Documentation/git-svnimport.txt
Signed-off-by: Stas Maximov <smaximov@yahoo.com>
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
old mode 100755
new mode 100644
--
1.5.1.3
^ permalink raw reply related
* Re: qgit: Annotate hundreds of files at terrific speed ;-)
From: Shawn O. Pearce @ 2007-06-24 23:08 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550706230935m5363a6dava9dbd62a56a1b685@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> wrote:
> You get _all_ the hundreds (more then 800) of revisions of this
> monster history annotated in the time it takes *other* ;-) tools to
By "other tools" do you mean git-blame? ;-)
--
Shawn.
^ permalink raw reply
* Re: cloning empty repo
From: Shawn O. Pearce @ 2007-06-24 23:01 UTC (permalink / raw)
To: Marijn Schouten (hkBst); +Cc: git
In-Reply-To: <467E8808.7030903@gentoo.org>
"Marijn Schouten (hkBst)" <hkBst@gentoo.org> wrote:
> is there any reason why cloning an empty repository should result in an error
> instead of a succesfully cloned empty repo?
There's nothing to clone. The repository is empty.
If you create a Git repository using `git init` and then create
another one also using `git init` then both repositories are empty,
and an empty repository is identical to every other empty repository.
So if you want to setup an empty repository and then clone nothing,
you actually can just setup another empty repository and configure
the 'origin' remote:
mkdir a; cd a; git init; cd ..
mkdir b; cd b; git init
# now a and b are identical
git remote add origin ../a/.git
# now b is a "clone" of a's nothingness...
--
Shawn.
^ permalink raw reply
* Re: fastimport pull request
From: Shawn O. Pearce @ 2007-06-24 22:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6o1ouv9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> wrote:
> I had an impression from reading #git log and mailing list
> traffic, that you guys were afraid that the development history,
> and especially the commit log messages on this branch, were, eh,
> less than optimal. So I got curious and took a look --- it does
> not look too bad. It is a nontrivial amount of code (1.5k lines
> of Python) and is understandable to have meaningful history
> behind it.
That was true of the first version of the branch offered up by Simon.
After my initial reply Simon cleaned up the history and made many
of the messages more meaningful, and added SBO lines to them.
So the history you saw when you pulled was much improved over the
original version we were discussing on the list.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Add core.quotepath configuration variable.
From: Junio C Hamano @ 2007-06-24 22:30 UTC (permalink / raw)
To: git; +Cc: David Kastrup, Robin Rosenberg, Johannes Schindelin
In-Reply-To: <7v1wg1q9i2.fsf@assigned-by-dhcp.cox.net>
OOPS.
Sorry about the gotcha. Because I did not force the MUA to use
UTF-8, it silently converted the patch to ISO-2022. Too
friendly to be useful crap...
^ permalink raw reply
* DWIM ref names for push/fetch
From: Daniel Barkalow @ 2007-06-24 22:25 UTC (permalink / raw)
To: git
AFAICT, the rules are currently:
for push, we compare the source against the list of local refs, and do
some complicated stuff to figure out what it matches. Then we compare the
destination against the list of remote refs (with no destination being
interpreted as the full name of the source), and do the same complicated
stuff.
for fetch, we accept anything that starts with "refs/heads/",
"refs/tags/", or "refs/remotes/"; prepend "refs/" to anything that starts
with "heads/", "tags/", or "remotes/"; and prepend "refs/heads/" to
anything else. (NB: I'm looking at Julian's C translation, rather than the
original shell scripts, which I find inpenetrable).
Is this difference simply due to the different languages the matching
portions of these were originally written in? Would it be okay to change
fetch to work like push? It would be nice to have a single procedure for
determining which (if any) of a list of refs is the match for some string,
regardless of why we're looking.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] diff: round down similarity index
From: René Scharfe @ 2007-06-24 22:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Kastrup, Johannes Schindelin, Git Mailing List
Rounding down the printed (dis)similarity index allows us to use
"100%" as a special value that indicates complete rewrites and
fully equal file contents, respectively.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
The added documentation is only correct if you apply the
diffcore-rename patch, too.
Documentation/diff-format.txt | 7 +++++++
diff.c | 30 +++++++++++++++++++-----------
2 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index 18d49d2..0015032 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -126,6 +126,13 @@ the file that rename/copy produces, respectively.
If there is need for such substitution then the whole
pathname is put in double quotes.
+The similarity index is the percentage of unchanged lines, and
+the dissimilarity index is the percentage of changed lines. It
+is a rounded down integer, followed by a percent sign. The
+similarity index value of 100% is thus reserved for two equal
+files, while 100% dissimilarity means that no line from the old
+file made it into the new one.
+
combined diff format
--------------------
diff --git a/diff.c b/diff.c
index 4aa9bbc..f1db55d 100644
--- a/diff.c
+++ b/diff.c
@@ -1813,6 +1813,19 @@ static void diff_fill_sha1_info(struct diff_filespec *one)
hashclr(one->sha1);
}
+static int similarity_index(struct diff_filepair *p)
+{
+ int result = p->score * 100.0 / MAX_SCORE;
+
+ /* Paranoia: guard against floating point rounding errors. */
+ if (p->score == MAX_SCORE)
+ result = 100;
+ else if (result == 100)
+ result = 99;
+
+ return result;
+}
+
static void run_diff(struct diff_filepair *p, struct diff_options *o)
{
const char *pgm = external_diff();
@@ -1847,23 +1860,20 @@ static void run_diff(struct diff_filepair *p, struct diff_options *o)
"similarity index %d%%\n"
"copy from %s\n"
"copy to %s\n",
- (int)(0.5 + p->score * 100.0/MAX_SCORE),
- name_munged, other_munged);
+ similarity_index(p), name_munged, other_munged);
break;
case DIFF_STATUS_RENAMED:
len += snprintf(msg + len, sizeof(msg) - len,
"similarity index %d%%\n"
"rename from %s\n"
"rename to %s\n",
- (int)(0.5 + p->score * 100.0/MAX_SCORE),
- name_munged, other_munged);
+ similarity_index(p), name_munged, other_munged);
break;
case DIFF_STATUS_MODIFIED:
if (p->score) {
len += snprintf(msg + len, sizeof(msg) - len,
"dissimilarity index %d%%\n",
- (int)(0.5 + p->score *
- 100.0/MAX_SCORE));
+ similarity_index(p));
complete_rewrite = 1;
break;
}
@@ -2385,8 +2395,7 @@ static void diff_flush_raw(struct diff_filepair *p,
}
if (p->score)
- sprintf(status, "%c%03d", p->status,
- (int)(0.5 + p->score * 100.0/MAX_SCORE));
+ sprintf(status, "%c%03d", p->status, similarity_index(p));
else {
status[0] = p->status;
status[1] = 0;
@@ -2668,8 +2677,7 @@ static void show_rename_copy(const char *renamecopy, struct diff_filepair *p)
{
char *names = pprint_rename(p->one->path, p->two->path);
- printf(" %s %s (%d%%)\n", renamecopy, names,
- (int)(0.5 + p->score * 100.0/MAX_SCORE));
+ printf(" %s %s (%d%%)\n", renamecopy, names, similarity_index(p));
free(names);
show_mode_change(p, 0);
}
@@ -2693,7 +2701,7 @@ static void diff_summary(struct diff_filepair *p)
if (p->score) {
char *name = quote_one(p->two->path);
printf(" rewrite %s (%d%%)\n", name,
- (int)(0.5 + p->score * 100.0/MAX_SCORE));
+ similarity_index(p));
free(name);
show_mode_change(p, 0);
} else show_mode_change(p, 1);
^ permalink raw reply related
* [PATCH] diffcore-rename: don't change similarity index based on basename equality
From: René Scharfe @ 2007-06-24 22:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List, David Kastrup
This implements a suggestion from Johannes. It uses a separate field in
struct diff_score to keep the result of the file name comparison in the
rename detection logic. This reverts the value of the similarity index
to be a function of file contents, only, and basename comparison is only
used to decide between files with equal amounts of content changes.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
diffcore-rename.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 79c984c..e0a89f3 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -138,6 +138,7 @@ struct diff_score {
int src; /* index in rename_src */
int dst; /* index in rename_dst */
int score;
+ int name_score;
};
static int estimate_similarity(struct diff_filespec *src,
@@ -201,11 +202,8 @@ static int estimate_similarity(struct diff_filespec *src,
*/
if (!dst->size)
score = 0; /* should not happen */
- else {
+ else
score = (int)(src_copied * MAX_SCORE / max_size);
- if (basename_same(src, dst))
- score++;
- }
return score;
}
@@ -242,6 +240,10 @@ static void record_rename_pair(int dst_index, int src_index, int score)
static int score_compare(const void *a_, const void *b_)
{
const struct diff_score *a = a_, *b = b_;
+
+ if (a->score == b->score)
+ return b->name_score - a->name_score;
+
return b->score - a->score;
}
@@ -360,6 +362,7 @@ void diffcore_rename(struct diff_options *options)
m->dst = i;
m->score = estimate_similarity(one, two,
minimum_score);
+ m->name_score = basename_same(one, two);
diff_free_filespec_data(one);
}
/* We do not need the text anymore */
^ permalink raw reply related
* Re: 100%
From: René Scharfe @ 2007-06-24 22:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Kastrup, git
In-Reply-To: <Pine.LNX.4.64.0706231318180.4059@racer.site>
Johannes Schindelin schrieb:
> Hi,
>
> On Sat, 23 Jun 2007, René Scharfe wrote:
>
>> As I already hinted at, the common result of comparing two files, as
>> done by e.g. cmp(1), is one bit that indicates equality. This
>> information is lost when using up/down rounding, but it is retained when
>> rounding down. It's _not_ common to be unable to determine equality
>> from the result of a file compare.
>
> And as _I_ already hinted, this does not matter. The whole purpose to have
> a number here instead of a bit is to have a larger range. In practice, I
> bet that the 100% are really uninteresting. At least here, they are.
You would lose your bet since both David and me expressed interest in
that pure 100% thing.
Rounding down instead of up/down doesn't affect the size of neither the
input nor the output range. It affects the boundary of the input range,
(-0.499 .. 100.499 versus 0.000 .. 100.999), but I can't find a problem
with that.
> For example, if you move a Java class from one package into another, you
> have to change the package name in the file. Guess what, I am perfectly
> okay if the rename detector says "100% similarity" here. Because if it is
> closer to 100% than to 99%, dammit, I want to see 100%, not 99%.
That uses a side effect of rounding and won't work for small files. And
of course (if the file is large enough) there could be other changes
"hidden" in a similarity index value of 100% that was rounded up.
> Nuff said about this subject.
Yes, let's advance this topic to the coding stage.
René
^ permalink raw reply
* Re: Darcs
From: Junio C Hamano @ 2007-06-24 22:22 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Linus Torvalds, Bu Bacoo, git
In-Reply-To: <46a038f90706241345m4b5ecb80p9f4ec840993023e0@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
>> "Academic".
>
> OTOH, and from the POV of someone closely following the SCM tools in
> the last few years (and using almost all of them), darcs was the first
> usable DSCM in the camp. I am not sure how much of its commandline
> user interface was borrowed from BK or elsewhere, but darcs was
> _easy_, where Arch was extremely hard to use.
I second this. Before I started contributing to git in its
early weeks, I staged my own changes to my day-job project in
darcs to trickle them in to the company's central repository (I
was sufficiently faster than other members of the project and I
had to pace myself).
It would have been much more difficult for me to grasp the basic
concepts of how "distributed development" process works, if I
did not have an exposure to Darcs before I started, especially
because I never used BK.
^ permalink raw reply
* Re: fastimport pull request
From: Junio C Hamano @ 2007-06-24 22:22 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070622232458.GK17393@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> The following changes since commit 45fd8bd32dd68ce6b14a406d0abbd6f56490131c:
> Ismail Dönmez (1):
> Change default man page path to /usr/share/man
>
> are available in the git repository at:
>
> repo.or.cz:/srv/git/git/fastimport.git master
>
> and are intended for your master branch, aka the 1.5.3 series.
>
> Shawn O. Pearce (2):
> Avoid src:dst syntax as default bash completion for git push
> Import branch 'git-p4' of git://repo.or.cz/fast-export
>
> Yes, that's right, I pulled in Simon's git-p4 work. :-)
>
> Benjamin Sergeant (1): ...
> Han-Wen Nienhuys (30): ...
> Kevin Green (1): ...
> Marius Storm-Olsen (7): ...
> Simon Hausmann (222): ...
I had an impression from reading #git log and mailing list
traffic, that you guys were afraid that the development history,
and especially the commit log messages on this branch, were, eh,
less than optimal. So I got curious and took a look --- it does
not look too bad. It is a nontrivial amount of code (1.5k lines
of Python) and is understandable to have meaningful history
behind it.
Pulled, and pushed out.
^ permalink raw reply
* [PATCH] Add core.quotepath configuration variable.
From: Junio C Hamano @ 2007-06-24 22:21 UTC (permalink / raw)
To: git; +Cc: David Kastrup, Robin Rosenberg, Johannes Schindelin
We always quote "unusual" byte values in a pathname using
C-string style, to make it safer for parsing scripts that do not
handle NUL separated records well (or just too lazy to bother).
The absolute minimum bytes that need to be quoted for this
purpose are TAB, LF (and other control characters), double quote
and backslash.
However, we have also always quoted the bytes in high 8-bit
range; this was partly because we were lazy and partly because
we were being cautious.
This introduces an internal "quote_path_fully" variable, and
core.quotepath configuration variable to control it. When set
to false, it does not quote bytes in high 8-bit range anymore
but passes them intact.
The variable defaults to "true" to retain the traditional
behaviour for now. Maybe in later versions of git we might want
to change the default to false, so people need to explicitly ask
for safer quoting. But that would be for a separate patch in
different timeframe.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/config.txt | 12 ++++
cache.h | 1 +
config.c | 5 ++
environment.c | 1 +
quote.c | 5 +-
t/t3902-quoted.sh | 126 ++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 148 insertions(+), 2 deletions(-)
create mode 100755 t/t3902-quoted.sh
diff --git a/Documentation/config.txt b/Documentation/config.txt
index a2057d9..34b1c97 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -117,6 +117,18 @@ core.fileMode::
the working copy are ignored; useful on broken filesystems like FAT.
See gitlink:git-update-index[1]. True by default.
+core.quotepath::
+ The commands that output paths (e.g. `ls-files`,
+ `diff`), when not given the `-z` option, will quote
+ "unusual" characters in the pathname by enclosing the
+ pathname in a double-quote pair and with backslashes the
+ same way strings in C source code are quoted. If this
+ variable is set to false, the bytes higher than 0x80 are
+ not quoted but output as verbatim. Note that double
+ quote, backslash and control characters are always
+ quoted without `-z` regardless of the setting of this
+ variable.
+
core.autocrlf::
If true, makes git convert `CRLF` at the end of lines in text files to
`LF` when reading from the filesystem, and convert in reverse when
diff --git a/cache.h b/cache.h
index ed83d92..6776357 100644
--- a/cache.h
+++ b/cache.h
@@ -292,6 +292,7 @@ extern int delete_ref(const char *, const unsigned char *sha1);
/* Environment bits from configuration mechanism */
extern int trust_executable_bit;
+extern int quote_path_fully;
extern int has_symlinks;
extern int assume_unchanged;
extern int prefer_symlink_refs;
diff --git a/config.c b/config.c
index e323153..4de8926 100644
--- a/config.c
+++ b/config.c
@@ -271,6 +271,11 @@ int git_default_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.quotepath")) {
+ quote_path_fully = git_config_bool(var, value);
+ return 0;
+ }
+
if (!strcmp(var, "core.symlinks")) {
has_symlinks = git_config_bool(var, value);
return 0;
diff --git a/environment.c b/environment.c
index 8b9b89d..1c2773f 100644
--- a/environment.c
+++ b/environment.c
@@ -12,6 +12,7 @@
char git_default_email[MAX_GITNAME];
char git_default_name[MAX_GITNAME];
int trust_executable_bit = 1;
+int quote_path_fully = 1;
int has_symlinks = 1;
int assume_unchanged;
int prefer_symlink_refs;
diff --git a/quote.c b/quote.c
index aa44009..d88bf75 100644
--- a/quote.c
+++ b/quote.c
@@ -188,7 +188,8 @@ static int quote_c_style_counted(const char *name, int namelen,
#define EMITQ() EMIT('\\')
const char *sp;
- int ch, count = 0, needquote = 0;
+ unsigned char ch;
+ int count = 0, needquote = 0;
if (!no_dq)
EMIT('"');
@@ -197,7 +198,7 @@ static int quote_c_style_counted(const char *name, int namelen,
if (!ch)
break;
if ((ch < ' ') || (ch == '"') || (ch == '\\') ||
- (ch >= 0177)) {
+ (quote_path_fully && (ch >= 0177))) {
needquote = 1;
switch (ch) {
case '\a': EMITQ(); ch = 'a'; break;
diff --git a/t/t3902-quoted.sh b/t/t3902-quoted.sh
new file mode 100755
index 0000000..63f950b
--- /dev/null
+++ b/t/t3902-quoted.sh
@@ -0,0 +1,126 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Junio C Hamano
+#
+
+test_description='quoted output'
+
+. ./test-lib.sh
+
+FN='濱野'
+GN='純'
+HT=' '
+LF='
+'
+DQ='"'
+
+for_each_name () {
+ for name in \
+ Name "Name and a${LF}LF" "Name and an${HT}HT" "Name${DQ}" \
+ "$FN$HT$GN" "$FN$LF$GN" "$FN $GN" "$FN$GN" "$FN$DQ$GN" \
+ "With SP in it"
+ do
+ eval "$1"
+ done
+}
+
+test_expect_success setup '
+
+ for_each_name "echo initial >\"\$name\""
+ git add . &&
+ git commit -q -m Initial &&
+
+ for_each_name "echo second >\"\$name\"" &&
+ git commit -a -m Second
+
+ for_each_name "echo modified >\"\$name\""
+
+'
+
+cat >expect.quoted <<\EOF
+Name
+"Name and a\nLF"
+"Name and an\tHT"
+"Name\""
+With SP in it
+"\346\277\261\351\207\216\t\347\264\224"
+"\346\277\261\351\207\216\n\347\264\224"
+"\346\277\261\351\207\216 \347\264\224"
+"\346\277\261\351\207\216\"\347\264\224"
+"\346\277\261\351\207\216\347\264\224"
+EOF
+
+cat >expect.raw <<\EOF
+Name
+"Name and a\nLF"
+"Name and an\tHT"
+"Name\""
+With SP in it
+"濱野\t純"
+"濱野\n純"
+濱野 純
+"濱野\"純"
+濱野純
+EOF
+
+test_expect_success 'check fully quoted output from ls-files' '
+
+ git ls-files >current && diff -u expect.quoted current
+
+'
+
+test_expect_success 'check fully quoted output from diff-files' '
+
+ git diff --name-only >current &&
+ diff -u expect.quoted current
+
+'
+
+test_expect_success 'check fully quoted output from diff-index' '
+
+ git diff --name-only HEAD >current &&
+ diff -u expect.quoted current
+
+'
+
+test_expect_success 'check fully quoted output from diff-tree' '
+
+ git diff --name-only HEAD^ HEAD >current &&
+ diff -u expect.quoted current
+
+'
+
+test_expect_success 'setting core.quotepath' '
+
+ git config --bool core.quotepath false
+
+'
+
+test_expect_success 'check fully quoted output from ls-files' '
+
+ git ls-files >current && diff -u expect.raw current
+
+'
+
+test_expect_success 'check fully quoted output from diff-files' '
+
+ git diff --name-only >current &&
+ diff -u expect.raw current
+
+'
+
+test_expect_success 'check fully quoted output from diff-index' '
+
+ git diff --name-only HEAD >current &&
+ diff -u expect.raw current
+
+'
+
+test_expect_success 'check fully quoted output from diff-tree' '
+
+ git diff --name-only HEAD^ HEAD >current &&
+ diff -u expect.raw current
+
+'
+
+test_done
--
1.5.2.2.1334.g1625
^ permalink raw reply related
* Re: [PATCH] transplant: move a series of commits to a different parent
From: Alex Riesen @ 2007-06-24 22:20 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <6382A127-7A81-4ADE-B2C1-1FCCBE9EA239@zib.de>
Steffen Prohaska, Sun, Jun 24, 2007 22:54:21 +0200:
> I don't see how I can avoid tree diffs. As I pointed out earlier I need
> to mix the tree of the base commit of the newly built branch with
> files that were changed in the series of commits that I'm transplanting.
Hmm...
> Just taking the whole tree from the commits I'm transplanting is
> _wrong_.
> I need to only take files that were touched by a commit. The tree of
> the tip of the resulting branch can be quite different from the tree
> of the tip of the original branch.
I see.
> >As to perfomance: read-tree doesn't actually _read_ the blobs to
> >populate index, just the trees. And diff-tree has do do the same, but
> >also _compare_ two trees recursively: more work, more memory needed.
>
> I'm still pretty convinced that I need tree diffs (not file diffs!).
"git-read-tree --reset" does an in-index merge (just discards unmerged
entries), so it still is better then git-diff-tree. But remove that
unlink, so that the previuos tree is not discarded and do a
"git-read-tree $onto" before starting the loop.
> Anyway, the script worked for me and I still think it may be useful for
> fixing broken repositories resulting from a wrong cvsimport. I would
> probably improve many details if someone else considered my work useful.
> But up to now it seems as if I failed to explain, why the script would
> be needed in the first place.
>
> However, the best way would be to fix git-cvsimport to handle branches
> correctly independently of the time of the first commit to a branch;
> and avoid insane, broken repositories altogether.
You still better make it work properly wrt deleted files.
And you have to be careful not to hit a real content conflict.
^ permalink raw reply
* Re: [PATCH][RESEND] Escape some tilde characters causing spurious subscripts in documentation
From: Junio C Hamano @ 2007-06-24 22:18 UTC (permalink / raw)
To: Jason Sewall; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <31e9dd080706241440s21025c26p68fda1595d531f1e@mail.gmail.com>
"Jason Sewall" <jasonsewall@gmail.com> writes:
> I'd suggest that we put all inline revspecs inside $$...$$; this
> "inline passthrough" quote obeys outside quoting,...
Does that work with AsciiDoc 7?
> Is there a documentation 'style' file or something like that for git?
Well, there isn't one as nobody really knows AsciiDoc well
enough, and actually my message was to con you into writing one ;-).
^ permalink raw reply
* Re: [PATCH] git-svnimport: added explicit merge graph option -G
From: Junio C Hamano @ 2007-06-24 22:17 UTC (permalink / raw)
To: Stas Maximov; +Cc: git, Peter Baumann
In-Reply-To: <49428.47661.qm@web43139.mail.sp1.yahoo.com>
Stas Maximov <smaximov@yahoo.com> writes:
> Attached are two patches:
>
> 1. resubmission of the original patch with proper sign-off; and
> 2. patch with permissions fix (thanks to Alex Reisen for pointing out);
As you are assuming that the original patch was rejected (by
resending that as the first one here), I do not think these
changes should be in two separate commits. Please redo them as
a single patch.
Also please do not "Attach". When you have N patches to send,
send N e-mail messages, numbered from [PATCH 1/N] to [PATCH
N/N], each with one patch in the message itself.
Please see Documentation/SubmittingPatches.
^ permalink raw reply
* Re: [PATCH] git-svnimport: added explicit merge graph option -G
From: Stas Maximov @ 2007-06-24 21:48 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Peter Baumann
[-- Attachment #1: Type: text/plain, Size: 2846 bytes --]
Attached are two patches:
1. resubmission of the original patch with proper sign-off; and
2. patch with permissions fix (thanks to Alex Reisen for pointing out);
A few points in defense of specification of merge graph in terms of SVN rev numbers.
a) This information is often directly available from svn log records. While there is no one agreed format of svn commit messages reflecting merge information, many projects adopted their own rules about that. So it is often possible to write a project-specific script which will automate the step of creating the graph in terms of SVN revs. Suggested merge graph format serves as an interface between such scripts and git-svnimport.
As there is no need to operate in terms of git commit ids, debugging of such script does not require any import operations.
b) Generic git tool which allows fine editing of merge lines in git repo is certainly a good thing to have, but it is more suitable for fine editing after the import completed, where only a small number of corrections is required. This tool is beyond the scope of this patch.
c) Different importers may have very different issues to deal with. The proposed patch for git-svnimport takes advantage of a notion of a changeset available in SVN. For example CVS does not have such a concept, so different means should be used there. See how options -m/-M of git-svnimport were carried over from CVS to SVN. This is likely to be the case with other importers.
Stas.
----- Original Message ----
From: Peter Baumann <waste.manager@gmx.de>
To: Stas Maximov <smaximov@yahoo.com>
Cc: git@vger.kernel.org; Junio C Hamano <gitster@pobox.com>
Sent: Sunday, June 24, 2007 1:44:27 AM
Subject: Re: [PATCH] git-svnimport: added explicit merge graph option -G
[exchanging To:/Cc: as Junio just forwarded the message from Stas]
Not commenting on the patch per se, but wouldn't it make more
sense to have such functionality in a history rewriting tool like
e.g. git-branch-filter?
I had an svn import (git-svn) where I wanted to give correct
branch/merge points, too, and so I manually created a grafts file
annotating all the svn merges. Having such a thing as a _generic_ tool
which operates on grafts would be much more usefull because you get one
implementation which could be used for each and every importer out
there. Sure, you have to transform the native revision specifieres into
the GIT commit id's if you only have e.g. "merged r4711:4720 into trunk",
but these functionality is much more common to have in importers
than whats implemented in the above mentioned patch.
Another bonus point of using the grafts mechanism you'll get for free is
that you could _look_ at the commit graph in gitk *before* doing the
often expensive reimport of your project, so could be sure you haven't
forgotten to mark a merge.
-Peter Baumann
[-- Attachment #2: 0001-git-svnimport-added-explicit-merge-graph-option-G.patch --]
[-- Type: application/octet-stream, Size: 5942 bytes --]
From fd83a4e003802b6cb4dc8a2d058310f235f65e17 Mon Sep 17 00:00:00 2001
From: Stas Maximov <smaximov@yahoo.com>
Date: Sat, 23 Jun 2007 09:06:30 -0700
Subject: [PATCH] git-svnimport: added explicit merge graph option -G
Allows explicit merge graph information to be provided. Each line
of merge graph file must contain a pair of SVN revision numbers
separated by space. The first number is child (merged to) SVN rev
number and the second is the parent (merged from) SVN rev number.
Comments can be started with '#' and continue to the end of line.
Empty and space-only lines are allowed and will be ignored.
Signed-off-by: Stas Maximov <smaximov@yahoo.com>
---
Documentation/git-svnimport.txt | 11 +++++-
git-svnimport.perl | 71 +++++++++++++++++++++++++++++++++++++--
2 files changed, 78 insertions(+), 4 deletions(-)
mode change 100644 => 100755 Documentation/git-svnimport.txt
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
old mode 100644
new mode 100755
index e97d15e..c902b64
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -13,7 +13,8 @@ SYNOPSIS
'git-svnimport' [ -o <branch-for-HEAD> ] [ -h ] [ -v ] [ -d | -D ]
[ -C <GIT_repository> ] [ -i ] [ -u ] [-l limit_rev]
[ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]
- [ -s start_chg ] [ -m ] [ -r ] [ -M regex ]
+ [ -s start_chg ] [ -r ]
+ [ -m ] [ -M regex ] [-G merge_graph_file ]
[ -I <ignorefile_name> ] [ -A <author_file> ]
[ -R <repack_each_revs>] [ -P <path_from_trunk> ]
<SVN_repository_URL> [ <path> ]
@@ -102,6 +103,14 @@ repository without -A.
regex. It can be used with -m to also see the default regexes.
You must escape forward slashes.
+-G <merge_graph_file>::
+ Allows explicit merge graph information to be provided. Each line
+ of merge graph file must contain a pair of SVN revision numbers
+ separated by space. The first number is child (merged to) SVN rev
+ number and the second is the parent (merged from) SVN rev number.
+ Comments can be started with '#' and continue to the end of line.
+ Empty and space-only lines are allowed and will be ignored.
+
-l <max_rev>::
Specify a maximum revision number to pull.
+
diff --git a/git-svnimport.perl b/git-svnimport.perl
index f459762..113b252 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -32,7 +32,7 @@ $ENV{'TZ'}="UTC";
our($opt_h,$opt_o,$opt_v,$opt_u,$opt_C,$opt_i,$opt_m,$opt_M,$opt_t,$opt_T,
$opt_b,$opt_r,$opt_I,$opt_A,$opt_s,$opt_l,$opt_d,$opt_D,$opt_S,$opt_F,
- $opt_P,$opt_R);
+ $opt_P,$opt_R,$opt_G);
sub usage() {
print STDERR <<END;
@@ -40,12 +40,13 @@ Usage: ${\basename $0} # fetch/update GIT from SVN
[-o branch-for-HEAD] [-h] [-v] [-l max_rev] [-R repack_each_revs]
[-C GIT_repository] [-t tagname] [-T trunkname] [-b branchname]
[-d|-D] [-i] [-u] [-r] [-I ignorefilename] [-s start_chg]
- [-m] [-M regex] [-A author_file] [-S] [-F] [-P project_name] [SVN_URL]
+ [-m] [-M regex] [-G merge_graph_file] [-A author_file]
+ [-S] [-F] [-P project_name] [SVN_URL]
END
exit(1);
}
-getopts("A:b:C:dDFhiI:l:mM:o:rs:t:T:SP:R:uv") or usage();
+getopts("A:b:C:dDFhiI:l:mM:G:o:rs:t:T:SP:R:uv") or usage();
usage if $opt_h;
my $tag_name = $opt_t || "tags";
@@ -80,6 +81,39 @@ if ($opt_M) {
unshift (@mergerx, qr/$opt_M/);
}
+
+# merge_graph will be used for finding all parent SVN revisions for a given SVN
+# revision. It will be implemented as a hash of hashes. First level hash will
+# be keyed with the child SVN rev and contain a hash keyed with the parent SVN
+# revisions. Values of the second level hash are not important (1 will be
+# used). The keys will be used to store the parent revs for uniqueness.
+our %merge_graph;
+
+
+# read-in the explicit merge graph specified with -G option
+if ($opt_G) {
+ open(F,"cat $opt_G | sed -e 's/#.*\$//' -e '/^\$/d' |") or
+ die("Can not open $opt_G");
+ while(<F>) {
+ chomp;
+ die "ERROR: invalid line in $opt_G: $_" unless /^\s*(\d+)\s+(\d+)\s*$/;
+ # $merge_graph{child_rev}{parent_rev} = 1;
+ $merge_graph{$1}{$2} = 1;
+ }
+ close(F);
+}
+
+
+# Given an SVN revision (string), finds all its parent SVN revisions in the
+# merge graph.
+sub merge_graph_get_parents($)
+{
+ my $child_svnrev = shift;
+ my @parents = keys(%{$merge_graph{$child_svnrev}});
+ return @parents;
+}
+
+
# Absolutize filename now, since we will have chdir'ed by the time we
# get around to opening it.
$opt_A = File::Spec->rel2abs($opt_A) if $opt_A;
@@ -356,6 +390,24 @@ if ($opt_A) {
open BRANCHES,">>", "$git_dir/svn2git";
+
+# Given an SVN revision (string), returns all corresponding GIT revisions.
+#
+# Note that it is possible that one SVN revision needs to be split into two or
+# more GIT commits (revision). For example, this will happen if SVN user
+# commits two branches at once.
+sub svnrev_to_gitrevs($)
+{
+ my $svnrev = shift;
+ my @gitrevs;
+ for my $b (keys(%branches)) {
+ push (@gitrevs, $branches{$b}{$svnrev})
+ if defined($branches{$b}{$svnrev});
+ }
+ return @gitrevs;
+}
+
+
sub node_kind($$) {
my ($svnpath, $revision) = @_;
my $pool=SVN::Pool->new;
@@ -815,6 +867,19 @@ sub commit {
}
}
}
+
+ # add parents from explicit merge graph (-G)
+ {
+ my @svnpars = merge_graph_get_parents($revision);
+ foreach my $svnp (@svnpars) {
+ my @gitpars = svnrev_to_gitrevs($svnp);
+ foreach my $gitp (@gitpars) {
+ push (@parents, $gitp);
+ #print OUT "MG: $svnp -merge-> $revision\n";
+ }
+ }
+ }
+
my %seen_parents = ();
my @unique_parents = grep { ! $seen_parents{$_} ++ } @parents;
foreach my $bparent (@unique_parents) {
--
1.5.1.3
[-- Attachment #3: 0002-Fixed-permissions-of-Documentation-git-svnimport.txt.patch --]
[-- Type: application/octet-stream, Size: 511 bytes --]
From 7008a13f1fe00fdbd90be6a12ad1197dceedaebb Mon Sep 17 00:00:00 2001
From: Stas Maximov <smaximov@yahoo.com>
Date: Sun, 24 Jun 2007 14:23:29 -0700
Subject: [PATCH] Fixed permissions of Documentation/git-svnimport.txt
Signed-off-by: Stas Maximov <smaximov@yahoo.com>
---
0 files changed, 0 insertions(+), 0 deletions(-)
mode change 100755 => 100644 Documentation/git-svnimport.txt
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
old mode 100755
new mode 100644
--
1.5.1.3
^ permalink raw reply related
* Re: Darcs
From: Theodore Tso @ 2007-06-24 21:52 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Linus Torvalds, Bu Bacoo, git
In-Reply-To: <46a038f90706241345m4b5ecb80p9f4ec840993023e0@mail.gmail.com>
On Mon, Jun 25, 2007 at 08:45:57AM +1200, Martin Langhoff wrote:
> OTOH, and from the POV of someone closely following the SCM tools in
> the last few years (and using almost all of them), darcs was the first
> usable DSCM in the camp. I am not sure how much of its commandline
> user interface was borrowed from BK or elsewhere, but darcs was
> _easy_, where Arch was extremely hard to use.
> The darcs commandset (init, push, pull) is what git, hg and bzr have
> today in common.
> And the closer we get to Darcs UI the happier I feel ;-)
Darcs was first announced in April 2003 [1].
Linus first started using BK to manage the Linux source tree in 2002;
I first started using Bitkeeper to manage e2fsprogs back in 2001; and
BK was first available in late 1998.
So to give credit where credit is due, the whole "$foo init", "$foo
commit", "$foo push", "$foo pull" DSCM UI was first pioneered by Larry
McVoy and BitKeeper, not Darcs.
- Ted
[1] http://www.haskell.org/pipermail/haskell-cafe/2003-April/004139.html
^ permalink raw reply
* Re: [PATCH][RESEND] Escape some tilde characters causing spurious subscripts in documentation
From: Jason Sewall @ 2007-06-24 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <31e9dd080706241031m64c6be37sb4437036fda543c9@mail.gmail.com>
On 6/24/07, Jason Sewall <jasonsewall@gmail.com> wrote:
> On 6/24/07, Junio C Hamano <gitster@pobox.com> wrote:
> > "Jason Sewall" <jasonsewall@gmail.com> writes:
> >
> > > On 6/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > >> I just checked with my copy of asciidoc, though, and there is no mangling
> > >> going on, at least in git-bundle.html (which is the only file I checked).
> > >> My asciidoc is version 8.2.1. What is yours?
> > >
> > > I've got 8.1.0; perhaps that's the problem. I wasn't so surprised to
> > > hear the asciidoc 7 and 8 don't get along, but I'm surprised to see
> > > that 8.1 and 8.2 are so different.
> > >
> > > Anyway, 8.1.0 is apparently what's in Fedora 7 (the distro I'm using
> > > right now) so it might be worth hanging on to the patch.
> >
> > FWIW, 7.1.2, 8.2.1 and 7.0.2 all seem to be Ok (the last one is
> > used to format the pages in html and man branches of git.git).
> > It is a bit annoying having to use name\~num at some places and
> > no backslash all others.
> >
> > Two requests:
> >
> > - Documentation/git-rev-parse.txt has '{tilde}<n>'. If you
> > replace that {tilde} with a "~", how does your AsciiDoc
> > format it? Do you see the same breakage?
>
> Kinda. Replacing {tilde} with ~ actually causes asciidoc to fail while
> processing the file; that tilde is 'unmatched' and ends up crossing
> another tag or somesuch.
>
> > - If it breaks, does it fix the breakage if you prefix the "~"
> > with a backslash, instead of using {tilde}?
>
> The escaped tilde works fine.
>
> > If the answer to both questions are "yes", then perhaps we
> > should get rid of the {tilde} macro we define in
> > Documentation/asciidoc.conf file, and use your "\~" solution
> > everywhere.
> >
> > Also do you see any pattern? It does not seem that all the
> > "master~3" are broken for you but only some. If your commit
> > message can describe when quoting is needed, that would help
> > people who would modify the documentation in the future.
>
> I clearly need to read up on Asciidoc formatting directives before I
> could do that with confidence, but I look over it today and see what I
> can do.
Frankly, I don't see any pattern. The git documentation is very fond
of ~ and ^, naturally, and these are inline delimiters in Asciidoc.
Sometimes the places these appear in are unquoted, sometimes
double-quoted, grave-quoted, or single-quoted; any of these can cause
<sub> and <sup> tags in the html output.
I'd suggest that we put all inline revspecs inside $$...$$; this
"inline passthrough" quote obeys outside quoting, and it's what
AsciiMathML uses to avoid fighting reserved characters. Since ~, ^, {,
}, [, ] and more all appear with great frequency in refspecs, this
will save us a lot of escape characters.
There's also a few places where ~ appears in a path name; perhaps we
could put $$...$$ around paths too.
Is there a documentation 'style' file or something like that for git?
Something like that might be useful to help solve this sort of
problem; in addition to unintentional formatting problems like the one
under discussion, there doesn't seem to be a consensus on what sort of
quoting to use for special literal text, like git commands, refspecs,
pathnames, etc. - `, ', and " abound interchangeably.
Jason
P.S. I got smarter about how to find some of these formatting problems
and have found some more 'doc bugs' that I'll put into a patch once
we've decided how to handle this stuff
^ 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