* [PATCH] Generate tags with correct timestamp (git-svnimport)
From: Dave O'Neill @ 2007-06-21 21:48 UTC (permalink / raw)
To: git; +Cc: Dave O'Neill
In-Reply-To: <7vzm2u3tov.fsf@assigned-by-dhcp.pobox.com>
Now uses git-tag instead of manually constructing the tag. This gives us a
correct timestamp, removes some crufty code, and makes it work the same as
git-cvsimport.
The generated tags are now lightweight tags instead of tag objects, which may
or may not be the behaviour we want.
Also, remove two unused variables from git-cvsimport.
---
git-cvsimport.perl | 1 -
git-svnimport.perl | 24 ++----------------------
2 files changed, 2 insertions(+), 23 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 433b7fd..69ccb88 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -774,7 +774,6 @@ sub commit {
or die "Cannot write branch $branch for update: $!\n";
if ($tag) {
- my ($in, $out) = ('','');
my ($xtag) = $tag;
$xtag =~ s/\s+\*\*.*$//; # Remove stuff like ** INVALID ** and ** FUNKY **
$xtag =~ tr/_/\./ if ( $opt_u );
diff --git a/git-svnimport.perl b/git-svnimport.perl
index f459762..32832ad 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -868,33 +868,13 @@ sub commit {
}
if($tag) {
- my($in, $out) = ('','');
$last_rev = "-" if %$changed_paths;
# the tag was 'complex', i.e. did not refer to a "real" revision
$dest =~ tr/_/\./ if $opt_u;
- $branch = $dest;
-
- my $pid = open2($in, $out, 'git-mktag');
- print $out ("object $cid\n".
- "type commit\n".
- "tag $dest\n".
- "tagger $committer_name <$committer_email> 0 +0000\n") and
- close($out)
- or die "Cannot create tag object $dest: $!\n";
-
- my $tagobj = <$in>;
- chomp $tagobj;
-
- if ( !close($in) or waitpid($pid, 0) != $pid or
- $? != 0 or $tagobj !~ /^[0123456789abcdef]{40}$/ ) {
- die "Cannot create tag object $dest: $!\n";
- }
- open(C,">$git_dir/refs/tags/$dest") and
- print C ("$tagobj\n") and
- close(C)
- or die "Cannot create tag $branch: $!\n";
+ system('git-tag', $dest, $cid) == 0
+ or die "Cannot create tag $dest: $!\n";
print "Created tag '$dest' on '$branch'\n" if $opt_v;
}
--
1.5.2.2.239.g89630
^ permalink raw reply related
* [PATCH] Let git-svnimport and git-svn clean up SVK commit messages
From: Dave O'Neill @ 2007-06-21 20:51 UTC (permalink / raw)
To: git; +Cc: Dave O'Neill
In-Reply-To: <1182392095394-git-send-email-dmo@roaringpenguin.com>
SVN repositories that have been committed to with SVK will have commits that
contain SVK metadata on the first line of the message:
r12345@hostname: user | YYYY-MM-DD HH:MM:SS -ZZZZ
After importing, git will then pick up this first as the commit title, which
isn't terribly informative in 'git log --pretty=oneline' or gitk.
This patch adds a -k option to git-svnimport and a --fix-svk-message option
(and fixSvkMessage config option) to git-svn. Enabling this option allows
git-svn to try and move that metadata to the end of the commit message,
possibly giving us a more meaningful first line.
---
Documentation/git-svn.txt | 13 +++++++++++++
Documentation/git-svnimport.txt | 6 +++++-
git-svn.perl | 23 ++++++++++++++++++++---
git-svnimport.perl | 15 ++++++++++++---
4 files changed, 50 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index c0d7d95..5cd89f9 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -54,6 +54,8 @@ COMMANDS
Set the 'useSvmProps' option in the [svn-remote] config.
--use-svnsync-props;;
Set the 'useSvnsyncProps' option in the [svn-remote] config.
+--fix-svk-message;;
+ Set the 'fixSvkMessage' option in the [svn-remote] config.
--rewrite-root=<URL>;;
Set the 'rewriteRoot' option in the [svn-remote] config.
--username=<USER>;;
@@ -385,6 +387,14 @@ svn-remote.<name>.rewriteRoot::
the repository with a public http:// or svn:// URL in the
metadata so users of it will see the public URL.
+svn-remote.<name>.fixSvkMessage::
+ SVN repositories that have been committed to with SVK will have
+ commits that contain SVK metadata on the first line of the
+ message, which git will then pick up as the commit title. Enabling
+ this option allows git-svn to try and move that metadata to the end
+ of the commit message, possibly giving us a more meaningful first
+ line.
+
Since the noMetadata, rewriteRoot, useSvnsyncProps and useSvmProps
options all affect the metadata generated and used by git-svn; they
*must* be set in the configuration file before any history is imported
@@ -393,6 +403,9 @@ and these settings should never be changed once they are set.
Additionally, only one of these four options can be used per-svn-remote
section because they affect the 'git-svn-id:' metadata line.
+The fixSvkMessage option may be set in combination with any of these, and
+can be set after import if desired.
+
--
BASIC EXAMPLES
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
index e97d15e..23a54b0 100644
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -11,7 +11,7 @@ SYNOPSIS
--------
[verse]
'git-svnimport' [ -o <branch-for-HEAD> ] [ -h ] [ -v ] [ -d | -D ]
- [ -C <GIT_repository> ] [ -i ] [ -u ] [-l limit_rev]
+ [ -C <GIT_repository> ] [ -i ] [ -k ] [ -u ] [-l limit_rev]
[ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]
[ -s start_chg ] [ -m ] [ -r ] [ -M regex ]
[ -I <ignorefile_name> ] [ -A <author_file> ]
@@ -68,6 +68,10 @@ When importing incrementally, you might need to edit the .git/svn2git file.
Prepend 'rX: ' to commit messages, where X is the imported
subversion revision.
+-k::
+ Remove SVK-style revision/commiter info from the top of commit
+ messages and move it to the bottom.
+
-I <ignorefile_name>::
Import the svn:ignore directory property to files with this
name in each directory. (The Subversion and GIT ignore
diff --git a/git-svn.perl b/git-svn.perl
index 50128d7..1451f0d 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -83,6 +83,7 @@ my %init_opts = ( 'template=s' => \$_template, 'shared:s' => \$_shared,
'trunk|T=s' => \$_trunk, 'tags|t=s' => \$_tags,
'branches|b=s' => \$_branches, 'prefix=s' => \$_prefix,
'minimize-url|m' => \$Git::SVN::_minimize_url,
+ 'fix-svk-message' => \$Git::SVN::_fix_svk_message,
'no-metadata' => sub { $icv{noMetadata} = 1 },
'use-svm-props' => sub { $icv{useSvmProps} = 1 },
'use-svnsync-props' => sub { $icv{useSvnsyncProps} = 1 },
@@ -280,6 +281,11 @@ sub do_git_init_db {
command_noisy('config', "$pfx.$i", $icv{$i});
$set = $i;
}
+
+ if( defined $Git::SVN::_fix_svk_message ) {
+ command_noisy('config', "$pfx.fixSvkMessage", $Git::SVN::_fix_svk_message);
+ }
+
}
sub init_subdir {
@@ -826,7 +832,7 @@ sub working_head_info {
package Git::SVN;
use strict;
use warnings;
-use vars qw/$default_repo_id $default_ref_id $_no_metadata $_follow_parent
+use vars qw/$default_repo_id $default_ref_id $_no_metadata $_follow_parent $_fix_svk_message
$_repack $_repack_flags $_use_svm_props $_head
$_use_svnsync_props $no_reuse_existing $_minimize_url/;
use Carp qw/croak/;
@@ -849,7 +855,7 @@ BEGIN {
# per [svn-remote "..."] section. Command-line options will *NOT*
# override options set in an [svn-remote "..."] section
no strict 'refs';
- for my $option (qw/follow_parent no_metadata use_svm_props
+ for my $option (qw/follow_parent no_metadata use_svm_props fix_svk_message
use_svnsync_props/) {
my $key = $option;
$key =~ tr/_//d;
@@ -1613,7 +1619,18 @@ sub do_git_commit {
}
defined(my $pid = open3(my $msg_fh, my $out_fh, '>&STDERR', @exec))
or croak $!;
- print $msg_fh $log_entry->{log} or croak $!;
+ my $log_msg = $log_entry->{log};
+
+ if( $self->fix_svk_message ) {
+ # Remove SVK cruft in commit message
+ $log_msg =~ s{(r\d+\@[^:]+:\s+\S+\s+\|\s+\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2}\s[\+-]\d{4})\s*}{};
+ if( $1 ) {
+ # and stick it on the end so we don't lose it
+ $log_msg .= "\n$1"
+ }
+ }
+
+ print $msg_fh $log_msg or croak $!;
unless ($self->no_metadata) {
print $msg_fh "\ngit-svn-id: $log_entry->{metadata}\n"
or croak $!;
diff --git a/git-svnimport.perl b/git-svnimport.perl
index f459762..89afdd8 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -32,20 +32,20 @@ $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_k);
sub usage() {
print STDERR <<END;
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]
+ [-d|-D] [-i] [-k] [-u] [-r] [-I ignorefilename] [-s start_chg]
[-m] [-M regex] [-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:kl:mM:o:rs:t:T:SP:R:uv") or usage();
usage if $opt_h;
my $tag_name = $opt_t || "tags";
@@ -835,6 +835,15 @@ sub commit {
$pw->writer();
$pr->reader();
+ if ( $opt_k ) {
+ # Remove SVK cruft in commit message
+ $message =~ s{(r\d+\@[^:]+:\s+\S+\s+\|\s+\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2}\s[\+-]\d{4})\s*}{};
+ if( $1 ) {
+ # and stick it on the end so we don't lose it
+ $message .= "\n$1"
+ }
+ }
+
$message =~ s/[\s\n]+\z//;
$message = "r$revision: $message" if $opt_r;
--
1.5.2.2.239.g89630
^ permalink raw reply related
* Re: [PATCH] git-gui: use "blame -w -C -C" for "where did it come from, originally?"
From: Linus Torvalds @ 2007-06-21 19:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.98.0706211237220.3593@woody.linux-foundation.org>
On Thu, 21 Jun 2007, Linus Torvalds wrote:
>
> I'd personally rather *not* have git-gui make the -w/-M/-C choice for me.
> Why don't you just allow the user to say? Sometimes I might want to see
> who introduced broken whitespace. Let me say
>
> git gui blame -w filename.c
>
> please? Instead of making that choice for me, and then blaming git for
> something that wasn't git's problem.
Side note - this ended up being one reason why "gitk" is so good. It just
passed down the arguments to "git-rev-list", and it allowed me to improve
on the original gitk without gitk ever even _realizing_ it was improved
upon. All the pathname filtering etc was done without gitk ever learning
about it - it "just worked".
Linus
^ permalink raw reply
* Re: [PATCH] git-gui: use "blame -w -C -C" for "where did it come from, originally?"
From: Linus Torvalds @ 2007-06-21 19:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20070621050117.GF8477@spearce.org>
On Thu, 21 Jun 2007, Shawn O. Pearce wrote:
>
> I've wanted to do this since you introduced `git blame -w`. But I
> can't use it, because I cannot trust that -w is there. For example
> it is not in maint, but the new blame viewer from git-gui is.
Actually, I think there's a different fundamental problem, namely that
git-gui doesn't seem to accept parameters.
I'd personally rather *not* have git-gui make the -w/-M/-C choice for me.
Why don't you just allow the user to say? Sometimes I might want to see
who introduced broken whitespace. Let me say
git gui blame -w filename.c
please? Instead of making that choice for me, and then blaming git for
something that wasn't git's problem.
Linus
^ permalink raw reply
* Re: [PATCH] Make list of features auto-managed.
From: Junio C Hamano @ 2007-06-21 19:32 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.0.99.0706211137020.20596@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> Well, just in case my opinion matters...
Well, you already do ;-)
> I don't like this feature list idea at all.
... and thanks for bringing a bit of sanity to this thread.
> When you need git behavior X and you know that it appeared in version Y
> then you only need to test for git_version >= Y. Determining that
> particular Y is much easier after the facts using the commit log than
> trying to anticipate what item should be added to a feature list for
> future usage. In fact the same argument as for not explicitly recording
> renames in commit objects should apply here.
Very well put; that is exactly what I wanted to say in two
messages ago.
^ permalink raw reply
* Re: Fix up "git log --follow" a bit..
From: Junio C Hamano @ 2007-06-21 19:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0706211017190.3593@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> As to "diff_queued_diff", I think it would be better off not as a global
> at all, but as being just an entry in the "struct diff_options" structure,
> but that's a separate issue, and there may be some subtle reason for why
> it's currently a global.
There is no subtle issue that I know of, but I have to double
check. It is just that the code is one of the most ancient part
of the system by now.
^ permalink raw reply
* Re: [PATCH] diffcore-rename: favour identical basenames
From: Linus Torvalds @ 2007-06-21 18:24 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Johannes Schindelin, Shawn O. Pearce, git,
govindsalinas
In-Reply-To: <7vfy4lw5yk.fsf@assigned-by-dhcp.pobox.com>
On Thu, 21 Jun 2007, Junio C Hamano wrote:
>
> This is not an example to draw very useful conclusions, is it?
>
> The heuristics to say '-pc => common' is a more likely rename
> than '-obscure-arch => common' heavily depends on human
> intelligence in the context
Oh, absolutely.
I'm just saying that *if* you see two equally weighed content moves, if
you then prefer the one that has more in common with the name, that's
likely the right choice.
In the actual example I gave, there was no ambiguity: the file contents
were very obvious. But let's sat that you happened to have an example of
two files with 100% identical content that moved, and you had the files
-arch/i386/kernel/pci-pc.c
-arch/alpha/kernel/pci-pc.c
+arch/i386/kernel/pci/common.c
+arch/alpha/kernel/pci/common.c
to match up, how would you do it? Again: they're all identical files: we
can obviously agree that two files got renamed, but what is the pairing.
I'd suggest that if you do it by matching up the similarity of the
filenames (not necessarily "exact same basename"), you'd actually catch
it. In this case, they all have "pci" in them, but the "alpha" similarity
would make you select the right one.
Similarly, in some other cases, the "pci" might be the thing they have in
common, and might be the thing that decides that "oh, those two filenames
look like they might be more of a better pair".
And yes, all of this would trigger only if the file data content match is
non-conclusive. The file data is *more* important, but that doesn't mean
that the file name similarity is *totally* unimportant either.
Linus
^ permalink raw reply
* Re: [PATCH] diffcore-rename: favour identical basenames
From: Junio C Hamano @ 2007-06-21 17:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jeff King, Johannes Schindelin, Shawn O. Pearce, git,
govindsalinas, gitster
In-Reply-To: <alpine.LFD.0.98.0706210910390.3593@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> We'e also had things like
>
> arch/i386/kernel/pci-pc.c -> arch/i386/kernel/pci/common.c
>
> so it's not always the ending of a file that is unchanged, but you still
> often have some "similarity" of the name (ie the "pci" substring is still
> common there).
This is not an example to draw very useful conclusions, is it?
The heuristics to say '-pc => common' is a more likely rename
than '-obscure-arch => common' heavily depends on human
intelligence in the context of a particular project, the kernel,
where there are rules such as "peripherals are tested most
widely on PC architectures, so assume that the vendors might
have tested their stuff only on PCs".
But I do agree that not limiting to basename has values.
Taking example from the "I cannot draw so here is a red big X",
it is quite possible that two red big X's are replaced with
properly rendered icons, while their format modified, like so:
images/ok-button.gif => images/buttons/ok.png
images/cancel-button.gif => images/buttons/cancel.png
This suggests that we might be able to look around to see what
other rename src/target candidate files there are, so that we
can figure out if there is a common pattern (i.e. in the above
example, "patsubst images/%-button.gif,images/buttons/%.png" is
what is going on). If we find such a pattern, we can base the
assignment of "basename similarity bonus" on that pattern.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Linus Torvalds @ 2007-06-21 17:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <alpine.LFD.0.98.0706211005520.3593@woody.linux-foundation.org>
On Thu, 21 Jun 2007, Linus Torvalds wrote:
>
> But "git log" itself really fundamentally has no clue, and you really
> should see "git log" as a *linearization* thing. It linearizes the history
> by creating a one-dimensional streaming log. And within that linearized
> history, there can not be anything like "concurrent renames".
Btw, just to clarify:
This is absolutely not somethign unique to "--follow" and rename
detection!
when you do a simple "git log -p", you will very commonly see the issue of
the same patch being applied twice, and if you think of the linearized
"git log" output is somehow "the Truth" with a capital "T", then you'd
obviously believe that the thing shows up twice in the end result.
It doesn't even have to be the same patch: you can have a patch that shows
up in one branch, and that *never* makes it into the end result, even
though the other branch didn't "undo" it. A merge may have chosen just the
one side (not necessarily due to "-s ours" or anythign like that: a merge
conflict may have been resoled that way).
So the individual logs of changes are not "meaningful" in that sense. Not
with --follow, and not without. They are a locally linearized version of
history, and as such you cannot put the world together just based on them.
You need to have the bigger picture to get the end result.
Does that mean that linearization is meaningless? No, obviously not. Does
it mean that you *can* get confused by it? Yes, absolutely. Does rename
detection add new _ways_ of getting confused? Oh, YES! The example from
the kernel is a great one.
I still think "git log --follow" is actually a really good thing. People
will find places like this where they are confused, and maybe we'll have
to teach them about the effects of linearizing their history, but
especially if you come from the CVS/SVN world, your history has _always_
been linear, so git will always get that case right.
And once you get used to merges, you'll start understanding why git does
what git does more, and then the "git log --follow" behaviour will still
perhaps not be what you might always want at any particular point in time,
but it's something you can understand and deal with.
And it's still hugely preferable to "file identities", which have their
own (and much more fundamental) problems over merges.
Linus
^ permalink raw reply
* Fix up "git log --follow" a bit..
From: Linus Torvalds @ 2007-06-21 17:22 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This fixes "git log --follow" to hopefully not leak memory any more, and
also cleans it up a bit to look more like some of the other functions that
use "diff_queued_diff" (by *not* using it directly as a global in the
code, but by instead just taking a pointer to the diff queue and using
that).
As to "diff_queued_diff", I think it would be better off not as a global
at all, but as being just an entry in the "struct diff_options" structure,
but that's a separate issue, and there may be some subtle reason for why
it's currently a global.
Anyway, no real changes. Instead of having a magical first entry in the
diff-queue, we now end up just keeping the diff-queue clean, and keeping
our "preferred" file pairing in an internal "choice" variable. That makes
it easy to switch the choice around when we find a better one.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
No changes outside of "try_to_follow_renames()", and most of the diff here
really is just trivial re-organizations and the addition of "free all the
filepairs we're not interested in.
Updated the comments a bit to match.
tree-diff.c | 37 ++++++++++++++++++++++++++++---------
1 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/tree-diff.c b/tree-diff.c
index 42924e9..26bdbdd 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -305,9 +305,15 @@ static inline int diff_might_be_rename(void)
static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, const char *base, struct diff_options *opt)
{
struct diff_options diff_opts;
- const char *paths[2];
+ struct diff_queue_struct *q = &diff_queued_diff;
+ struct diff_filepair *choice;
+ const char *paths[1];
int i;
+ /* Remove the file creation entry from the diff queue, and remember it */
+ choice = q->queue[0];
+ q->nr = 0;
+
diff_setup(&diff_opts);
diff_opts.recursive = 1;
diff_opts.detect_rename = DIFF_DETECT_RENAME;
@@ -320,17 +326,21 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co
diff_tree(t1, t2, base, &diff_opts);
diffcore_std(&diff_opts);
- /* NOTE! Ignore the first diff! That was the old one! */
- for (i = 1; i < diff_queued_diff.nr; i++) {
- struct diff_filepair *p = diff_queued_diff.queue[i];
+ /* Go through the new set of filepairing, and see if we find a more interesting one */
+ for (i = 0; i < q->nr; i++) {
+ struct diff_filepair *p = q->queue[i];
/*
* Found a source? Not only do we use that for the new
- * diff_queued_diff, we also use that as the path in
+ * diff_queued_diff, we will also use that as the path in
* the future!
*/
if ((p->status == 'R' || p->status == 'C') && !strcmp(p->two->path, opt->paths[0])) {
- diff_queued_diff.queue[0] = p;
+ /* Switch the file-pairs around */
+ q->queue[i] = choice;
+ choice = p;
+
+ /* Update the path we use from now on.. */
opt->paths[0] = xstrdup(p->one->path);
diff_tree_setup_paths(opt->paths, opt);
break;
@@ -338,10 +348,19 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co
}
/*
- * Then, ignore any but the first entry! It might be the old one,
- * or it might be the rename/copy we found
+ * Then, discard all the non-relevane file pairs...
+ */
+ for (i = 0; i < q->nr; i++) {
+ struct diff_filepair *p = q->queue[i];
+ diff_free_filepair(p);
+ }
+
+ /*
+ * .. and re-instate the one we want (which might be either the
+ * original one, or the rename/copy we found)
*/
- diff_queued_diff.nr = 1;
+ q->queue[0] = choice;
+ q->nr = 1;
}
int diff_tree_sha1(const unsigned char *old, const unsigned char *new, const char *base, struct diff_options *opt)
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Linus Torvalds @ 2007-06-21 17:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pl1zsd7.fsf@assigned-by-dhcp.pobox.com>
On Thu, 21 Jun 2007, Junio C Hamano wrote:
>
> Also I am not convinced its handling of merges is sane. If you
> have an ancestry graph like this, and the commit A renames the
> followed path, it would show the file _before_ rename, which is
> very good.
>
> o-------B---A---o----o
> /
> o----C------'
I agree. That's even what I tried to explain (but your graph is better) in
my commit message, when I was talking about how it linearizes the history
in "git log" order, and decides that renames happen "within that
linearized" world.
You can actually see an *example* of this by doing
git log --stat --follow arch/i386/pci/common.c
on the old historical Linux archive (the BK import one, not the bkcvs
import - the latter has been linearized by bkcvs so won't show concurrent
development anyway).
What you get is:
[ ... ]
commit f9001d4262148fbfb7ecdcb88c73d9791c1ac0ad
Author: Greg Kroah-Hartman <greg@kroah.com>
Date: Mon May 6 20:18:16 2002 -0700
Move arch/i386/kernel/pci/ to arch/i386/pci/
arch/i386/{kernel => }/pci/common.c | 0
1 files changed, 0 insertions(+), 0 deletions(-)
commit bbb283cca10b2d2c935ae35327620ebae07f7d80
Author: Patrick Mochel <mochel@segfault.osdl.org>
Date: Mon May 6 20:09:44 2002 -0700
Move arch/i386/kernel/pci/ to arch/i386/pci/
arch/i386/kernel/pci/common.c | 206 -----------------------------------------
1 files changed, 0 insertions(+), 206 deletions(-)
[ ... ]
and this is an artifact of two _concurrent_ directory moves, and look at
what "git log --follow" did: it actually found the rename (we looked at
Greg's version first), but then *because* it found the rename, it is now
starting to look at the *previous* name, which was
arch/i386/kernel/pci/common.c
and when it then sees the rename in Pat's commit, it's no longer finding
that previous entry as a "new file that got created" (which triggers the
rename logic), but now it finds that filename has being *removed* (because
the _old_ filename really did go away - it got renamed!)
This is 100% logical within that linearized history, but it's a bit
surprising. But it's how "git log --follow" just works.
If you want to see the real history, you need to do it with "git blame",
which actually understands about merges, or with some graphical viewer
that would be extended to follow renames when it notices that a filename
goes away.
But "git log" itself really fundamentally has no clue, and you really
should see "git log" as a *linearization* thing. It linearizes the history
by creating a one-dimensional streaming log. And within that linearized
history, there can not be anything like "concurrent renames".
Linus
^ permalink raw reply
* [PATCH] filter-branch: add example to move everything into a subdirectory
From: Johannes Schindelin @ 2007-06-21 17:05 UTC (permalink / raw)
To: Jeff King, git, gitster
This is based on Jeff King's example in
20070621130137.GB4487@coredump.intra.peff.net
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-filter-branch.sh | 8 ++++++++
t/t7003-filter-branch.sh | 8 ++++++++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index ffb31d6..297e09e 100644
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -181,6 +181,14 @@
#
# git-filter-branch ... new-H C..H --not D
# git-filter-branch ... new-H D..H --not C
+#
+# To move the whole tree into a subdirectory, or remove it from there:
+#
+# git-filter-branch --index-filter \
+# 'git-ls-files -s | sed "s-\t-&newsubdir/-" |
+# GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
+# git-update-index --index-info &&
+# mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' directorymoved
# Testsuite: TODO
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 0fabe49..f00c262 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -99,4 +99,12 @@ test_expect_success 'subdirectory filter result looks okay' '
! git show sub:subdir
'
+test_expect_success 'use index-filter to move into a subdirectory' '
+ git-filter-branch --index-filter \
+ "git-ls-files -s | sed \"s-\\t-&newsubdir/-\" |
+ GIT_INDEX_FILE=\$GIT_INDEX_FILE.new \
+ git-update-index --index-info &&
+ mv \$GIT_INDEX_FILE.new \$GIT_INDEX_FILE" directorymoved &&
+ test -z "$(git diff HEAD directorymoved:newsubdir)"'
+
test_done
--
1.5.2.2.2822.g027a6-dirty
^ permalink raw reply related
* Re: Basename matching during rename/copy detection
From: Steven Grimm @ 2007-06-21 16:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthieu Moy, Andy Parkins, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0706211649520.4059@racer.site>
Johannes Schindelin wrote:
> No, that message did not convince me. It was way too short on the side of
> facts.
>
Short of posting multiple historical versions of the third-party source
code in question, I'm not sure what I can do to convince you. And I'd
rather not violate the license agreement on that code. I would have
thought, though, that the fact that I supplied a detailed, reproducible
test case with obviously broken behavior would itself have been pretty
convincing.
The fact that not all projects contain any short files, or any files
whose contents have ever been identical, does not cause git's behavior
in that test case to be correct. "It's broken and unfixable" is one
thing; "It's broken and we don't care" is another; and "It's broken and
we care but it's not at the top of anyone's priority list to fix" is
something else again. All of those are fine, but "If it's broken, you
are stupid" and "If it's broken, it's a sign your project isn't real"
are not.
Or, to take another tack on this entirely, it is not the proper function
of a version control system to dictate the contents of the projects
under its control. It should take whatever we humans throw at it and
reproduce those contents faithfully with coherent, non-jumbled history.
It should do so even if what we're throwing at it is completely stupid.
By the way, I'll toss out one more example of legitimate duplicate
files, though admittedly one where you might not care so much about
history jumbling: if you have a project that makes use of two GPL
libraries or utilities whose source you want to keep locally, e.g.
because you are making local modifications, you will have two copies of
the GNU "COPYING" file. Neither one produced by a build system (or at
least, not by *your* build system) and you are not permitted by the
terms of the GPL to publish a copy of either piece of software without a
verbatim copy of its license -- it says so right in section 1 of the GPL
(the "keep intact" wording.) Removing one of those copies and expecting
a build system to reconstruct it after someone clones your repository
would arguably be a violation of the GPL.
-Steve
^ permalink raw reply
* RE: [PATCH] git-svn: allow dcommit to retain local merge information
From: Joakim Tjernlund @ 2007-06-21 16:54 UTC (permalink / raw)
To: 'Eric Wong'; +Cc: 'Junio C Hamano', 'Steven Grimm', git
In-Reply-To: <20070620065600.GA25010@muzzle>
> -----Original Message-----
> From: Eric Wong [mailto:normalperson@yhbt.net]
> Sent: den 20 juni 2007 08:56
> To: Joakim Tjernlund
> Cc: Junio C Hamano; Steven Grimm; git@vger.kernel.org
> Subject: Re: [PATCH] git-svn: allow dcommit to retain local
> merge information
>
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > On Wed, 2007-06-13 at 02:23 -0700, Eric Wong wrote:
> > > dcommit will still rewrite the HEAD commit and the
> history of the first
> > > parents of each HEAD~1, HEAD~2, HEAD~3 as it always has.
> > >
> > > However, any merge parents (HEAD^2, HEAD^^2, HEAD~2^2) will now be
> > > preserved when the new HEAD and HEAD~[0-9]+ commits are
> rewritten to SVN
> > > with dcommit. Commits written to SVN will still not have
> any merge
> > > information besides anything in the commit message.
> > >
> > > Thanks to Joakim Tjernlund, Junio C Hamano and Steven Grimm
> > > for explanations, feedback, examples and test case.
> > >
> > > Signed-off-by: Eric Wong <normalperson@yhbt.net>
> > > ---
> > >
> > > This is a better patch that replaces the previous one.
> > >
> > > Junio:
> > > This one is a big change and should probably sit in pu or next
> > > for a bit. Double-checking the logic in linearize_history()
> > > would be greatly appreciated, too.
> > >
> > > I don't think there are any regressions for the
> > > already-linear-history case besides slightly reduced
> performance for
> > > new calls to cat-file.
> > >
> > > Joakim/Steven:
> > > Any further testing and test cases would be
> appreciated. Be very
> > > careful with real-world repositories, and run dcommit with the
> > > '-n' flag before actually committing to verify the
> diffs are sane.
> > >
> > > Thanks
> > >
> >
> > Did a little testing and so far it looks good :)
> >
> > Sidenote:
> > Doing this
> > git-svn init -t tags -T trunk -b branches
> file:///usr/local/src/tst-git-svn/svn-uboot-repo
> > git-svn fetch --quiet
> > makes git svn fetch stop for rather long periods in do_update:
> > Found possible branch point:
> file:///usr/local/src/tst-git-svn/svn-uboot-repo/trunk =>
> file:///usr/local/src/tst-git-svn/svn-uboot-repo/tags/snap-ubo
> ot-1.1.4, 2
> > Found branch parent: (tags/snap-uboot-1.1.4)
> 81eef14963597cc99ba375f52e6d0b3bc09e25f8
> > Following parent with do_update
> > Successfully followed parent
> >
> > Is it possible to speed up do_update?
>
> Use a do_switch()-enabled SVN to avoid do_update(). do_update will
> redownload everything. I have patched 1.4.3 debian packages
> with source
> and a diff here: http://git-svn.bogomips.org/svn. SVN 1.4.4 claims to
> have fixed the bindings, but 1.4.3 claimed the same thing, too...
> Confirmation of it working in SVN 1.4.4 would be nice.
Confirmed as requested, I installed 1.4.4(Gentoo) an ran the
same test case. Now I see "Following parent with do_switch"
instead and it is almost instant. It felt though that
git-svn was somewhat slower importing large diffs.
Jocke
>
> > Lastly, when adding the above u-boot svn repo into a fresh u-boot
> > clone from WD, can I attach the svn tree to git u-boot tree without
> > using a graft?
>
> Not with the current version. The 1.5.0 (or previous, I
> forget) allowed
> forced-parenting with: "git-svn fetch <rev>=<commit>" but I figured
> nobody was using it, and it would be difficult to get working since
> fetch can now works on multiple trees and the same revision
> numbers can
> appear in multiple trees.
If you reconsider this, please let me know.
Jocke
^ permalink raw reply
* Re: Strange diff behavior?
From: Jason Sewall @ 2007-06-21 16:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Raimund Bauer, git
In-Reply-To: <Pine.LNX.4.64.0706211131160.4059@racer.site>
Ok, it was my bad. There *were* whitespaces on those lines, but in
HEAD^, not head. Git only cares when they are introduced, not when
they are removed. So git diff HEAD^..HEAD showed that strange line
removal/add but git diff HEAD..HEAD^ shows me the whitespace.
I recently set up emacs to strip whitespace whenever I save a file to
prevent git from complaining (and it's good practice anyway), so that
explains why I didn't expect the change
Sorry about the mixup, and thanks for your help.
On 6/21/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 21 Jun 2007, Raimund Bauer wrote:
>
> > On Thu, 2007-06-21 at 02:13 +0100, Johannes Schindelin wrote:
> >
> > > Just a guess: core.autocrlf=true?
> >
> > My guess: apply.whitespace=strip
>
> Much better guess, I guess. Jason?
>
> Ciao,
> Dscho
>
^ permalink raw reply
* Little fix and suggestion for the git tutorial
From: Carlos Rica @ 2007-06-21 16:45 UTC (permalink / raw)
To: J. Bruce Fields, git
Sorry for not sending a patch, I was following the tutorial and found
this, in the section "Using git for collaboration":
307 With this, you can perform the first operation alone using the
308 "git fetch" command without merging them with her own branch,
309 using:
I think that "you" should be replaced with "she".
I have a suggestion also that I don't know how to fix. The text in
that section seems to say something like you need to add a "remote"
alias to be able to run fetch for retrieving without merging:
...[remote add <alias>]...
307 With this, you can perform the first operation alone using the
308 "git fetch" command without merging them with her own branch,
309 using:
....[fetch <alias>]...
315 Unlike the longhand form, when Alice fetches from Bob using a
316 remote repository shorthand set up with `git remote`, what was
317 fetched is stored in a remote tracking branch, in this case
318 `bob/master`. So after this:
I'm not sure, but I think that you could use fetch without the need of
an alias. I think that here it is trying to avoid more advanced
explanations or longer commands, however I don't know how to say it
better, perhaps mentioning that this way it is easier, without
omitting that it could be done without a "remote" alias for the repo.
That's all, thank you
^ permalink raw reply
* Re: [PATCH] diffcore-rename: favour identical basenames
From: Linus Torvalds @ 2007-06-21 16:20 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, Shawn O. Pearce, git, govindsalinas, gitster
In-Reply-To: <20070621131915.GD4487@coredump.intra.peff.net>
On Thu, 21 Jun 2007, Jeff King wrote:
> On Thu, Jun 21, 2007 at 12:52:11PM +0100, Johannes Schindelin wrote:
>
> > When there are several candidates for a rename source, and one of them
> > has an identical basename to the rename target, take that one.
>
> That's a reasonable heuristic, but it unfortunately won't match simple
> things like:
>
> i386_widget.c -> arch/i386/widget.c
We'e also had things like
arch/i386/kernel/pci-pc.c -> arch/i386/kernel/pci/common.c
so it's not always the ending of a file that is unchanged, but you still
often have some "similarity" of the name (ie the "pci" substring is still
common there).
So I agree that we can be even better about the heuristics. I don't know
how much it *matters* in practice.
I do agree with the people who argue that you simply shouldn't depend on
these kinds of things, and if you have identical files, and move them
around, you really are getting behaviour that doesn't matter.
The files are *identical* for christ sake! Following their history, it
doesn't matter *which* base you follow, since regardless, they've come to
the same point!
So in that sense, the current git behaviour is actually perfectly fine.
At the same time, I'll argue from a totally theoretical point that the
"filename" is obviously part of the data in the tree, and as such, a
similarity comparison that takes only the data into account is a bit
limited. So while I don't think a user should really care, I also think
that keeping the filename as part of the similarity analysis is actually
a perfectly logical and valid thing to do withing the git policy of
"content is king".
The filename *is* part of the content, and it's doubly so when you think
about a rename or copy operation, where the whole point of the exercise is
as much about the filename as about the data inside the file.
Linus
^ permalink raw reply
* Re: Finally implement "git log --follow"
From: Linus Torvalds @ 2007-06-21 16:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marco Costalba, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0706211654100.4059@racer.site>
On Thu, 21 Jun 2007, Johannes Schindelin wrote:
>
> The only quirk here is that "--stdin" makes no sense with a pager.
> Therefore, you'd have to move the automatic pager invocation to _after_
> option parsing.
I don't know.. The pager invocation already checks whether the output is a
tty. Quite frankly, I think that is sufficient for all cases we're
discussing right now (ie anybody who uses "--stdin" would *also* redirect
the output!), and we could certainly make it check that both the input
*and* the output is a tty.
Linus
^ permalink raw reply
* Re: [PATCH] Make list of features auto-managed.
From: Nicolas Pitre @ 2007-06-21 15:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vwsxxwtrh.fsf@assigned-by-dhcp.pobox.com>
On Thu, 21 Jun 2007, Junio C Hamano wrote:
> I am now getting sort of convinced that the list-features is a
> slippery slop towards total suckage, unless managed very
> carefully.
>
> The "auto manage" patch I am responding to would tempt anybody
> to extend the mechanism to do something like the attached patch,
> because a one-line comment near the code, like:
>
> /* FEATURE<oneline-first-paragraph> */
>
> does not look very useful nor pretty by itself in the source
> code. It makes it very tempting to actually describe the
> "feature". People with only half a brain would even advocate
> updating supported_features[] to a tuple of (name, explanation),
> and have "git version --list-features" to spit both out, or
> something like that. I really do not think we would want to go
> there.
>
> A few years down the road, do we really care if we did not do
> something long time ago, but the code was updated and added as a
> new feature? That information belongs to the commit log, not to
> in-source comments. This will lead to the same mistake often
> made by users of other SCMs, embedding "$Log$" in their sources.
Well, just in case my opinion matters...
I don't like this feature list idea at all.
Not only is it going to grow indefinitely with no possibility for
garbage collection because programs will depends on particular features
to be listed there, the simple fact that deciding if a particular
improvement should be listed is a subjective matter which will make the
list grow faster than it absolutely should.
Given that this appears to be needed by git-guy, and since git-guy is
shipped with main git already, it is a bit odd to have to support code
to work with older git versions. Why isn't git-guy simply remaining in
synch with the git version it is shipped with? This way cruft won't
accumulate forever.
And if the tool and git core really have to be decoupled, then the best
way to test for a specific feature is actually to get the git
version. No silly issues with a feature list to maintain, and no issue
with a particular feature that might not have been added to the list.
When you need git behavior X and you know that it appeared in version Y
then you only need to test for git_version >= Y. Determining that
particular Y is much easier after the facts using the commit log than
trying to anticipate what item should be added to a feature list for
future usage. In fact the same argument as for not explicitly recording
renames in commit objects should apply here.
Nicolas
^ permalink raw reply
* Re: Finally implement "git log --follow"
From: Johannes Schindelin @ 2007-06-21 15:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Marco Costalba, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0706210842340.3593@woody.linux-foundation.org>
Hi,
On Thu, 21 Jun 2007, Linus Torvalds wrote:
> On Thu, 21 Jun 2007, Marco Costalba wrote:
> >
> > Bad: Currently git-log does not support --stdin option, required IMHO
> > when git-log is runned by a tool, not a user, due to the possibility
> > of a very long command line.
>
> I do think we should just fix this. The patch to do so can't be *that*
> bad.
The only quirk here is that "--stdin" makes no sense with a pager.
Therefore, you'd have to move the automatic pager invocation to _after_
option parsing.
Ciao,
Dscho
^ permalink raw reply
* Re: Basename matching during rename/copy detection
From: Johannes Schindelin @ 2007-06-21 15:53 UTC (permalink / raw)
To: Steven Grimm; +Cc: Matthieu Moy, Andy Parkins, git, Junio C Hamano
In-Reply-To: <467A9B2C.2060907@midwinter.com>
Hi,
On Thu, 21 Jun 2007, Steven Grimm wrote:
> Johannes Schindelin wrote:
> > Yes. And Git explicitely allows what I call stupid. And yes, those
> > _identical_ files in the test suit should probably all be folded into
> > single files, and the places where they are used should reference _that_
> > single instance.
> >
>
> Two files that are identical in the current revision have not necessarily
> been identical from the beginning. Doing what you suggest will cause you to
> lose the history of all but one of those files.
>
> Files can absolutely become identical in the real world. I know that for a
> fact because it happened to me just this week (see my "Directory renames"
> message from a few days ago.)
No, that message did not convince me. It was way too short on the side of
facts.
And no, I do not think that two unrelated files can get exactly the same
content.
Be that as may, even _if_ there were such a case, I'd still try to reuse
the same file in the working directory. Just because Git can deal
efficiently with millions of identical files does not mean that a working
directory can, or worse, human developers.
Ciao,
Dscho
^ permalink raw reply
* Re: Finally implement "git log --follow"
From: Linus Torvalds @ 2007-06-21 15:44 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550706202321t354ec0e3xb218f382f1c983ae@mail.gmail.com>
On Thu, 21 Jun 2007, Marco Costalba wrote:
>
> Bad: Currently git-log does not support --stdin option, required IMHO
> when git-log is runned by a tool, not a user, due to the possibility
> of a very long command line.
I do think we should just fix this. The patch to do so can't be *that*
bad.
I'll look at it.
> FWIK "git blame -M --incremental" does not support "code lines range
> filtering", when with the mouse you select some lines of code and
> after filtering you see the subset of file's history that modified
> that range of code. This feature is currently supported by qgit
> annotating code.
Yeah, that sounds like it would be a good thing to fix.
Linus
^ permalink raw reply
* Re: Suggestions for documentation
From: Jakub Narebski @ 2007-06-21 15:16 UTC (permalink / raw)
To: git
In-Reply-To: <467A5FE1.1010401@gmail.com>
Claudio Scordino wrote:
> actually I didn't understand the difference between "git clone --bare" and
> "git --bare fetch" either... (maybe is not clear in the documentation ?)
>
> For instance, what should be used when setting up a public not-working repository ?
>
> I mean, we can use both
>
> git --bare init
> git --bare fetch ... master:master
"git --bare <command>" is equivalent to "git --git-dir=. <command>", and
it only tells where to find repository...
> and
>
> git clone --bare ...
...while "git clone --bare" setups _bare_ repository, which means
1:1 mapping of references, and no working area.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Basename matching during rename/copy detection
From: Steven Grimm @ 2007-06-21 15:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthieu Moy, Andy Parkins, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0706211451480.4059@racer.site>
Johannes Schindelin wrote:
> Yes. And Git explicitely allows what I call stupid. And yes, those
> _identical_ files in the test suit should probably all be folded into
> single files, and the places where they are used should reference _that_
> single instance.
>
Two files that are identical in the current revision have not
necessarily been identical from the beginning. Doing what you suggest
will cause you to lose the history of all but one of those files.
Files can absolutely become identical in the real world. I know that for
a fact because it happened to me just this week (see my "Directory
renames" message from a few days ago.) Are you seriously suggesting that
every time I unpack an update from a third party, I should go through it
and see if they have changed any files such that the contents now match
another file in my repository, and if so, I should remove all but one of
the copies from my repository and have a build system create it instead?
Then undo that work when I unpack another update and the files are no
longer identical?
Well, no, I know you're not suggesting that, but it's the logical
conclusion of the "it's stupid to ever have duplicate files" philosophy.
While that approach certainly makes life easier for the version control
system, it doesn't exactly make life easier for the *developer*, which
is kind of the whole point of why we're here.
-Steve
^ permalink raw reply
* Re: [PATCH] Let git-svnimport clean up SVK commit messages.
From: Jeffrey C. Ollie @ 2007-06-21 15:00 UTC (permalink / raw)
To: Dave O'Neill; +Cc: Steven Grimm, git
In-Reply-To: <20070621141415.GA21065@magnesium.roaringpenguin.com>
[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]
On Thu, 2007-06-21 at 10:14 -0400, Dave O'Neill wrote:
> On Wed, Jun 20, 2007 at 08:19:33PM -0700, Steven Grimm wrote:
>
> > Any chance of applying this to git-svn instead? There has been talk of
> > deprecating git-svnimport since git-svn now does everything
> > git-svnimport does, and more. (If you believe that's not the case,
> > please describe what you're doing with git-svnimport that you can't do
> > with git-svn.)
>
> Sure, I can probably apply it to git-svn as well, but based on the
> testing I've done, git-svnimport still works better for what I'm doing.
> I'm trying to do a straight conversion from SVN to git, so we can do
> away with our Subversion repositories, so I won't need the bidirectional
> support of git-svn.
>
> If git-svn had a --one-way option that could
> - know that I'm converting, and import my SVN tags and branches to
> local tags and heads rather than remotes
This quickie Python script should convert the "tag branches" to regular
Git tags:
import os
refs = os.popen('git-for-each-ref --format="%(objectname)%00%(refname)%00" refs/remotes/tags')
for line in refs:
[sha, ref] = line.split('\0')[:2]
os.system('git tag %s %s' % (ref[18:], sha))
> - turn off the git-svn-id: tags in the commit
git svn fetch --no-metadata
> - avoid preserving a .git/svn/ directory (a git-svn conversion was 50%
> larger than one from git-svnimport because of this)
Once you are done importing, you can delete that directory.
> - convert svn:ignore attrs to .gitignore (like the -I option of
> git-svnignore)
git svn show-ignore
> then I wouldn't need git-svnimport. Alternatively, if there's some way
> to postprocess my clone to do all of the above, that would probably be
> good enough.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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