* Re: git blame and cherry-picking
From: Jeff King @ 2008-08-07 18:49 UTC (permalink / raw)
To: Steven Grimm; +Cc: Alex Riesen, git
In-Reply-To: <AA6BDC98-8800-4031-8C8F-A4BD326BEC1E@midwinter.com>
On Thu, Aug 07, 2008 at 11:37:02AM -0700, Steven Grimm wrote:
> No, of course not. But one might want to show the original commit's
> author instead of the name of the person who did the cherry pick. That's
> mostly what I'm looking for here; knowing where the change originally came
> from in terms of the revision graph is occasionally interesting but not
> nearly as important.
OK. I think that is a cherry-pick -n issue, then, as you mention below.
> One could argue that the real issue here is that while "git cherry-pick"
> preserves the original author and doesn't have the misattribution problem,
> "git cherry-pick -n" discards the original commit's attribution (though it
> does keep the commit message). Obviously git doesn't necessarily know
> whether the cherry-picker made substantial changes before committing and
> should truly be considered the author, but one of the use cases for the
> "-n" option is a simple "make sure you don't commit totally broken
> revisions" where there is little to no additional editing of the patch and
> keeping the original author would support that use case better.
I don't think it would be hard to stuff the cherry-picked commit's info
somewhere and to pull it out during git-commit. git-am and git-rebase -i
are already doing something similar. The harder question is what should
be done with multiple "git cherry-pick -n" invocations with different
authors?
I haven't looked closely at the git-sequencer stuff, but I wonder if
some of this will come with it for free. My impression is that the
prototype is built on _top_ of cherry-pick, but that the C version will
not be, and that cherry-pick can then be implemented in terms of the
sequencer.
-Peff
^ permalink raw reply
* Re: git blame and cherry-picking
From: Junio C Hamano @ 2008-08-07 18:49 UTC (permalink / raw)
To: Steven Grimm; +Cc: Jeff King, Alex Riesen, git
In-Reply-To: <AA6BDC98-8800-4031-8C8F-A4BD326BEC1E@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> On Aug 7, 2008, at 11:22 AM, Jeff King wrote:
>> You could potentially have git-blame incorporate that information
>> (again, if the referenced commit is even still available), but I'm not
>> sure exactly what difference it would make. I don't think you would
>> want
>> to start blaming up the original commits line of parentage.
>
> No, of course not. But one might want to show the original commit's
> author instead of the name of the person who did the cherry pick.
"cherry-pick" lets you say "-n" so that you can use the change as if you
are creating (think of it as a typesaver). You can ask commit to record
the result under the original authorship.
Perhaps a workflow sequence would go like this:
... Ah, I like that change by Joe; let's see if that really works ...
$ git cherry-pick -n joe/experimental~4
$ test test test
... Hmm, not quite, let's fix up ...
$ edit test edit test
... Now it works and I like the result, but I'll edit the comment to
... describe the change I made on top of what he did to make it work.
$ git commit -a -c joe/experimental~4
^ permalink raw reply
* Re: git blame and cherry-picking
From: Steven Grimm @ 2008-08-07 18:37 UTC (permalink / raw)
To: Jeff King; +Cc: Alex Riesen, git
In-Reply-To: <20080807182256.GF11314@sigill.intra.peff.net>
On Aug 7, 2008, at 11:22 AM, Jeff King wrote:
> You could potentially have git-blame incorporate that information
> (again, if the referenced commit is even still available), but I'm not
> sure exactly what difference it would make. I don't think you would
> want
> to start blaming up the original commits line of parentage.
No, of course not. But one might want to show the original commit's
author instead of the name of the person who did the cherry pick.
That's mostly what I'm looking for here; knowing where the change
originally came from in terms of the revision graph is occasionally
interesting but not nearly as important.
One could argue that the real issue here is that while "git cherry-
pick" preserves the original author and doesn't have the
misattribution problem, "git cherry-pick -n" discards the original
commit's attribution (though it does keep the commit message).
Obviously git doesn't necessarily know whether the cherry-picker made
substantial changes before committing and should truly be considered
the author, but one of the use cases for the "-n" option is a simple
"make sure you don't commit totally broken revisions" where there is
little to no additional editing of the patch and keeping the original
author would support that use case better.
-Steve
^ permalink raw reply
* Re: git blame and cherry-picking
From: Jeff King @ 2008-08-07 18:22 UTC (permalink / raw)
To: Alex Riesen; +Cc: Steven Grimm, git
In-Reply-To: <20080807060940.GA15405@blimp.local>
On Thu, Aug 07, 2008 at 08:09:40AM +0200, Alex Riesen wrote:
> Steven Grimm, Thu, Aug 07, 2008 00:18:33 +0200:
> > What, if any, is the approved way to get git blame to follow cherry-
> > picked changes?
>
> The can't be any: cherry-picks are just new commits. You just make the
> same changes at the new place in the history.
We used to say "cherry-picked from..." in the commit message, but I
don't think we do by default any longer. One could follow that link to
see the original change (if it still exists!).
You could potentially have git-blame incorporate that information
(again, if the referenced commit is even still available), but I'm not
sure exactly what difference it would make. I don't think you would want
to start blaming up the original commits line of parentage.
-Peff
^ permalink raw reply
* linearising TopGit forests into patch series (was: [ANNOUNCE] TopGit - A different patch queue manager)
From: martin f krafft @ 2008-08-07 17:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: vcs distro packaging discussion list, git
In-Reply-To: <20080803031424.GV32184@machine.or.cz>
[-- Attachment #1.1: Type: text/plain, Size: 1579 bytes --]
Hi Petr and everyone else,
as some of you may know, I am working on http://vcs-pkg.org, and
Pierre kindly alerted me to your announcement, which looks very
interesting for what we are trying to do.
Assuming a number of interdependent topic branches, does TopGit
provide a way for me to linearise/flatten/serialise these branches
in a one-patch-per-branch fashion, so that I could turn any TopGit
repository into a quilt series? I am only interested in a one-way
conversion from TopGit to quilt for now.
The reason for this is quite simply that while it's fabulous to use
e.g. Git for managing the source repository from which to build
distro packages, the resulting packages will have all
distro-specific changes applied or collated into a single diff. This
makes it hard for other distributions to grab patches, for upstream
to keep on top of what is being distributed, and for bug fixers to
separate patches and test only specific ones.
If we could turn a TopGit-managed forest into a quilt series, we
could distribute the series with the package and allow those who
inspect the source package to use quilt to navigate the patches.
If anyone has any input on the matter, I'd love to hear it.
Thank you,
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
infinite loop: see 'loop, infinite'.
loop, infinite: see 'infinite loop'.
[-- Attachment #1.2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git blame and cherry-picking
From: Avery Pennarun @ 2008-08-07 17:53 UTC (permalink / raw)
To: Steven Grimm; +Cc: Git Users List
In-Reply-To: <91A979F0-1329-4CA6-AADC-6CF55872B57A@midwinter.com>
On 8/6/08, Steven Grimm <koreth@midwinter.com> wrote:
> What, if any, is the approved way to get git blame to follow cherry-picked
> changes? Right now blame is good about showing you the actual responsible
> revision and author in the case of merges, but if you cherry-pick a change
> with "-n" (to test before committing), the modifications are attributed to
> the person who did the cherry-pick instead of the cherry-picked revision's
> author. Even without the "-n" option, the changes are attributed to the
> cherry-pick *revision* instead of the original one.
It sounds like you at least want to avoid using "-n", if it really
does lose author information that way. If the patch doesn't work, you
can always "git commit --amend" or "git reset --hard HEAD^".
I don't think tracing through to the original revision is useful
anyway; nothing you'd find through the original commit would be
relevant to git blame, AFAICS, since none of those other patches were
applied to the branch you're looking at.
Have fun,
Avery
^ permalink raw reply
* Re: git blame and cherry-picking
From: Alex Riesen @ 2008-08-07 6:09 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <91A979F0-1329-4CA6-AADC-6CF55872B57A@midwinter.com>
Steven Grimm, Thu, Aug 07, 2008 00:18:33 +0200:
> What, if any, is the approved way to get git blame to follow cherry-
> picked changes?
The can't be any: cherry-picks are just new commits. You just make the
same changes at the new place in the history.
^ permalink raw reply
* [TopGit PATCH] Makefile: mkdir $(bindir)
From: Bert Wesarg @ 2008-08-07 16:39 UTC (permalink / raw)
To: Petr Baudis; +Cc: Bert Wesarg, git
Mkdir $(bindir) in install target.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 238d07d..2e162ce 100644
--- a/Makefile
+++ b/Makefile
@@ -29,6 +29,7 @@ $(help_out): README
./create-help.sh `echo $@ | sed -e 's/tg-//' -e 's/\.txt//'`
install:: all
+ install -d -m 755 "$(bindir)"
install tg "$(bindir)"
install -d -m 755 "$(cmddir)"
install $(commands_out) "$(cmddir)"
--
tg: (e311d15..) t/mkdir-bindir (depends on: master)
^ permalink raw reply related
* [PATCH v2 2/2] git-svn: Allow deep branch names by supporting multi-globs
From: Marcus Griep @ 2008-08-07 15:34 UTC (permalink / raw)
To: Git Mailing List; +Cc: Eric Wong, Junio C Hamano, Marcus Griep
In-Reply-To: <1218123242-26260-2-git-send-email-marcus@griep.us>
Some repositories use a deep branching strategy, such as:
branches/1.0/1.0.rc1
branches/1.0/1.0.rc2
branches/1.0/1.0.rtm
branches/1.0/1.0.gold
Only allowing a single glob stiffles this.
This change allows for a single glob 'set' to accept this deep branching
strategy.
The ref glob depth must match the branch glob depth. When using the -b or -t
options for init or clone, this is automatically done.
For example, using the above branches:
svn-remote.svn.branches = branches/*/*:refs/remote/*/*
gives the following branch names:
1.0/1.0.rc1
1.0/1.0.rc2
1.0/1.0.rtm
1.0/1.0.gold
Signed-off-by: Marcus Griep <marcus@griep.us>
---
git-svn.perl | 64 +++++++++---
t/t9108-git-svn-glob.sh | 9 +-
t/t9108-git-svn-multi-glob.sh | 155 ++++++++++++++++++++++++++++
t/t9125-git-svn-multi-glob-branch-names.sh | 41 ++++++++
4 files changed, 248 insertions(+), 21 deletions(-)
create mode 100755 t/t9108-git-svn-multi-glob.sh
create mode 100755 t/t9125-git-svn-multi-glob-branch-names.sh
diff --git a/git-svn.perl b/git-svn.perl
index 5974a06..fe78461 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -169,7 +169,8 @@ my %cmd = (
'color' => \$Git::SVN::Log::color,
'pager=s' => \$Git::SVN::Log::pager
} ],
- 'find-rev' => [ \&cmd_find_rev, "Translate between SVN revision numbers and tree-ish",
+ 'find-rev' => [ \&cmd_find_rev,
+ "Translate between SVN revision numbers and tree-ish",
{} ],
'rebase' => [ \&cmd_rebase, "Fetch and rebase your working directory",
{ 'merge|m|M' => \$_merge,
@@ -229,7 +230,9 @@ unless ($cmd && $cmd =~ /(?:clone|init|multi-init)$/) {
my %opts = %{$cmd{$cmd}->[2]} if (defined $cmd);
read_repo_config(\%opts);
-Getopt::Long::Configure('pass_through') if ($cmd && ($cmd eq 'log' || $cmd eq 'blame'));
+if ($cmd && ($cmd eq 'log' || $cmd eq 'blame')) {
+ Getopt::Long::Configure('pass_through');
+}
my $rv = GetOptions(%opts, 'help|H|h' => \$_help, 'version|V' => \$_version,
'minimize-connections' => \$Git::SVN::Migration::_minimize,
'id|i=s' => \$Git::SVN::default_ref_id,
@@ -985,7 +988,7 @@ sub complete_url_ls_init {
die "--prefix='$pfx' must have a trailing slash '/'\n";
}
command_noisy('config', "svn-remote.$gs->{repo_id}.$n",
- "$remote_path:refs/remotes/$pfx*");
+ "$remote_path:refs/remotes/$pfx*" . ('/*' x (($remote_path =~ tr/*/*/)-1)));
}
sub verify_ref {
@@ -4121,16 +4124,38 @@ sub gs_fetch_loop_common {
Git::SVN::gc();
}
+sub get_dir_globbed {
+ my ($self, $left, $depth, $r) = @_;
+
+ my @x = eval { $self->get_dir($left, $r) };
+ return unless scalar @x == 3;
+ my $dirents = $x[0];
+ my @finalents;
+ foreach my $de (keys %$dirents) {
+ next if $dirents->{$de}->{kind} != $SVN::Node::dir;
+ if ($depth > 1) {
+ foreach my $dir ($self->get_dir_globbed($left.'/'.$de, $depth - 1, $r)) {
+ push @finalents, "$de/$dir";
+ }
+ } else {
+ push @finalents, $de;
+ }
+ }
+ @finalents;
+}
+
sub match_globs {
my ($self, $exists, $paths, $globs, $r) = @_;
sub get_dir_check {
my ($self, $exists, $g, $r) = @_;
- my @x = eval { $self->get_dir($g->{path}->{left}, $r) };
- return unless scalar @x == 3;
- my $dirents = $x[0];
- foreach my $de (keys %$dirents) {
- next if $dirents->{$de}->{kind} != $SVN::Node::dir;
+
+ my @dirs = $self->get_dir_globbed(
+ $g->{path}->{left},
+ $g->{path}->{depth},
+ $r);
+
+ foreach my $de (@dirs) {
my $p = $g->{path}->full_path($de);
next if $exists->{$p};
next if (length $g->{path}->{right} &&
@@ -4912,16 +4937,21 @@ sub new {
my ($class, $glob) = @_;
my $re = $glob;
$re =~ s!/+$!!g; # no need for trailing slashes
- my $nr = $re =~ tr/*/*/;
- if ($nr > 1) {
- die "Only one '*' wildcard expansion ",
- "is supported (got $nr): '$glob'\n";
- } elsif ($nr == 0) {
+ $re =~ m!^([^*]*)(\*(?:/\*)*)([^*]*)$!;
+ my $temp = $re;
+ my ($left, $right) = ($1, $3);
+ $re = $2;
+ my $depth = $re =~ tr/*/*/;
+ if ($depth != $temp =~ tr/*/*/) {
+ die "Only one set of wildcard directories " .
+ "(e.g. '*' or '*/*/*') is supported: '$glob'\n";
+ }
+ if ($depth == 0) {
die "One '*' is needed for glob: '$glob'\n";
}
- $re =~ s!^(.*)\*(.*)$!\(\[^/\]+\)!g;
- my ($left, $right) = ($1, $2);
- $re = quotemeta($left) . $re . quotemeta($right);
+ $re =~ s!\*!\[^/\]*!g;
+# $re =~ s!\?!\[^/\]!g;
+ $re = quotemeta($left) . "($re)" . quotemeta($right);
if (length $left && !($left =~ s!/+$!!g)) {
die "Missing trailing '/' on left side of: '$glob' ($left)\n";
}
@@ -4930,7 +4960,7 @@ sub new {
}
my $left_re = qr/^\/\Q$left\E(\/|$)/;
bless { left => $left, right => $right, left_regex => $left_re,
- regex => qr/$re/, glob => $glob }, $class;
+ regex => qr/$re/, glob => $glob, depth => $depth }, $class;
}
sub full_path {
diff --git a/t/t9108-git-svn-glob.sh b/t/t9108-git-svn-glob.sh
index ef6d88e..46958e5 100755
--- a/t/t9108-git-svn-glob.sh
+++ b/t/t9108-git-svn-glob.sh
@@ -52,7 +52,8 @@ test_expect_success 'test refspec globbing' '
test "`git rev-parse refs/remotes/tags/end~1`" = \
"`git rev-parse refs/remotes/branches/start`" &&
test "`git rev-parse refs/remotes/branches/start~2`" = \
- "`git rev-parse refs/remotes/trunk`"
+ "`git rev-parse refs/remotes/trunk`" &&
+ test_must_fail git rev-parse refs/remotes/tags/end@3
'
echo try to try > expect.two
@@ -83,14 +84,14 @@ test_expect_success 'test left-hand-side only globbing' '
cmp expect.two output.two
'
-echo "Only one '*' wildcard expansion is supported (got 2): 'branches/*/*'" > expect.three
+echo "Only one set of wildcard directories (e.g. '*' or '*/*/*') is supported: 'branches/*/t/*'" > expect.three
echo "" >> expect.three
-test_expect_success 'test disallow multi-globs' '
+test_expect_success 'test disallow multiple globs' '
git config --add svn-remote.three.url "$svnrepo" &&
git config --add svn-remote.three.fetch trunk:refs/remotes/three/trunk &&
git config --add svn-remote.three.branches \
- "branches/*/*:refs/remotes/three/branches/*" &&
+ "branches/*/t/*:refs/remotes/three/branches/*" &&
git config --add svn-remote.three.tags \
"tags/*/*:refs/remotes/three/tags/*" &&
cd tmp &&
diff --git a/t/t9108-git-svn-multi-glob.sh b/t/t9108-git-svn-multi-glob.sh
new file mode 100755
index 0000000..1d80cb1
--- /dev/null
+++ b/t/t9108-git-svn-multi-glob.sh
@@ -0,0 +1,155 @@
+#!/bin/sh
+# Copyright (c) 2007 Eric Wong
+test_description='git-svn globbing refspecs'
+. ./lib-git-svn.sh
+
+cat > expect.end <<EOF
+the end
+hi
+start a new branch
+initial
+EOF
+
+test_expect_success 'test refspec globbing' '
+ mkdir -p trunk/src/a trunk/src/b trunk/doc &&
+ echo "hello world" > trunk/src/a/readme &&
+ echo "goodbye world" > trunk/src/b/readme &&
+ svn import -m "initial" trunk "$svnrepo"/trunk &&
+ svn co "$svnrepo" tmp &&
+ cd tmp &&
+ mkdir branches branches/v1 tags &&
+ svn add branches tags &&
+ svn cp trunk branches/v1/start &&
+ svn commit -m "start a new branch" &&
+ svn up &&
+ echo "hi" >> branches/v1/start/src/b/readme &&
+ poke branches/v1/start/src/b/readme &&
+ echo "hey" >> branches/v1/start/src/a/readme &&
+ poke branches/v1/start/src/a/readme &&
+ svn commit -m "hi" &&
+ svn up &&
+ svn cp branches/v1/start tags/end &&
+ echo "bye" >> tags/end/src/b/readme &&
+ poke tags/end/src/b/readme &&
+ echo "aye" >> tags/end/src/a/readme &&
+ poke tags/end/src/a/readme &&
+ svn commit -m "the end" &&
+ echo "byebye" >> tags/end/src/b/readme &&
+ poke tags/end/src/b/readme &&
+ svn commit -m "nothing to see here"
+ cd .. &&
+ git config --add svn-remote.svn.url "$svnrepo" &&
+ git config --add svn-remote.svn.fetch \
+ "trunk/src/a:refs/remotes/trunk" &&
+ git config --add svn-remote.svn.branches \
+ "branches/*/*/src/a:refs/remotes/branches/*/*" &&
+ git config --add svn-remote.svn.tags\
+ "tags/*/src/a:refs/remotes/tags/*" &&
+ git-svn multi-fetch &&
+ git log --pretty=oneline refs/remotes/tags/end | \
+ sed -e "s/^.\{41\}//" > output.end &&
+ cmp expect.end output.end &&
+ test "`git rev-parse refs/remotes/tags/end~1`" = \
+ "`git rev-parse refs/remotes/branches/v1/start`" &&
+ test "`git rev-parse refs/remotes/branches/v1/start~2`" = \
+ "`git rev-parse refs/remotes/trunk`" &&
+ test_must_fail git rev-parse refs/remotes/tags/end@3
+ '
+
+echo try to try > expect.two
+echo nothing to see here >> expect.two
+cat expect.end >> expect.two
+
+test_expect_success 'test left-hand-side only globbing' '
+ git config --add svn-remote.two.url "$svnrepo" &&
+ git config --add svn-remote.two.fetch trunk:refs/remotes/two/trunk &&
+ git config --add svn-remote.two.branches \
+ "branches/*/*:refs/remotes/two/branches/*/*" &&
+ git config --add svn-remote.two.tags \
+ "tags/*:refs/remotes/two/tags/*" &&
+ cd tmp &&
+ echo "try try" >> tags/end/src/b/readme &&
+ poke tags/end/src/b/readme &&
+ svn commit -m "try to try"
+ cd .. &&
+ git-svn fetch two &&
+ test `git rev-list refs/remotes/two/tags/end | wc -l` -eq 6 &&
+ test `git rev-list refs/remotes/two/branches/v1/start | wc -l` -eq 3 &&
+ test `git rev-parse refs/remotes/two/branches/v1/start~2` = \
+ `git rev-parse refs/remotes/two/trunk` &&
+ test `git rev-parse refs/remotes/two/tags/end~3` = \
+ `git rev-parse refs/remotes/two/branches/v1/start` &&
+ git log --pretty=oneline refs/remotes/two/tags/end | \
+ sed -e "s/^.\{41\}//" > output.two &&
+ cmp expect.two output.two
+ '
+cat > expect.four <<EOF
+adios
+adding more
+Changed 2 in v2/start
+Another versioned branch
+initial
+EOF
+
+test_expect_success 'test another branch' '
+ (
+ cd tmp &&
+ mkdir branches/v2 &&
+ svn add branches/v2 &&
+ svn cp trunk branches/v2/start &&
+ svn commit -m "Another versioned branch" &&
+ svn up &&
+ echo "hello" >> branches/v2/start/src/b/readme &&
+ poke branches/v2/start/src/b/readme &&
+ echo "howdy" >> branches/v2/start/src/a/readme &&
+ poke branches/v2/start/src/a/readme &&
+ svn commit -m "Changed 2 in v2/start" &&
+ svn up &&
+ svn cp branches/v2/start tags/next &&
+ echo "bye" >> tags/next/src/b/readme &&
+ poke tags/next/src/b/readme &&
+ echo "aye" >> tags/next/src/a/readme &&
+ poke tags/next/src/a/readme &&
+ svn commit -m "adding more" &&
+ echo "byebye" >> tags/next/src/b/readme &&
+ poke tags/next/src/b/readme &&
+ svn commit -m "adios"
+ ) &&
+ git config --add svn-remote.four.url "$svnrepo" &&
+ git config --add svn-remote.four.fetch trunk:refs/remotes/four/trunk &&
+ git config --add svn-remote.four.branches \
+ "branches/*/*:refs/remotes/four/branches/*/*" &&
+ git config --add svn-remote.four.tags \
+ "tags/*:refs/remotes/four/tags/*" &&
+ git-svn fetch four &&
+ test `git rev-list refs/remotes/four/tags/next | wc -l` -eq 5 &&
+ test `git rev-list refs/remotes/four/branches/v2/start | wc -l` -eq 3 &&
+ test `git rev-parse refs/remotes/four/branches/v2/start~2` = \
+ `git rev-parse refs/remotes/four/trunk` &&
+ test `git rev-parse refs/remotes/four/tags/next~2` = \
+ `git rev-parse refs/remotes/four/branches/v2/start` &&
+ git log --pretty=oneline refs/remotes/four/tags/next | \
+ sed -e "s/^.\{41\}//" > output.four &&
+ cmp expect.four output.four
+ '
+
+echo "Only one set of wildcard directories (e.g. '*' or '*/*/*') is supported: 'branches/*/t/*'" > expect.three
+echo "" >> expect.three
+
+test_expect_success 'test disallow multiple globs' '
+ git config --add svn-remote.three.url "$svnrepo" &&
+ git config --add svn-remote.three.fetch trunk:refs/remotes/three/trunk &&
+ git config --add svn-remote.three.branches \
+ "branches/*/t/*:refs/remotes/three/branches/*/*" &&
+ git config --add svn-remote.three.tags \
+ "tags/*:refs/remotes/three/tags/*" &&
+ cd tmp &&
+ echo "try try" >> tags/end/src/b/readme &&
+ poke tags/end/src/b/readme &&
+ svn commit -m "try to try"
+ cd .. &&
+ test_must_fail git-svn fetch three &> stderr.three &&
+ cmp expect.three stderr.three
+ '
+
+test_done
diff --git a/t/t9125-git-svn-multi-glob-branch-names.sh b/t/t9125-git-svn-multi-glob-branch-names.sh
new file mode 100755
index 0000000..5560db0
--- /dev/null
+++ b/t/t9125-git-svn-multi-glob-branch-names.sh
@@ -0,0 +1,41 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Eric Wong
+#
+
+test_description='git-svn multi-glob branch names'
+. ./lib-git-svn.sh
+
+test_expect_success 'setup svnrepo' '
+ mkdir project project/trunk project/branches \
+ project/branches/v14.1 project/tags &&
+ echo foo > project/trunk/foo &&
+ svn import -m "$test_description" project "$svnrepo/project" &&
+ rm -rf project &&
+ svn cp -m "fun" "$svnrepo/project/trunk" \
+ "$svnrepo/project/branches/v14.1/beta" &&
+ svn cp -m "more fun!" "$svnrepo/project/branches/v14.1/beta" \
+ "$svnrepo/project/branches/v14.1/gold" &&
+ start_httpd
+ '
+
+test_expect_success 'test clone with multi-glob in branch names' '
+ git svn clone -T trunk -b branches/*/* -t tags "$svnrepo/project" project &&
+ cd project &&
+ git rev-parse "refs/remotes/v14.1/beta" &&
+ git rev-parse "refs/remotes/v14.1/gold" &&
+ cd ..
+ '
+
+test_expect_success 'test dcommit to multi-globbed branch' "
+ cd project &&
+ git reset --hard 'refs/remotes/v14.1/gold' &&
+ echo hello >> foo &&
+ git commit -m 'hello' -- foo &&
+ git svn dcommit &&
+ cd ..
+ "
+
+stop_httpd
+
+test_done
--
1.6.0.rc2.4.g39f8
^ permalink raw reply related
* [PATCH v2 1/2] Fix multi-glob assertion in git-svn
From: Marcus Griep @ 2008-08-07 15:34 UTC (permalink / raw)
To: Git Mailing List; +Cc: Eric Wong, Junio C Hamano, Marcus Griep
In-Reply-To: <1218123242-26260-1-git-send-email-marcus@griep.us>
Fixes bad regex match check for multiple globs (would always return
one glob regardless of actual number).
Signed-off-by: Marcus Griep <marcus@griep.us>
---
git-svn.perl | 5 +++--
t/t9108-git-svn-glob.sh | 19 +++++++++++++++++++
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index df0ed90..5974a06 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -4912,14 +4912,15 @@ sub new {
my ($class, $glob) = @_;
my $re = $glob;
$re =~ s!/+$!!g; # no need for trailing slashes
- my $nr = ($re =~ s!^(.*)\*(.*)$!\(\[^/\]+\)!g);
- my ($left, $right) = ($1, $2);
+ my $nr = $re =~ tr/*/*/;
if ($nr > 1) {
die "Only one '*' wildcard expansion ",
"is supported (got $nr): '$glob'\n";
} elsif ($nr == 0) {
die "One '*' is needed for glob: '$glob'\n";
}
+ $re =~ s!^(.*)\*(.*)$!\(\[^/\]+\)!g;
+ my ($left, $right) = ($1, $2);
$re = quotemeta($left) . $re . quotemeta($right);
if (length $left && !($left =~ s!/+$!!g)) {
die "Missing trailing '/' on left side of: '$glob' ($left)\n";
diff --git a/t/t9108-git-svn-glob.sh b/t/t9108-git-svn-glob.sh
index f6f71d0..ef6d88e 100755
--- a/t/t9108-git-svn-glob.sh
+++ b/t/t9108-git-svn-glob.sh
@@ -83,4 +83,23 @@ test_expect_success 'test left-hand-side only globbing' '
cmp expect.two output.two
'
+echo "Only one '*' wildcard expansion is supported (got 2): 'branches/*/*'" > expect.three
+echo "" >> expect.three
+
+test_expect_success 'test disallow multi-globs' '
+ git config --add svn-remote.three.url "$svnrepo" &&
+ git config --add svn-remote.three.fetch trunk:refs/remotes/three/trunk &&
+ git config --add svn-remote.three.branches \
+ "branches/*/*:refs/remotes/three/branches/*" &&
+ git config --add svn-remote.three.tags \
+ "tags/*/*:refs/remotes/three/tags/*" &&
+ cd tmp &&
+ echo "try try" >> tags/end/src/b/readme &&
+ poke tags/end/src/b/readme &&
+ svn commit -m "try to try"
+ cd .. &&
+ test_must_fail git-svn fetch three &> stderr.three &&
+ cmp expect.three stderr.three
+ '
+
test_done
--
1.6.0.rc2.4.g39f8
^ permalink raw reply related
* [PATCH v2 0/2] git-svn multi-glob fix and extension
From: Marcus Griep @ 2008-08-07 15:34 UTC (permalink / raw)
To: Git Mailing List; +Cc: Eric Wong, Junio C Hamano
In-Reply-To: <20080807090008.GA9161@untitled>
This patch series fixes and extends globs for branches and tags.
The first patch fixes the assertion that protects git-svn from allowing
multi-globs in branch names, whereas the second removes that restriction
altogether, allowing up to one multi-glob set in defining a branch hierarchy.
Also, patches are now under 80 chars wide except for a couple of echos in the
test cases.
Marcus Griep (2):
Fix multi-glob assertion in git-svn
git-svn: Allow deep branch names by supporting multi-globs
git-svn.perl | 63 +++++++++---
t/t9108-git-svn-glob.sh | 22 ++++-
t/t9108-git-svn-multi-glob.sh | 155 ++++++++++++++++++++++++++++
t/t9125-git-svn-multi-glob-branch-names.sh | 41 ++++++++
4 files changed, 264 insertions(+), 17 deletions(-)
^ permalink raw reply
* git svn throws locale related error when built from source
From: Anton Mostovoy @ 2008-08-07 15:33 UTC (permalink / raw)
To: git
Hi
I built git 1.5.6.3 manually (no package with 1.5.4+ on gutsy), and I am
getting the error below when running 'git svn rebase'.
svn works fine on its own though.
The default locale is set to en_US.UTF-8
svn: error: cannot set LC_ALL locale
svn: error: environment variable LANG is en_US.UTF-8
svn: error: please check that your locale name is correct
I found a workaround that works, but it would be nice to have it work
properly.
$ LANG= git svn rebase
Here is the output of the locale command:
$ locale
LANG=en_US.UTF-8
LANGUAGE=en-US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
Thanks in advance.
-Anton
^ permalink raw reply
* Re: git svn rebase - could not detach HEAD
From: Daniel Barkalow @ 2008-08-07 14:24 UTC (permalink / raw)
To: Tony Stubbs; +Cc: Björn Steinbrink, Junio C Hamano, git
In-Reply-To: <f7d8f60b0808070553o6f709445j9dd036f380763f6e@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 958 bytes --]
On Fri, 8 Aug 2008, Tony Stubbs wrote:
> >> <manually deleted "untracked file" here>
> >
> > Maybe you're ignoring that file? git clean deletes ignored files only if
> > you use -x/-X.
> >
> > Björn
> >
>
> That's probably it, I'll try it tomorrow. However, that could be a
> problem. There's ignored files I don't want to keep (build artifacts),
> and there's ignored files I do want to keep (i.e. .metadata).
> Is there a good solution?
There's only a problem if there's some reason you specifically want to not
keep an ignored file; this is usually only an issue when you're trying to
merge/rebase with a branch that has it tracked, at which point you have to
decide whether to add your version and merge or remove your version.
Ideally, git would tell you when the file that's in the way is ignored,
which would probably help you know what's going on, but it's tricky to get
that information there.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH v2] Documentation: filter-branch: document how to filter all refs
From: Thomas Rast @ 2008-08-07 14:16 UTC (permalink / raw)
To: Jan Wielemaker, git; +Cc: gitster, Johannes Schindelin
In-Reply-To: <1218117841-27398-1-git-send-email-trast@student.ethz.ch>
Document the '--' option that can be used to pass rev-list options
(not just arguments), and give an example usage of '-- --all'. Remove
reference to "the new branch name"; filter-branch takes arbitrary
arguments to rev-list since dfd05e3.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
At second glance, it turned out the documentation was actually older
than the code. So rewrite the documentation of <rev-list options>.
Documentation/git-filter-branch.txt | 21 ++++++++++++++++-----
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index a518ba6..31d3cae 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[--msg-filter <command>] [--commit-filter <command>]
[--tag-name-filter <command>] [--subdirectory-filter <directory>]
[--original <namespace>] [-d <directory>] [-f | --force]
- [<rev-list options>...]
+ [--] [<rev-list options>...]
DESCRIPTION
-----------
@@ -168,10 +168,10 @@ to other tags will be rewritten to point to the underlying commit.
'refs/original/', unless forced.
<rev-list options>...::
- When options are given after the new branch name, they will
- be passed to 'git-rev-list'. Only commits in the resulting
- output will be filtered, although the filtered commits can still
- reference parents which are outside of that set.
+ Arguments for 'git-rev-list'. All positive refs included by
+ these options are rewritten. You may also specify options
+ such as '--all', but you must use '--' to separate them from
+ the 'git-filter-branch' options.
Examples
@@ -196,6 +196,17 @@ git filter-branch --index-filter 'git rm --cached filename' HEAD
Now, you will get the rewritten history saved in HEAD.
+To rewrite the repository to look as if 'foodir/' had been its project
+root, and discard all other history:
+
+-------------------------------------------------------
+git filter-branch --subdirectory-filter foodir -- --all
+-------------------------------------------------------
+
+Thus you can, e.g., turn a library subdirectory into a repository of
+its own. Note the '--' that separates 'filter-branch' options from
+revision options, and the '--all' to rewrite all branches and tags.
+
To set a commit (which typically is at the tip of another
history) to be the parent of the current initial commit, in
order to paste the other history behind the current history:
--
1.6.0.rc1.106.g98a7
^ permalink raw reply related
* Re: [PATCH] Fail properly when cloning from invalid HTTP URL
From: Daniel Barkalow @ 2008-08-07 14:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: gitster, git
In-Reply-To: <1218067590-31590-1-git-send-email-pasky@suse.cz>
On Thu, 7 Aug 2008, pasky@suse.cz wrote:
> From: Petr Baudis <pasky@suse.cz>
>
> Currently, when cloning from invalid HTTP URL, git clone will possibly
> return curl error, then a confusing message about remote HEAD and then
> return success and leave an empty repository behind, confusing either
> the end-user or the automated service calling it (think repo.or.cz).
>
> This patch changes the error() calls in get_refs_via_curl() to die()s,
> akin to the other get_refs_*() functions.
>
> Cc: Daniel Barkalow <barkalow@iabervon.org>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
> ---
> transport.c | 7 +++----
> 1 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/transport.c b/transport.c
> index 6eb65b8..b88b89b 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -464,16 +464,15 @@ static struct ref *get_refs_via_curl(struct transport *transport)
> if (results.curl_result != CURLE_OK) {
> strbuf_release(&buffer);
> if (missing_target(&results)) {
> + die("%s not found: did you run git update-server-info on the server?", refs_url);
> return NULL;
The "return NULL" isn't necessary any more. Otherwise,
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
> } else {
> - error("%s", curl_errorstr);
> - return NULL;
> + die("%s download error - %s", refs_url, curl_errorstr);
> }
> }
> } else {
> strbuf_release(&buffer);
> - error("Unable to start request");
> - return NULL;
> + die("Unable to start HTTP request");
> }
>
> data = buffer.buf;
> --
> 1.5.6.3.392.g292f1
>
> --
> 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
>
^ permalink raw reply
* [PATCH] Documentation: filter-branch: document how to filter all refs
From: Thomas Rast @ 2008-08-07 14:04 UTC (permalink / raw)
To: git
In-Reply-To: <200808070950.23754.trast@student.ethz.ch>
Document the '--' option that can be used to pass rev-list options
(not just arguments), and give an example usage of '-- --all'.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
[This went out to Jan and Junio already, but I forgot to CC the list.
Sorry.]
Somehow I'm imagining this is a FAQ. Either way, I remember figuring
out this exact example by accident when I first needed it.
Documentation/git-filter-branch.txt | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index a518ba6..1f0fcec 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[--msg-filter <command>] [--commit-filter <command>]
[--tag-name-filter <command>] [--subdirectory-filter <directory>]
[--original <namespace>] [-d <directory>] [-f | --force]
- [<rev-list options>...]
+ [--] [<rev-list options>...]
DESCRIPTION
-----------
@@ -196,6 +196,17 @@ git filter-branch --index-filter 'git rm --cached filename' HEAD
Now, you will get the rewritten history saved in HEAD.
+To rewrite the repository to look as if 'foodir/' had been its project
+root, and discard all other history:
+
+-------------------------------------------------------
+git filter-branch --subdirectory-filter foodir -- --all
+-------------------------------------------------------
+
+Thus you can, e.g., turn a library subdirectory into a repository of
+its own. Note the '--' that separates 'filter-branch' options from
+revision options, and the '--all' to rewrite all branches and tags.
+
To set a commit (which typically is at the tip of another
history) to be the parent of the current initial commit, in
order to paste the other history behind the current history:
--
1.6.0.rc1.106.g98a7
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.6.0-rc2
From: Peter Zijlstra @ 2008-08-07 10:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7v3alhjgau.fsf@gitster.siamese.dyndns.org>
On Thu, 2008-08-07 at 03:00 -0700, Junio C Hamano wrote:
> Peter Zijlstra <peterz@infradead.org> writes:
>
> > Quick question - where does one go to find out the cool new features
> > that make it 1.6 and should convince me to upgrade and try this whicked
> > new release?
>
> Draft release notes for 1.6.0 was posted to the list some time ago
> already, but as always:
>
> http://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.6.0.txt
Thanks!
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.0-rc2
From: Peter Zijlstra @ 2008-08-07 8:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vskthll6t.fsf@gitster.siamese.dyndns.org>
On Wed, 2008-08-06 at 17:31 -0700, Junio C Hamano wrote:
> GIT 1.6.0-rc2 is the second (or should we call it the third?) preview of
> the upcoming release. It is available at the usual places:
>
> http://www.kernel.org/pub/software/scm/git/
>
> git-1.6.0-rc2.tar.{gz,bz2} (source tarball)
> git-htmldocs-1.6.0-rc2.tar.{gz,bz2} (preformatted docs)
> git-manpages-1.6.0-rc2.tar.{gz,bz2} (preformatted docs)
>
> The RPM binary packages for a few architectures are also provided
> as courtesy.
>
> testing/RPMS/$arch/*-1.6.0.rc2-1.fc9.$arch.rpm (RPM)
Quick question - where does one go to find out the cool new features
that make it 1.6 and should convince me to upgrade and try this whicked
new release?
^ permalink raw reply
* Re: [PATCH] files given on the command line are relative to $cwd
From: Luciano Rocha @ 2008-08-07 9:03 UTC (permalink / raw)
To: Samuel Tardieu
Cc: Junio C Hamano, git list, pascal, Pierre Habouzit,
Kristian Høgsberg
In-Reply-To: <2008-08-07-10-45-21+trackit+sam@rfc1149.net>
[-- Attachment #1: Type: text/plain, Size: 842 bytes --]
On Thu, Aug 07, 2008 at 10:45:21AM +0200, Samuel Tardieu wrote:
> >>>>> "Junio" == Junio C Hamano <gitster@pobox.com> writes:
>
> Junio> When running "git commit -F file" and "git tag -F file" from a
> Junio> subdirectory, we should take it as relative to the directory we
> Junio> started from, not relative to the top-level directory.
>
> Don't we have the same problem with "git show"? If you go into
> the "gitweb" directory of the GIT source, "git show HEAD:README" will
> show you the toplevel "README" instead of the one in the "gitweb"
> directory.
No, git show has different semantics. It has been discussed often in
this list.
For instance:
http://thread.gmane.org/gmane.comp.version-control.git/68786/focus=68852
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git svn rebase - could not detach HEAD
From: Tony Stubbs @ 2008-08-07 12:53 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, git
In-Reply-To: <20080807074117.GA7648@atjola.homenet>
2008/8/7 Björn Steinbrink <B.Steinbrink@gmx.de>:
>> that seems to have got it. so are you going to apply that patch to git proper?
>
> It already is.
Great!
>> <manually deleted "untracked file" here>
>
> Maybe you're ignoring that file? git clean deletes ignored files only if
> you use -x/-X.
>
> Björn
>
That's probably it, I'll try it tomorrow. However, that could be a
problem. There's ignored files I don't want to keep (build artifacts),
and there's ignored files I do want to keep (i.e. .metadata).
Is there a good solution?
--
___________________________
http://stubbisms.wordpress.com/
^ permalink raw reply
* Re: [PATCH] Documentation: clarify that git-commit only works with tracked files
From: Miklos Vajna @ 2008-08-07 11:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jonathan Nieder, git
In-Reply-To: <alpine.DEB.1.00.0808070239120.9611@pacific.mpi-cbg.de.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 459 bytes --]
On Thu, Aug 07, 2008 at 02:39:59AM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Funny. I haven't used CVS for a while now, but I seem to remember that
> "cvs commit newfile.c" without a prior "cvs add newfile.c" is not allowed.
But there is a difference. In most VCSes, you need 'add' once. In git
you need add before every commit. Of course this should be clear after
reading the "How to make a commit" part of the user manual.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git filter-branch --subdirectory-filter, still a mistery
From: Jan Wielemaker @ 2008-08-07 10:14 UTC (permalink / raw)
To: git
In-Reply-To: <200808070950.23754.trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 2880 bytes --]
Hi Thomas,
On Thursday 07 August 2008 09:50:03 am Thomas Rast wrote:
> Jan Wielemaker wrote:
> [...]
>
> > % git filter-branch --subdirectory-filter packages/chr HEAD
> >
> > This indeed creates a nice directory holding only the contents of
> > packages/chr. But, starting qgit I see that all commits, also those
> > that had absolutely nothing to do with this dir are still there.
>
> The trick is to rewrite all refs, not just HEAD. I usually proceed as
> follows:
>
> cp -a repo repo.old # just to keep a backup
> cd repo
> git filter-branch --subdirectory-filter somedir -- --all
>
> The --all tells it to rewrite as many refs as possible. Note that the
> -- is required. Also note that refs/original/* will still point to
> the old commits, so they won't "just vanish". You may want to clone
> the repository or delete them manually once you are sure the
> filter-branch did the right thing.
Thanks. That is moving in the right direction! There are some, possibly
related, problems left (using 1.5.6.GIT). According to git fsck,
my repo is clean. I got:
Ref 'refs/tags/V5.6.50' was rewritten
error: Ref refs/tags/V5.6.50 is at 8678b32f71178019c06aefa40e2d3fb9a2e8ef25
but
expected 2e8aef64e2fed088720a19ac2ffa2481e5bc7806
fatal: Cannot lock the ref 'refs/tags/V5.6.50'.
Could not rewrite refs/tags/V5.6.50
Now, if I look in .git/packed-refs, I see this (i.e. a second line with
a ^) for all refs that cause problems:
274ec8ac671542206ba3567ff5d72b3e54c5603c refs/tags/V5.6.59
^28920c3c0a184698d9cd15a65cd643367200bbf5
faf203f9d9e350d84b6b38b7746e710b6232fc97 refs/tags/V5.6.58
^1edb1adedcc47ec15c3242234cc6b7ede94bbfba
48488c871227beabcb3ba167b737d6e33ced65bc refs/tags/V5.6.57
^766587b09e3d2f09c87b03ad0d7faf3529c9dcff
After a bit of puzzling I discovered the the SHA1 after the ^ refers to
the actual commit and I changed all these to `lightweight' tags by
putting the SHA1 behind ^ before the tag itself. I wrote a little
sh/awk script to automate this (attached).
Now it runs to the end. Unfortunagtely the history is completely
screwed up :-(:
* There are a lot of commits that are not related to the dir
* Commits start long before the directory came into existence,
Looks like it just shows the whole project at this place.
I think the problem is related to the fact that the directory I want to
filter didn't exists at the start of the project. Looking at
git-rev-list, I found --remove-empty, so I added that after the --all,
but that doesn't appear to help. I must admit I don't really know what
I'm doing (though I still think the result I want it well defined and
its hard to imagine I'm the only person who wants this).
If someone wants to help: clone git://gollem.science.uva.nl/home/git/pl.git
and try to filter the dir packages/chr. You can browse the git at
http://gollem.science.uva.nl/git/pl.git
Thanks --- Jan
[-- Attachment #2: git-lightweight-tags --]
[-- Type: application/x-shellscript, Size: 677 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: clarify that git-commit only works with tracked files
From: Peter Krefting @ 2008-08-07 11:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0808070239120.9611@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin:
> Funny. I haven't used CVS for a while now, but I seem to remember
> that "cvs commit newfile.c" without a prior "cvs add newfile.c" is
> not allowed.
Only to add the file to revision control initially. After that, you
just use commit to create new revisions.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.0-rc2
From: David Miller @ 2008-08-07 12:26 UTC (permalink / raw)
To: gitster; +Cc: peterz, git, linux-kernel
In-Reply-To: <7v3alhjgau.fsf@gitster.siamese.dyndns.org>
From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 07 Aug 2008 03:00:25 -0700
> Peter Zijlstra <peterz@infradead.org> writes:
>
> > Quick question - where does one go to find out the cool new features
> > that make it 1.6 and should convince me to upgrade and try this whicked
> > new release?
>
> Draft release notes for 1.6.0 was posted to the list some time ago
> already, but as always:
>
> http://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.6.0.txt
Just FYI, I have some issue with 1.6.x git when pulling remotely from
it on sparc64. I suspect it is the usual unaligned access issue and I
will debug it further soon.
^ permalink raw reply
* Re: [PATCH 2/2] git-svn: Allow deep branch names by supporting multi-globs
From: Eric Wong @ 2008-08-07 9:00 UTC (permalink / raw)
To: Marcus Griep; +Cc: Git Mailing List
In-Reply-To: <489A025C.50507@griep.us>
Marcus Griep <marcus@griep.us> wrote:
> Some repositories use a deep branching strategy, such as:
> branches/1.0/1.0.rc1
> branches/1.0/1.0.rc2
> branches/1.0/1.0.rtm
> branches/1.0/1.0.gold
>
> Only allowing a single glob stiffles this.
>
> This change allows for a single glob 'set' to accept this deep branching
> strategy.
>
> The ref glob depth must match the branch glob depth. When using the -b or -t
> options for init or clone, this is automatically done.
>
> For example, using the above branches:
> svn-remote.svn.branches = branches/*/*:refs/remote/*/*
> gives the following branch names:
> 1.0/1.0.rc1
> 1.0/1.0.rc2
> 1.0/1.0.rtm
> 1.0/1.0.gold
Hi Marcus,
This looks awesome. Some folks have been wanting to do this for a
long time but I was always too lazy to touch this code.
Unfortunately, I'm having trouble applying your patches due to
whitespace conversion issues with your MUA. I suggest taking a look at
Documentation/SubmittingPatches on how to submit easily applyable
patches to the mailing list.
I usually use git-send-email myself, but sometimes mutt, too.
Also, there are some long lines that need to be wrapped at
80 characters or less to conform to the existing coding
conventions.
I look forward to applying and testing your patches,
Thank you!
--
Eric Wong
^ 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