* [DON'T MERGE PATCH 7/7]
From: Pierre Habouzit @ 2007-09-21 7:39 UTC (permalink / raw)
To: gitster, git
In-Reply-To: <20070921070329.GB5689@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]
On Fri, Sep 21, 2007 at 07:03:29AM +0000, Pierre Habouzit wrote:
> On jeu, sep 20, 2007 at 10:05:06 +0000, Pierre Habouzit wrote:
> > On mer, sep 19, 2007 at 10:42:16 +0000, Pierre Habouzit wrote:
> >
> > As someone pointed to me off-list the above should be:
> > + if (rf_one) {
> > + (*write_ref)[targets] = xmemdupz(rf_one + 1, buf.len - (rf_one + 1 - buf.buf));
> > + } else {
> >
> > Or better:
> > + if (rf_one) {
> > + rf_one++; /* skip \t */
> > + (*write_ref)[targets] = xmemdupz(rf_one, buf.buf + buf.len - rf_one);
> > + } else {
> >
> > Which is definitely more readable.
>
> damn it was not the error that was reported to me, there is another
> one, I'll roll a new patch, sorry :/
Okay this patch is worthless, the previous version worked the same, I
totally missed what it did. I should not code when I'm too tired, I'm
sorry.
Don't merge patch 7/7 it's broken.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 7/7] Avoid duplicating memory, and use xmemdupz instead of xstrdup.
From: Pierre Habouzit @ 2007-09-21 7:03 UTC (permalink / raw)
To: gitster, git
In-Reply-To: <1190241736-30449-8-git-send-email-madcoder@debian.org>
[-- Attachment #1: Type: text/plain, Size: 829 bytes --]
On jeu, sep 20, 2007 at 10:05:06 +0000, Pierre Habouzit wrote:
> On mer, sep 19, 2007 at 10:42:16 +0000, Pierre Habouzit wrote:
>
> As someone pointed to me off-list the above should be:
> + if (rf_one) {
> + (*write_ref)[targets] = xmemdupz(rf_one + 1, buf.len - (rf_one + 1 - buf.buf));
> + } else {
>
> Or better:
> + if (rf_one) {
> + rf_one++; /* skip \t */
> + (*write_ref)[targets] = xmemdupz(rf_one, buf.buf + buf.len - rf_one);
> + } else {
>
> Which is definitely more readable.
damn it was not the error that was reported to me, there is another
one, I'll roll a new patch, sorry :/
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [SUPERSEDES PATCH 2/7] nfv?asprintf are broken without va_copy, workaround them.
From: Pierre Habouzit @ 2007-09-21 7:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejgsk0ev.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2660 bytes --]
On Fri, Sep 21, 2007 at 06:17:12AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > This reinstates the trace_argv_printf API. The implementation is
> > stupid, but is rewritten in a latter commit. I didn't wanted to bother
> > optimizing it.
> > ...
> > cache.h | 2 -
> > imap-send.c | 13 ++++++++
> > merge-recursive.c | 74 ++++++++++++++++++++-----------------------
> > trace.c | 90 ++++++++++++++++-------------------------------------
> > 4 files changed, 74 insertions(+), 105 deletions(-)
> > ...
> > diff --git a/merge-recursive.c b/merge-recursive.c
> > index 14b56c2..4e27549 100644
> > --- a/merge-recursive.c
> > +++ b/merge-recursive.c
> > @@ -85,63 +85,57 @@ struct stage_data
> > +static void flush_output(void)
> > {
> > + if (obuf.len) {
> > + fputs(obuf.buf, stdout);
> > + strbuf_reset(&obuf);
> > }
> > }
>
> This assumes obuf.buf has necessary indentations and line
> breaks, which is sensible. However...
>
> > +static void output(int v, const char *fmt, ...)
> > {
> > + if (show(v)) {
> > + int len;
> > + va_list ap;
>
> Yuck, this single if statement covers the entirety of the
> function. Let's do
>
> if (!show(v))
> return;
>
> > + strbuf_grow(&obuf, call_depth);
> > + memset(obuf.buf + obuf.len, ' ', call_depth);
> > + strbuf_setlen(&obuf, obuf.len + call_depth);
>
> Per depth indentation used to be two whitespaces.
>
> > + va_start(ap, fmt);
> > + len = vsnprintf(obuf.buf, strbuf_avail(&obuf) + 1, fmt, ap);
> > + va_end(ap);
>
> And you overwrite whatever used to be in the buffer, including
> the previous buffered message and indentation you added. Not
> nice...
ooops, I wrote it too quickly.
> I'll squash this on top of yours for now.
works for me except the little remark in the end :)
> merge-recursive.c | 45 +++++++++++++++++++++++----------------------
> 1 files changed, 23 insertions(+), 22 deletions(-)
>
> + strbuf_setlen(&obuf, obuf.len + len);
> + strbuf_add(&obuf, "\n", 1);
rather use strbuf_addch(&obuf, '\n')
> + if (!buffer_output)
> + flush_output();
> }
>
> static void output_commit_title(struct commit *commit)
> -
> 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
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-svnimport: Use separate arguments in the pipe for git-rev-parse
From: Junio C Hamano @ 2007-09-21 6:59 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Dan Libby, git
In-Reply-To: <20070921061122.GI11204@kiste.smurf.noris.de>
Matthias Urlichs <smurf@smurf.noris.de> writes:
>> we do not like 'Cristian new code' as a tag name.
>
> Duh? That's a perfectly valid tag name.
Is it?
$ man git-check-ref-format
^ permalink raw reply
* Re: cvsimport bug on branches [was: conversion to git]
From: Steffen Prohaska @ 2007-09-21 5:18 UTC (permalink / raw)
To: Eric Blake; +Cc: m4-patches, Jim Meyering, git
In-Reply-To: <46F31BBB.1040901@byu.net>
On Sep 21, 2007, at 3:17 AM, Eric Blake wrote:
> According to Eric Blake on 9/19/2007 5:13 PM:
>> I'm working on converting M4 to git.
>>
>> The initial git conversion is complete. Feel free to check it out:
>>
>> http://git.savannah.gnu.org/gitweb/?p=m4.git
>
> Unfortunately, after publishing this repository, I noticed that
> there is a
> bug in git-cvsimport, when a vendor branch is created that contains
> fewer
> files than the point it branched from. Those files were not
> removed from
> the commit on the new branch, which means the git repository
> contains too
> many files compared to what the CVS repository had for any checkout
> along
> the branch.
>
> [...]
git-cvsimport may have more problems, see e.g.
http://marc.info/?l=git&m=118385565913953&w=2
http://marc.info/?l=git&m=118260312708709&w=2
> Now that the repository is published, what's the best way to
> correct the
> history for the git m4-1.4.1 tag, to correctly pick the m4-1.4
> commit as
> its parent, and to omit the files that were intentionally omitted
> from the
> CVS branch it was imported from?
Hard to say. The best is to avoid git-cvsimport if you need
to import branches correctly.
And you should do validate the result of any import by comparing
a working copy checked out from CVS with a working copy checked
out from git.
Never trust the cvs to git importers.
> What needs to be done to git-cvsimport to make it recognize files that
> were omitted from CVS branch creation points, to avoid this problem
> in the
> first place?
I'd recommend not to use git-cvsimport but better use
a different converter.
For me parsecvs [1] works.
I'd also give cvs2svn's git support [2] a try.
cvs2svn strives much harder to report errors and handle complex
history correctly. parsecvs for example just crashes on corrupted
RCS files, while cvs2svn reports the problem. But if your CVS
repository is good parsecvs is much faster.
fromcvs/togit was also mentioned a couple of times on the list.
It worked for me the last time I tried it. But I did no in depth
validation of the result.
I still believe it would be good to add a warning to the
documentation of git-cvsimport and provide links to alternatives.
Steffen
[1] http://gitweb.freedesktop.org/?p=users/keithp/parsecvs.git
[2] http://marc.info/?l=git&m=118592701426175&w=2
^ permalink raw reply
* Re: [SUPERSEDES PATCH 2/7] nfv?asprintf are broken without va_copy, workaround them.
From: Junio C Hamano @ 2007-09-21 6:17 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20070920084311.GB2053@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> This reinstates the trace_argv_printf API. The implementation is
> stupid, but is rewritten in a latter commit. I didn't wanted to bother
> optimizing it.
> ...
> cache.h | 2 -
> imap-send.c | 13 ++++++++
> merge-recursive.c | 74 ++++++++++++++++++++-----------------------
> trace.c | 90 ++++++++++++++++-------------------------------------
> 4 files changed, 74 insertions(+), 105 deletions(-)
> ...
> diff --git a/merge-recursive.c b/merge-recursive.c
> index 14b56c2..4e27549 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -85,63 +85,57 @@ struct stage_data
> +static void flush_output(void)
> {
> + if (obuf.len) {
> + fputs(obuf.buf, stdout);
> + strbuf_reset(&obuf);
> }
> }
This assumes obuf.buf has necessary indentations and line
breaks, which is sensible. However...
> +static void output(int v, const char *fmt, ...)
> {
> + if (show(v)) {
> + int len;
> + va_list ap;
Yuck, this single if statement covers the entirety of the
function. Let's do
if (!show(v))
return;
> + strbuf_grow(&obuf, call_depth);
> + memset(obuf.buf + obuf.len, ' ', call_depth);
> + strbuf_setlen(&obuf, obuf.len + call_depth);
Per depth indentation used to be two whitespaces.
> + va_start(ap, fmt);
> + len = vsnprintf(obuf.buf, strbuf_avail(&obuf) + 1, fmt, ap);
> + va_end(ap);
And you overwrite whatever used to be in the buffer, including
the previous buffered message and indentation you added. Not
nice...
I'll squash this on top of yours for now.
merge-recursive.c | 45 +++++++++++++++++++++++----------------------
1 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 4e27549..86767e6 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -108,34 +108,35 @@ static void flush_output(void)
static void output(int v, const char *fmt, ...)
{
- if (show(v)) {
- int len;
- va_list ap;
+ int len;
+ va_list ap;
- strbuf_grow(&obuf, call_depth);
- memset(obuf.buf + obuf.len, ' ', call_depth);
- strbuf_setlen(&obuf, obuf.len + call_depth);
+ if (!show(v))
+ return;
+
+ strbuf_grow(&obuf, call_depth * 2 + 2);
+ memset(obuf.buf + obuf.len, ' ', call_depth * 2);
+ strbuf_setlen(&obuf, obuf.len + call_depth * 2);
+
+ va_start(ap, fmt);
+ len = vsnprintf(obuf.buf + obuf.len, strbuf_avail(&obuf), fmt, ap);
+ va_end(ap);
+ if (len < 0)
+ len = 0;
+ if (len >= strbuf_avail(&obuf)) {
+ strbuf_grow(&obuf, len + 2);
va_start(ap, fmt);
- len = vsnprintf(obuf.buf, strbuf_avail(&obuf) + 1, fmt, ap);
+ len = vsnprintf(obuf.buf + obuf.len, strbuf_avail(&obuf), fmt, ap);
va_end(ap);
-
- if (len < 0)
- len = 0;
- if (len > strbuf_avail(&obuf)) {
- strbuf_grow(&obuf, len);
- va_start(ap, fmt);
- len = vsnprintf(obuf.buf, strbuf_avail(&obuf) + 1, fmt, ap);
- va_end(ap);
- if (len > strbuf_avail(&obuf)) {
- die("this should not happen, your snprintf is broken");
- }
+ if (len >= strbuf_avail(&obuf)) {
+ die("this should not happen, your snprintf is broken");
}
-
- strbuf_setlen(&obuf, obuf.len + len);
- if (!buffer_output)
- flush_output();
}
+ strbuf_setlen(&obuf, obuf.len + len);
+ strbuf_add(&obuf, "\n", 1);
+ if (!buffer_output)
+ flush_output();
}
static void output_commit_title(struct commit *commit)
^ permalink raw reply related
* Re: [PATCH] git-svnimport: Use separate arguments in the pipe for git-rev-parse
From: Matthias Urlichs @ 2007-09-21 6:11 UTC (permalink / raw)
To: Dan Libby; +Cc: Junio C Hamano, git
In-Reply-To: <200709201340.17023.danda@osc.co.cr>
Hi,
Dan Libby:
> we do not like 'Cristian new code' as a tag name.
Duh? That's a perfectly valid tag name.
I have no idea why git croaked on this one.
Please run
strace -f -s300 -eexecve git-svnimport ... 2>&1 | \
grep check-ref-format | grep -v ENOENT
and mail me the output, replacing the "..." with your normal arguments
of course.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Taken as a whole, the universe is absurd.
-- Walter Savage Landor
^ permalink raw reply
* stg branch --delete doesn't work
From: Aneesh Kumar @ 2007-09-21 4:40 UTC (permalink / raw)
To: Git Mailing List, catalin.marinas
[review@linux-review-ext4]$ git checkout master
Switched to branch "master"
[master@linux-review-ext4]$ stg branch --delete --force review
Deleting branch "review" ...
fatal: Needed a single revision
stg branch: refs/heads/review does not exist
And it leaves in .git/config
[branch "test2.stgit"]
stackformatversion = 2
So a later stg init also fails.
-aneesh
^ permalink raw reply
* Re: [PATCH] Add git-rev-list --invert-match
From: Jeff King @ 2007-09-21 4:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bart Trojanowski, git
In-Reply-To: <Pine.LNX.4.64.0709201403540.28395@racer.site>
On Thu, Sep 20, 2007 at 02:12:54PM +0100, Johannes Schindelin wrote:
> Further, it probably makes sense to have the option to say _both_: "Find
> me a commit that contains Bart in one line, but not Simpson, and that
> does not contain the word "Sverdoolaege" at all."
This is perhaps a little hack-ish compared to better grep support in the
core, but I find complex logic through command line options to be
somewhat unreadable. I prefer something more Perl-ish like this:
git-revgrep 'message =~ /bart/i
&& message !~ /Simpson/
&& author_name !~ /Sverdoolaege/'
or if you want to get complex:
git-revgrep '
return 0 if message =~ /Sverdoolaege/;
while(my $line = message =~ /^(.*bart.*)/gmi) {
return 1 if $line !~ /Simpson/;
}
return 0;'
where revgrep is the script below:
-- >8 --
#!/usr/bin/perl
use strict;
my $matcher = shift || '';
my $matcher_sub = eval "sub { $matcher }";
die $@ if $@;
my $input = do {
if(@ARGV == 1 && $ARGV[0] eq '-') {
\*STDIN;
}
else {
open(my $fh, '-|', qw(git log --pretty=raw), @ARGV)
or die "unable to open pipe to git log: $!";
$fh;
}
};
our $commit;
while(<$input>) {
if(/^commit /) {
try_match() if $commit;
$commit = $_;
}
else {
$commit .= $_;
}
}
try_match() if $commit;
exit 0;
sub try_match {
if($matcher_sub->()) {
print STDOUT $commit;
}
}
sub parse_person { $_[0] =~ /([^<]*) <([^>]*)> (.*)/ }
sub parse_author { return parse_person($commit =~ /^author (.*)/m) }
sub parse_committer { return parse_person($commit =~ /^committer (.*)/m) }
sub author_name { return (parse_author)[0] }
sub author_email { return (parse_author)[1] }
sub author_time { return (parse_author)[2] }
sub committer_name { return (parse_committer)[0] }
sub committer_email { return (parse_committer)[1] }
sub committer_time { return (parse_committer)[2] }
sub message { return ($commit =~ /^( +.*?^$)/ms)[0] }
^ permalink raw reply
* Re: [PATCH] git-svn: handle changed svn command-line syntax
From: Sam Vilain @ 2007-09-21 3:27 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <46F33734.3080408@vilain.net>
Sam Vilain wrote:
> Sam Vilain wrote:
>> Previously, if you passed a revision and a path to svn, it meant to look
>> back at that revision and select that path. New behaviour is to get the
>> path then go back to the revision. The old syntax is selected with new
>> syntax PATH@REV. This new syntax is not supported by the old tools, so we
>> have to try both in turn.
>
> Blast, this analysis is wrong. Hold off, I'll see what's really going
> on and re-submit.
ok, figured it out :)
I was close! I was just thrown off by 'svn ls PATH@REV'
The patch is the same, just the description has changed.
Subject: [PATCH] git-svn: handle changed svn cp command-line syntax
Previously, if you passed a revision and a path to svn cp, it meant to look
back at that revision and select that path. New behaviour is to get the
path then go back to the revision (like other commands that accept @REV
or -rREV do). The more consistent syntax is not supported by the old
tools, so we have to try both in turn.
---
t/t9104-git-svn-follow-parent.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t9104-git-svn-follow-parent.sh b/t/t9104-git-svn-follow-parent.sh
index 9eab945..7ba7630 100755
--- a/t/t9104-git-svn-follow-parent.sh
+++ b/t/t9104-git-svn-follow-parent.sh
@@ -51,8 +51,10 @@ test_expect_success 'init and fetch from one svn-remote' "
"
test_expect_success 'follow deleted parent' "
- svn cp -m 'resurrecting trunk as junk' \
- -r2 $svnrepo/trunk $svnrepo/junk &&
+ (svn cp -m 'resurrecting trunk as junk' \
+ $svnrepo/trunk@2 $svnrepo/junk ||
+ svn cp -m 'resurrecting trunk as junk' \
+ -r2 $svnrepo/trunk $svnrepo/junk) &&
git config --add svn-remote.svn.fetch \
junk:refs/remotes/svn/junk &&
git-svn fetch -i svn/thunk &&
--
1.5.3.2.3.g2f2dcc-dirty
^ permalink raw reply related
* Re: [PATCH] git-svn: handle changed svn command-line syntax
From: Sam Vilain @ 2007-09-21 3:15 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <11903401552164-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain wrote:
> Previously, if you passed a revision and a path to svn, it meant to look
> back at that revision and select that path. New behaviour is to get the
> path then go back to the revision. The old syntax is selected with new
> syntax PATH@REV. This new syntax is not supported by the old tools, so we
> have to try both in turn.
Blast, this analysis is wrong. Hold off, I'll see what's really going
on and re-submit.
Sam.
>
> Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
> ---
> t/t9104-git-svn-follow-parent.sh | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/t/t9104-git-svn-follow-parent.sh b/t/t9104-git-svn-follow-parent.sh
> index 9eab945..7ba7630 100755
> --- a/t/t9104-git-svn-follow-parent.sh
> +++ b/t/t9104-git-svn-follow-parent.sh
> @@ -51,8 +51,10 @@ test_expect_success 'init and fetch from one svn-remote' "
> "
>
> test_expect_success 'follow deleted parent' "
> - svn cp -m 'resurrecting trunk as junk' \
> - -r2 $svnrepo/trunk $svnrepo/junk &&
> + (svn cp -m 'resurrecting trunk as junk' \
> + $svnrepo/trunk@2 $svnrepo/junk ||
> + svn cp -m 'resurrecting trunk as junk' \
> + -r2 $svnrepo/trunk $svnrepo/junk) &&
> git config --add svn-remote.svn.fetch \
> junk:refs/remotes/svn/junk &&
> git-svn fetch -i svn/thunk &&
^ permalink raw reply
* [PATCH 0/3] git-svn: pass tests on svn trunk
From: Sam Vilain @ 2007-09-21 2:02 UTC (permalink / raw)
To: Eric Wong; +Cc: git
While svn trunk is a dubious target to integrate with, perhaps these
patches will prove useful to include anyway.
Tested against svn 1.4.2 and svn trunk r26724
^ permalink raw reply
* [PATCH] git-svn: fix test for trunk svn (commit message not needed)
From: Sam Vilain @ 2007-09-21 2:02 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Sam Vilain
In-Reply-To: <1190340155146-git-send-email-sam.vilain@catalyst.net.nz>
The 'svn mv -m "rename to thunk"' was a local operation, therefore not
needing a commit message, it was silently ignored. Newer svn clients will
instead raise an error.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
---
t/t9104-git-svn-follow-parent.sh | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/t/t9104-git-svn-follow-parent.sh b/t/t9104-git-svn-follow-parent.sh
index d8f9cab..9eab945 100755
--- a/t/t9104-git-svn-follow-parent.sh
+++ b/t/t9104-git-svn-follow-parent.sh
@@ -19,8 +19,7 @@ test_expect_success 'initialize repo' "
poke trunk/readme &&
svn commit -m 'another commit' &&
svn up &&
- svn mv -m 'rename to thunk' trunk thunk &&
- svn up &&
+ svn mv trunk thunk &&
echo goodbye >> thunk/readme &&
poke thunk/readme &&
svn commit -m 'bye now' &&
--
1.5.2.4
^ permalink raw reply related
* [PATCH] git-svn: fix test for trunk svn (transaction out of date)
From: Sam Vilain @ 2007-09-21 2:02 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Sam Vilain
In-Reply-To: <11903401551014-git-send-email-sam.vilain@catalyst.net.nz>
Older svn clients did not raise a 'transaction out of date' error here, but
trunk does - so 'svn up'.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
---
t/t9101-git-svn-props.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/t/t9101-git-svn-props.sh b/t/t9101-git-svn-props.sh
index 622ea1c..5aac644 100755
--- a/t/t9101-git-svn-props.sh
+++ b/t/t9101-git-svn-props.sh
@@ -140,6 +140,7 @@ test_expect_success 'test show-ignore' "
cd test_wc &&
mkdir -p deeply/nested/directory &&
svn add deeply &&
+ svn up &&
svn propset -R svn:ignore 'no-such-file*' .
svn commit -m 'propset svn:ignore'
cd .. &&
--
1.5.2.4
^ permalink raw reply related
* [PATCH] git-svn: handle changed svn command-line syntax
From: Sam Vilain @ 2007-09-21 2:02 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Sam Vilain
In-Reply-To: <11903401551812-git-send-email-sam.vilain@catalyst.net.nz>
Previously, if you passed a revision and a path to svn, it meant to look
back at that revision and select that path. New behaviour is to get the
path then go back to the revision. The old syntax is selected with new
syntax PATH@REV. This new syntax is not supported by the old tools, so we
have to try both in turn.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
---
t/t9104-git-svn-follow-parent.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t9104-git-svn-follow-parent.sh b/t/t9104-git-svn-follow-parent.sh
index 9eab945..7ba7630 100755
--- a/t/t9104-git-svn-follow-parent.sh
+++ b/t/t9104-git-svn-follow-parent.sh
@@ -51,8 +51,10 @@ test_expect_success 'init and fetch from one svn-remote' "
"
test_expect_success 'follow deleted parent' "
- svn cp -m 'resurrecting trunk as junk' \
- -r2 $svnrepo/trunk $svnrepo/junk &&
+ (svn cp -m 'resurrecting trunk as junk' \
+ $svnrepo/trunk@2 $svnrepo/junk ||
+ svn cp -m 'resurrecting trunk as junk' \
+ -r2 $svnrepo/trunk $svnrepo/junk) &&
git config --add svn-remote.svn.fetch \
junk:refs/remotes/svn/junk &&
git-svn fetch -i svn/thunk &&
--
1.5.2.4
^ permalink raw reply related
* cvsimport bug on branches [was: conversion to git]
From: Eric Blake @ 2007-09-21 1:17 UTC (permalink / raw)
To: m4-patches, Jim Meyering, git
In-Reply-To: <loom.20070920T010842-272@post.gmane.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Eric Blake on 9/19/2007 5:13 PM:
> I'm working on converting M4 to git.
>
> The initial git conversion is complete. Feel free to check it out:
>
> http://git.savannah.gnu.org/gitweb/?p=m4.git
Unfortunately, after publishing this repository, I noticed that there is a
bug in git-cvsimport, when a vendor branch is created that contains fewer
files than the point it branched from. Those files were not removed from
the commit on the new branch, which means the git repository contains too
many files compared to what the CVS repository had for any checkout along
the branch.
For example, look at the m4-1.4.1 tag. In CVS,
http://cvs.savannah.gnu.org/viewvc/m4/?root=m4&hideattic=0&pathrev=m4-1_4_1
shows the following:
ABOUT-NLS (dead) No revisions exist on m4-1_4_1
and for the file ChangeLog, the predecessor of m4-1_4_1 (rev 1.1.1.1.2.1)
was m4-1_4 (rev 1.1.1.1):
http://cvs.savannah.gnu.org/viewvc/m4/ChangeLog?hideattic=0&view=log&root=m4&pathrev=m4-1_4_1
But after git-cvsimport (using git 1.5.3), tag m4-1.4.1 is shown on the
branch-1_4 branch, but with unrelated m4-1.4ppre2 as parent, instead of
the correct m4-1.4:
http://git.sv.gnu.org/gitweb/?p=m4.git;a=shortlog;h=ab2ce6be
and as a result, the tree includes ABOUT-NLS (which was correctly a part
of the m4-1.4ppre2 tag on the master branch):
http://git.sv.gnu.org/gitweb/?p=m4.git;a=tree;h=ab2ce6bec48;hb=ab2ce6bec4
Now that the repository is published, what's the best way to correct the
history for the git m4-1.4.1 tag, to correctly pick the m4-1.4 commit as
its parent, and to omit the files that were intentionally omitted from the
CVS branch it was imported from?
What needs to be done to git-cvsimport to make it recognize files that
were omitted from CVS branch creation points, to avoid this problem in the
first place?
- --
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG8xu684KuGfSFAYARAjd8AJ0eOWw1TFGt4zpQKIDFTGRjxzI/cgCghBpM
W91wfRwc8Q2hoMO1WCWYtzM=
=zzNR
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] new test from the submodule chapter of the user manual
From: Joel Becker @ 2007-09-20 22:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, Junio C Hamano, git, J. Bruce Fields
In-Reply-To: <Pine.LNX.4.64.0709201946410.28395@racer.site>
On Thu, Sep 20, 2007 at 07:47:32PM +0100, Johannes Schindelin wrote:
> > Silly question: why use the '&&' when you can 'set -e'? As it
> > currently stands, a failure will still go back around the loop...
>
> A "set -e" will make the script exit AFAIR. That's not what we want. A
> simple "|| break" after the "cd .." will work, though.
Oh, drat. It's run in eval, not a subshell.
Joel
--
Life's Little Instruction Book #94
"Make it a habit to do nice things for people who
will never find out."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: [PATCH] [git-p4] Detect exec bit in more cases.
From: Junio C Hamano @ 2007-09-20 22:53 UTC (permalink / raw)
To: David Brown; +Cc: git, Simon Hausmann
In-Reply-To: <20070920151637.GA26873@old.davidb.org>
David Brown <git@davidb.org> writes:
> On Wed, Sep 19, 2007 at 09:03:50PM +0200, Simon Hausmann wrote:
>>On Wednesday 19 September 2007 20:15:03 David Brown wrote:
>
>>> git-p4 was missing the execute bit setting if the file had other attribute
>>> bits set.
>>> ---
>
>>I'm fine with this, so unless you find a better way:
>>
>>Acked-By: Simon Hausmann <simon@lst.de>
>
> I sent out an improved version of this patch yesterday
> <1190232768445-git-send-email-git@davidb.org> that I'd like to get
> approved. I guess I'm not quite sure what happens at this point with a
> patch.
I still have that *768445* message as "the last one proposed as
better than previous ones" in my mbox.
Simon?
^ permalink raw reply
* Re: [PATCH 7/7] Avoid duplicating memory, and use xmemdupz instead of xstrdup.
From: Pierre Habouzit @ 2007-09-20 22:05 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1190241736-30449-8-git-send-email-madcoder@debian.org>
[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]
On mer, sep 19, 2007 at 10:42:16 +0000, Pierre Habouzit wrote:
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
> walker.c | 23 +++++++++--------------
> 1 files changed, 9 insertions(+), 14 deletions(-)
>
> diff --git a/walker.c b/walker.c
> index 397b80d..0abdd64 100644
> --- a/walker.c
> +++ b/walker.c
> @@ -213,24 +213,19 @@ int walker_targets_stdin(char ***target, const char ***write_ref)
> struct strbuf buf;
> *target = NULL; *write_ref = NULL;
> strbuf_init(&buf, 0);
> - while (1) {
> - char *rf_one = NULL;
> - char *tg_one;
> -
> - if (strbuf_getline(&buf, stdin, '\n') == EOF)
> - break;
> - tg_one = buf.buf;
> - rf_one = strchr(tg_one, '\t');
> - if (rf_one)
> - *rf_one++ = 0;
> + while (strbuf_getline(&buf, stdin, '\n') != EOF) {
> + char *rf_one = memchr(buf.buf, '\t', buf.len);
>
> if (targets >= targets_alloc) {
> - targets_alloc = targets_alloc ? targets_alloc * 2 : 64;
> - *target = xrealloc(*target, targets_alloc * sizeof(**target));
> + ALLOC_GROW(target, targets, targets_alloc);
> *write_ref = xrealloc(*write_ref, targets_alloc * sizeof(**write_ref));
> }
> - (*target)[targets] = xstrdup(tg_one);
> - (*write_ref)[targets] = rf_one ? xstrdup(rf_one) : NULL;
> + if (rf_one) {
> + (*write_ref)[targets] = xmemdupz(rf_one, buf.len - (rf_one - buf.buf));
> + } else {
As someone pointed to me off-list the above should be:
+ if (rf_one) {
+ (*write_ref)[targets] = xmemdupz(rf_one + 1, buf.len - (rf_one + 1 - buf.buf));
+ } else {
Or better:
+ if (rf_one) {
+ rf_one++; /* skip \t */
+ (*write_ref)[targets] = xmemdupz(rf_one, buf.buf + buf.len - rf_one);
+ } else {
Which is definitely more readable.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] User Manual: add a chapter for submodules
From: Miklos Vajna @ 2007-09-20 22:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields
In-Reply-To: <7v1wcum0ox.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 288 bytes --]
On Wed, Sep 19, 2007 at 09:15:58PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> Looks Ok to me, although I didn't verify the examples by
> actually running them myself this time (last round I did).
just wanted to mention that i did verify them before sending the patch.
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add git-rev-list --invert-match
From: Johannes Schindelin @ 2007-09-20 21:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bart Trojanowski, git
In-Reply-To: <7vtzppj9d1.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 20 Sep 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Further, it probably makes sense to have the option to say _both_:
> > "Find me a commit that contains Bart in one line, but not Simpson, and
> > that does not contain the word "Sverdoolaege" at all."
>
> Yeah. And I think we would also want to have that at the
> underlying "grep" layer wouldn't we?
That's what I tried to get at... Already on IRC, I tried to direct the
attention to that thread on the list... There I had an ugly patch, which
was incomplete, mainly because I did not sort out the semantics first.
But the idea was to put this into grep.c so that both git-log and git-grep
could benefit from that feature.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/3] the return of the strbuf
From: Johannes Schindelin @ 2007-09-20 21:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Pierre Habouzit, git
In-Reply-To: <7v1wctkoao.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 20 Sep 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Mon, 17 Sep 2007, Shawn O. Pearce wrote:
> >
> >> $ git log --pretty=format:%an --since=6.months.ago -- fast-import.c \
> >> | sort | uniq -c | sort -nr
> >> 14 Shawn O. Pearce
> >> 3 Pierre Habouzit
> >> 3 Junio C Hamano
> >> 2 Simon Hausmann
> >> 2 Alex Riesen
> >> 1 Theodore Ts'o
> >> 1 Sven Verdoolaege
> >> 1 Sami Farin
> >> 1 Nicolas Pitre
> >> 1 Luiz Fernando N. Capitulino
> >> 1 Dana L. How
> >
> > FWIW I'd do
> >
> > git shortlog -n --since=6.months.ago HEAD -- fast-import.c|grep "^[A-Z]"
> >
> > instead...
>
> I am sure you certainly meant a single command without grep, like:
>
> $ git shortlog -n -s --since=6.months.ago HEAD -- fast-import.c
Hehe. I said "I'd do" ;-)
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] Add git-rev-list --invert-match
From: Junio C Hamano @ 2007-09-20 21:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bart Trojanowski, git
In-Reply-To: <Pine.LNX.4.64.0709201403540.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Further, it probably makes sense to have the option to say _both_: "Find
> me a commit that contains Bart in one line, but not Simpson, and that
> does not contain the word "Sverdoolaege" at all."
Yeah. And I think we would also want to have that at the
underlying "grep" layer wouldn't we?
^ permalink raw reply
* Re: [PATCH] new test from the submodule chapter of the user manual
From: Miklos Vajna @ 2007-09-20 21:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Joel Becker, Junio C Hamano, git, J. Bruce Fields
In-Reply-To: <Pine.LNX.4.64.0709201946410.28395@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]
On Thu, Sep 20, 2007 at 07:47:32PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > +test_expect_success "create the submodules" '
> > > + for i in a b c d
> > > + do
> > > + mkdir $i &&
> > > + cd $i &&
> > > + git init &&
> > > + echo "module $i" > $i.txt &&
> > > + git add $i.txt &&
> > > + git commit -m "Initial commit, submodule $i" &&
> > > + cd ..
> > > + done
> >
> > Silly question: why use the '&&' when you can 'set -e'? As it
> > currently stands, a failure will still go back around the loop...
>
> A "set -e" will make the script exit AFAIR. That's not what we want. A
> simple "|| break" after the "cd .." will work, though.
i know i asked this on irc, but i still a bit confused. the target would
be to jump out from the loop and return 'false' if any of the items
fails
if i understand correctly then this is what Dscho proposes:
$ for i in a b; do echo $i && false || break; done
a
$ echo $?
0
this jumps out from the loop but does not return false
here is my version:
$ for i in a b; do echo $i && false; done
a
b
$ echo $?
1
this one detects the error but does not jump out from the loop. none of
them is perfect, but at least my version fails as long as the last cycle
fails (which is not problem as i think in most cases all or none of the
cycles will fail)
anyway, if you really want, i can change it, but i think it is not the
right thing to do
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] more dependencies in doc generation
From: Alexey Mahotkin @ 2007-09-20 21:42 UTC (permalink / raw)
To: git
In-Reply-To: <bb5b640b0709201343j5a04a554ib91785b43464d4d2@mail.gmail.com>
On 9/21/07, Alexey Mahotkin <squadette@gmail.com> wrote:
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -135,11 +135,11 @@ clean:
> -%.xml : %.txt
> +%.xml : %.txt asciidoc.conf
This change is not needed, sorry.
--
Alexey Mahotkin
http://www.versioncontrolblog.com/
^ 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