* Re: CVS -> SVN -> Git
From: Eric S. Raymond @ 2007-07-14 19:52 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Martin Langhoff, Julian Phillips, git, dev
In-Reply-To: <4699034A.9090603@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu>:
> Martin Langhoff wrote:
> > On 7/14/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> >> Incidentally, now that cvs2svn 2.0.0 is nearly out, I am thinking about
> >> what it would take to write some other back ends for cvs2svn--turning
> >> it, essentially, into cvs2xxx. Most of the work that cvs2svn does is
> >> inferring the most plausible history of the repository from CVS's
> >> sketchy, incomplete, idiomatic, and often corrupt data. This work
> >> should also be useful for a cvs2git or cvs2hg or cvs2baz or ...
> >
> > Great to hear that. I'm game if we can do something in this direction
> > - surely we can make it talk to fastimport ;-)
>
> We added some hooks to cvs2svn 2.0 to start working in this direction.
Excuse me, I missed Michael's Haggerty's original post. But as it
happens I've been doing quite a lot of work with VCSes and migration
tools recently and I have some opinions and experience that I think are
relevant.
In slightly more detail: I just finished forward-porting sccs2rcs to
Python, I've been moving some Subversion-hosted stuff to Mercurial,
and I've been thinking about writing a simple rcs2svn because the last
time I tried using cvs2svn on a large RCS history (the Jargon File, as
it happens, a couple years back) it did a very poor job of coalescing
related commits without the CVS metadata. I'm going to hope 2.0.0 has
fixed that; I'll experiment and see.
Also, I'm in the process of rewriting Emacs VC mode and testing it
with three different VCSes. One consequence is that the Subversion
support in Emacs is going to cease sucking badly in the very near
future -- the VC-mode rewrite is giving VC mode the ability to make
atomic fileset commits if the underlying VCS will support them. I'm
putting the finishing touches on that code today, as it happens.
Another consequence is that Mercurial and git support will get really
good, oh, about ten minutes after the new Subversion backend lands.
The blocker on all three was the same weakness in the engine of VC
mode, for whicch I was (alas) responsible as its original author and
*which I have now fixed*.
So, I hear about plans to make cvs2svn generate something other than
Subversion, and here's my instant reaction:
DON'T DO IT!
This is not because I think Subversion is some kind of final answer to the
VCS problem. Fame from it -- I'm moving towards Mercurial. No, the
real reason I think this would be a waste of time is subtler than that.
Subversion, by design, is very good at capturing the metadata from
SCCS and RCS and the various CVS variants floating around. In fact,
lifting from those into Subversion is basically lossless - the real
problems are that (a) as Michael notes, the data you're losslessly
lifting is scratchy, and (b) as I've noted, you have to use heuristics
to coalesce file histories into changesets and those don't always make
the links they should.
That being the case, two-step conversion with tools that import CVS to
SVN and export from SVN to whatever actually works extremely well.
I'm speaking from direct recent experience here, not just theory. In
fact, it works so well well that I'm convinced a tool for direct
conversion from CVS to the third-generation systems would be misplaced
effort.
I'd much rather see the effort go into improving import to Subversion
from CVS and older, cruftier systems. Subversion is like the Heinlein quote
about low Earth orbit being halfway to anywhere -- once your code and
metadata are there, export to advanced alien VCSes is easy. So, Michael;
I know it's nice to think about building space probes that can go direct
to the aliens -- but please concentrate on building a better heavy-lift
vehicle, because low earth orbit is the hard part.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* [PATCH] git-svn: remove leading slashes from fetch lines in the generate config
From: Eric Wong @ 2007-07-14 19:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Bradford Smith
In-Reply-To: <f158199e0707141159t290d3aa9g90c6799e98520f56@mail.gmail.com>
We were previously sensitive to leading slashes in the fetch
lines and incorrectly writing them to the config if the user
used them (needlessly) in the command-line.
This fixes the issue and allows us to play nicely with legacy
configs that have leading slashes in fetch lines.
Thanks to Bradford Smith for figuring this out for me:
>
> This works:
>
> git-svn clone https://my.server.net/repos/path/ -Ttrunk/testing
> -ttags/testing -bbranches/testing testing
>
> This doesn't:
>
> git-svn clone https://my.server.net/repos/path -T/trunk/testing
> -t/tags/testing -b/branches/testing testing
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index b3dffcc..299b40f 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1026,7 +1026,9 @@ sub read_all_remotes {
my $r = {};
foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
if (m!^(.+)\.fetch=\s*(.*)\s*:\s*refs/remotes/(.+)\s*$!) {
- $r->{$1}->{fetch}->{$2} = $3;
+ my ($remote, $local_ref, $remote_ref) = ($1, $2, $3);
+ $local_ref =~ s{^/}{};
+ $r->{$remote}->{fetch}->{$local_ref} = $remote_ref;
} elsif (m!^(.+)\.url=\s*(.*)\s*$!) {
$r->{$1}->{url} = $2;
} elsif (m!^(.+)\.(branches|tags)=
@@ -1146,6 +1148,7 @@ sub init_remote_config {
unless ($no_write) {
command_noisy('config',
"svn-remote.$self->{repo_id}.url", $url);
+ $self->{path} =~ s{^/}{};
command_noisy('config', '--add',
"svn-remote.$self->{repo_id}.fetch",
"$self->{path}:".$self->refname);
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH 6/6] Add git-rewrite-commits
From: Junio C Hamano @ 2007-07-14 19:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: skimo, git
In-Reply-To: <Pine.LNX.4.64.0707141140510.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> +Examples
>> +--------
>> +
>> +Suppose you want to remove a file (containing confidential information
>> +or copyright violation) from all commits:
>> +
>> +----------------------------------------------------------------------------
>> +git rewrite-commits --index-filter 'git update-index --remove filename || :'
>
> We seem to prefer "$ git" instead of just "git" in the other man pages'
> examples.
"git update-index --remove Foo" does not remove the index entry
Foo if the file Foo still exists in the working tree (use "git
update-index --force-remove" for that).
But this leads to more fundamental issues. It is not obvious
from the description what environment rewrite-commits runs in.
Does it run at the toplevel of the current working tree, or is
it run in a separate temporary directory like filter-branch
does? What "index" and "HEAD" do operations done by filters
affect (I think it is safe to assume that readers familiar
enough with other parts of git would be able to guess that
filters should operate on the "HEAD" and index given by
rewrite-commits to its execution environment without mucking
with GIT_DIR nor GIT_INDEX_FILE)? Are filters allowed to modify
files in the working tree, and if so what is the consequence of
doing so?
>> +----------------------------------------------------------------------------
>> +
>> +Now, you will get the rewritten history saved in your current branch
>> +(the old branch is saved in refs/original).
>
> The "|| :" construct
> + prevents the filter to fail when the given file was not present in the
> + index.
prevents the filter from failing? But is that really what we
want? Why are we ignoring the error, and if there is a valid
reason to ignore shouldn't we explain why?
>> +To move the whole tree into a subdirectory, or remove it from there:
>> +
>> +---------------------------------------------------------------
>> +git rewrite-commits --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'
>> +---------------------------------------------------------------
I see only one operation in the example, and "or remove it from
there" confuses the reader.
I'll refrain from comments on the code right now, until I read
the series over.
^ permalink raw reply
* Fwd: git-svn: trunk missing, checks out tag instead
From: Bradford Smith @ 2007-07-14 19:04 UTC (permalink / raw)
To: git; +Cc: Eric Wong
In-Reply-To: <f158199e0707131205w358676e5j88f8e4c63b1be1f5@mail.gmail.com>
TWIMC,
(Cc: to git-svn author, Eric Wong)
I tried it again today, and it worked! Looking at the command more
closely and playing with it a bit I discovered I had written the
command line slightly differently.
This works:
git-svn clone https://my.server.net/repos/path/ -Ttrunk/testing -ttags/testing \
-bbranches/testing testing
This doesn't:
git-svn clone https://my.server.net/repos/path -T/trunk/testing
-t/tags/testing \
-b/branches/testing testing
So, clearly this command is extremely sensitive to where the slashes go.
With the "good" version of the command I get a trunk branch. With the
"bad" version I don't. Either way, I get the defunct 1.0 branch and
the error message mentioned in the original email below.
HTH,
Bradford C, Smith
---------- Forwarded message ----------
From: Bradford Smith <bradford.carl.smith@gmail.com>
Date: Jul 13, 2007 3:05 PM
Subject: Fwd: git-svn: trunk missing, checks out tag instead
To: git@vger.kernel.org
UPDATE:
I get the same behavior even after checking in a new change on the trunk.
Oh, well...
Bradford
---------- Forwarded message ----------
From: Bradford Smith <bradford.carl.smith@gmail.com>
Date: Jul 13, 2007 1:24 PM
Subject: git-svn: trunk missing, checks out tag instead
To: git@vger.kernel.org
I am using git-svn version 1.5.3.rc1.4.gaf83 (svn 1.4.3), and I work
with an SVN repository that is layed out like this:
/trunk/proj1/
...
/trunk/proj2/
...
/trunk/testing/
...
/branches/proj1/
...
/branches/proj2/
...
/branches/testing/
/branches/testing/0000-baseline
/tags/proj1/
...
/tags/proj2/
...
/tags/testing/
/tags/testing/0000-baseline-0
I want to track the testing project, so I tried to use this git-svn
command line:
git-svn clone <base-url> -T/trunk/testing -t/tags/testing
-b/branches/testing testing
This appears to work, though I do get this warning message (edited for privacy):
W: Ignoring error from SVN, path probably does not exist: (175002): RA
layer request failed: REPORT request failed on
'/<server_path>/!svn/bc/101': REPORT of '/<server_path>!svn/bc/101':
Could not read chunk size: Secure connection truncated
(https://<myserver>)
When I run 'git branch -a' in the new testing directory I get this:
* master
0000-baseline
0000-baseline@1546
1.0
1.0@1549
1.0@1656
tags/0000-baseline
tags/0000-baseline-0
tags/0000-baseline@1663
Where is the remote branch for trunk? And, why do I have remote
entries for the defunct 1.0 branch that I deleted from svn earlier
today? What's more, the latest changes from /trunk/testing do not
appear in my working directory, and gitk confirms that master is
pointing at the same commit as tags/0000-baseline-0.
If I just try to track the trunk like this:
git-svn clone <base-url>/trunk/testing
Then I get all of the latest changes and 'git branch -a' shows:
* master
git-svn
So that seems OK at least. It just doesn't work when I try to get
branches and tags. For now, I'll just work this way.
FWIW, I suspect this behavior may be related to recent changes I made
to the Subversion repository. I created
/branches/testing/0000-baseline today by copying an _old_ revision of
/trunk/testing. Then I created /tags/testing/0000-baseline-0 by
copying /branches/testing/0000-baseline. No commits have been done on
/testing/trunk since then. Perhaps the recent (probably latest)
commit that copied an OLD version of trunk is somehow confusing
git-svn? Once I commit a change to the subversion trunk, I'll try to
clone trunk, branches, and tags again and post an update to this
message. Maybe it will work then.
Thanks for your help.
Bradford C. Smith
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Junio C Hamano @ 2007-07-14 19:03 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550707140952hb60735bi95a4f03636c4aa99@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> Print message size just before the corresponding message
> to speedup the parsing by scripts/porcelains tools.
> diff --git a/log-tree.c b/log-tree.c
> index 8624d5a..2fb7761 100644
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -295,6 +295,9 @@ void show_log(struct rev_info *opt,
> if (opt->add_signoff)
> len = append_signoff(&msgbuf, &msgbuf_len, len,
> opt->add_signoff);
> + if (opt->show_size)
> + printf("size %i\n", len);
> +
> printf("%s%s%s", msgbuf, extra, sep);
> free(msgbuf);
> }
"size" is a bit vague here. What if we later want to extend
things so that you can ask for the entire log entry size
including the patch output part (I am not saying that would be
an easy change --- I am more worried about the stability of the
external interface). So is --show-"size". "message-size" would
have been a bit easier to swallow, but I sense the problem runs
deeper.
The current code spits out a log message after formatting it in
its entirety in core, so we happen to have its size upfront.
Having to say the size upfront means we close the door for
alternative implementations that stream the log formatting
processing.
This is not a problem for log messages per-se, as we
traditionally even did not show a commit log over 16kB (these
days we are supposed to be unbounded, although I do not know if
anybody actually tested that). But if we ever want to extend
this concept to cover the patch part, so that the reader can
split the "git log" output stream into individual commits with
the same "efficiency improvements" you are seeing from this
patch, that becomes a real problem, I would think.
Naturally, this reminds me of having to say Content-Length
upfront vs chunked transfer. Essentially you are treating the
output stream from "git log" into the pipe as a sequence of
messages (and without "-p", your "size" is exactly what a
"Content-Length" header is). The fact that this analogy works
only when the command is run without "-p" (but "--show-size"
does not check that) bothers me. What would we do when we want
to help the readers that reads from "-p" output?
I have a more basic question. If you are reading from non "-p"
output, where do you exactly have the wasted cycles in your
reader's processing? One immediately obvious thing is that you
would not have to repeatedly realloc your buffer to keep one
message worth of data in core, but somehow I cannot imagine that
that is the source of a huge performance boost.
One use case that this would give a huge improvement I can think
of is if you read the stream, and show only every tenth commit.
You can discard other 9 out of 10 without even looking at their
contents, and being able to read known amount of bytes and
immediately discard would certainly be much more efficient than
having to scan for NUL, only to discard. But that does not
sound as a plausible real-life scenario.
^ permalink raw reply
* bug in gitk on cygwin, v1.5.3-rc1
From: Mark Levedahl @ 2007-07-14 19:02 UTC (permalink / raw)
To: Paul Mackerras, Git Mailing List
Paul,
The previous bug I reported of gitk giving an error on Cygwin, and that
you addressed in 8c93917d23ec7ef998154a, now manifests itself
differently in that all commits are not shown. For instance, "gitk
v1.5.3-rc1" results in a display where the last shown commit is 9e026d3
(dated 205-09-26), the tag v0.99.8g is the penultimate shown, both are
shown with white circles at the tip of their respective commit lines.
12-15 previous commits are shown in the same way. The correct display of
course begins with commit e83c51 on 2005-040-7.
I have built a new tcl/tk package, using 8.4.15 sources, using POSIX +
X-Windows under Cygwin, and using this tcl/tk package I get identical
(assumed correct) results as I do on my fedora FC7 box. (Such a package
cannot be introduced into Cygwin as the Tcl/Tk package there is the one
that supports the insight debugger, and the Tcl/Tk sources are
integrated into the insight debugger source tree).
Further investigation has shown that:
1) The contents read in getcommitlines is identical (I logged from both
versions and compared the results).
2) The Posix-X windows version (and on Linux) in general reads 50,000
bytes at a time from the pipe, as would be expected from the line "
set stuff [read $fd 500000]"
3) The normal Cygwin TCL version reads 3000 - 5000 bytes at a time, not
50,000.
4) gitk, prior to commit 8c93917, would throw an error when trying to
layout the row that now shows up as the last commit.
So, my suspicion is that the layout code gets ahead of the read loop,
requiring data for a commit not yet read in, and prematurely terminates
the graph rather than waiting for more data to be read in before
attempting to continue the layout. Just a guess as I do not really
understand the pseudo-threading you have written.
Mark Levedahl
^ permalink raw reply
* Re: Restoring files from old commits
From: Junio C Hamano @ 2007-07-14 18:50 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Nikodemus Siivola, martin f krafft
In-Reply-To: <20070714143233.GC2544@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> martin f krafft, Sat, Jul 14, 2007 14:37:54 +0200:
>> also sprach Nikodemus Siivola <nikodemus@random-state.net> [2007.07.14.1409 +0200]:
>> > What is the recommended way to restore individual files
>> > (or directories) in the working tree to the content they
>> > had in a given commit?
>>
>> As per my comment on IRC, I think
>>
>> git checkout <tree-ish> <path>
>>
>> is the way.
>
> It does not work for directories, though.
Are you sure about that? I just did this in my git.git workspace:
$ mv Documentation Documentation-
$ git checkout HEAD Documentation/
$ diff -r Documentation- Documentation
^ permalink raw reply
* Re: [PATCH] git-cvsserver: detect/diagnose write failure, etc.
From: Jim Meyering @ 2007-07-14 18:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Frank Lichtenheld
In-Reply-To: <7v1wfe38xp.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> wrote:
> Jim Meyering <jim@meyering.net> writes:
>
>> Beware: in some contexts (when running as server), one must
>> not "die", but rather return an "error" indicator to the client.
>> I did that in the second hunk. However, I haven't carefully
>> audited the others, and so, some of the "die" calls I added may
>> end up killing the server, when a gentler failure is required.
>>
>> I've just looked, and can confirm that my change to req_Modified
>> (first hunk) is wrong. It should not die. Rather, it should probably
>> do something like the "print "E ... in hunk#2. Ideally, someone
>> would write a test to exercise code like this, to make sure it works.
>>
>> Jim
>
>> diff --git a/git-cvsserver.perl b/git-cvsserver.perl
>> index 5cbf27e..8d8d6f5 100755
>> --- a/git-cvsserver.perl
>> +++ b/git-cvsserver.perl
>> @@ -644,7 +644,7 @@ sub req_Modified
>> $bytesleft -= $blocksize;
>> }
>>
>> - close $fh;
>> + close $fh or die "Failed to write temporary, $filename: $!";
>
> True; dying is not appropriate here.
...
Hi Jun,
Thanks for the feedback.
Since no one else stepped forward, I've gone ahead and addressed the
problems -- though I haven't tested any of these server-side diagnostics.
I've added two new checks in req_Modified, to better diagnose an
incomplete request. Also, I converted each of the "die" stmts in
req_annotate to print "E..." + return.
Signed-off-by: Jim Meyering <jim@meyering.net>
---
git-cvsserver.perl | 50 +++++++++++++++++++++++++++++++++-----------------
1 files changed, 33 insertions(+), 17 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 10aba50..ae7d511 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -623,8 +623,12 @@ sub req_Modified
my ( $cmd, $data ) = @_;
my $mode = <STDIN>;
+ defined $mode
+ or (print "E end of file reading mode for $data\n"), return;
chomp $mode;
my $size = <STDIN>;
+ defined $size
+ or (print "E end of file reading size of $data\n"), return;
chomp $size;
# Grab config information
@@ -644,7 +648,8 @@ sub req_Modified
$bytesleft -= $blocksize;
}
- close $fh;
+ close $fh
+ or (print "E failed to write temporary, $filename: $!\n"), return;
# Ensure we have something sensible for the file mode
if ( $mode =~ /u=(\w+)/ )
@@ -901,8 +906,13 @@ sub req_update
# projects (heads in this case) to checkout.
#
if ($state->{module} eq '') {
+ my $heads_dir = $state->{CVSROOT} . '/refs/heads';
+ if (!opendir HEADS, $heads_dir) {
+ print "E [server aborted]: Failed to open directory, "
+ . "$heads_dir: $!\nerror\n";
+ return 0;
+ }
print "E cvs update: Updating .\n";
- opendir HEADS, $state->{CVSROOT} . '/refs/heads';
while (my $head = readdir(HEADS)) {
if (-f $state->{CVSROOT} . '/refs/heads/' . $head) {
print "E cvs update: New directory `$head'\n";
@@ -1737,14 +1747,16 @@ sub req_annotate
system("git-read-tree", $lastseenin);
unless ($? == 0)
{
- die "Error running git-read-tree $lastseenin $file_index $!";
+ print "E error running git-read-tree $lastseenin $file_index $!\n";
+ return;
}
$log->info("Created index '$file_index' with commit $lastseenin - exit status $?");
# do a checkout of the file
system('git-checkout-index', '-f', '-u', $filename);
unless ($? == 0) {
- die "Error running git-checkout-index -f -u $filename : $!";
+ print "E error running git-checkout-index -f -u $filename : $!\n";
+ return;
}
$log->info("Annotate $filename");
@@ -1754,7 +1766,11 @@ sub req_annotate
# git-jsannotate telling us about commits we are hiding
# from the client.
- open(ANNOTATEHINTS, ">$tmpdir/.annotate_hints") or die "Error opening > $tmpdir/.annotate_hints $!";
+ my $a_hints = "$tmpdir/.annotate_hints";
+ if (!open(ANNOTATEHINTS, '>', $a_hints)) {
+ print "E failed to open '$a_hints' for writing: $!\n";
+ return;
+ }
for (my $i=0; $i < @$revisions; $i++)
{
print ANNOTATEHINTS $revisions->[$i][2];
@@ -1765,11 +1781,14 @@ sub req_annotate
}
print ANNOTATEHINTS "\n";
- close ANNOTATEHINTS;
+ close ANNOTATEHINTS
+ or (print "E failed to write $a_hints: $!\n"), return;
- my $annotatecmd = 'git-annotate';
- open(ANNOTATE, "-|", $annotatecmd, '-l', '-S', "$tmpdir/.annotate_hints", $filename)
- or die "Error invoking $annotatecmd -l -S $tmpdir/.annotate_hints $filename : $!";
+ my @cmd = (qw(git-annotate -l -S), $a_hints, $filename);
+ if (!open(ANNOTATE, "-|", @cmd)) {
+ print "E error invoking ". join(' ',@cmd) .": $!\n";
+ return;
+ }
my $metadata = {};
print "E Annotations for $filename\n";
print "E ***************\n";
@@ -1996,12 +2015,12 @@ sub transmitfile
{
open NEWFILE, ">", $targetfile or die("Couldn't open '$targetfile' for writing : $!");
print NEWFILE $_ while ( <$fh> );
- close NEWFILE;
+ close NEWFILE or die("Failed to write '$targetfile': $!");
} else {
print "$size\n";
print while ( <$fh> );
}
- close $fh or die ("Couldn't close filehandle for transmitfile()");
+ close $fh or die ("Couldn't close filehandle for transmitfile(): $!");
} else {
die("Couldn't execute git-cat-file");
}
@@ -2501,17 +2520,14 @@ sub update
if ($parent eq $lastpicked) {
next;
}
- open my $p, 'git-merge-base '. $lastpicked . ' '
- . $parent . '|';
- my @output = (<$p>);
- close $p;
- my $base = join('', @output);
+ my $base = safe_pipe_capture('git-merge-base',
+ $lastpicked, $parent);
chomp $base;
if ($base) {
my @merged;
# print "want to log between $base $parent \n";
open(GITLOG, '-|', 'git-log', "$base..$parent")
- or die "Cannot call git-log: $!";
+ or die "Cannot call git-log: $!";
my $mergedhash;
while (<GITLOG>) {
chomp;
--
1.5.3.rc1.5.g9d947
^ permalink raw reply related
* Re: Draft release notes for v1.5.3, as of -rc1
From: Junio C Hamano @ 2007-07-14 18:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: skimo, git
In-Reply-To: <Pine.LNX.4.64.0707141517450.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> It is really unfortunate that rewrite-commits came in so late in the
> release cycle, and I am quite sure it should not be in 1.5.3. There is
> just too much new in it, and too many things to flesh out.
>
> Junio, if you want to include it in 1.5.3, it should be marked as alpha
> code, as it has not seen any time in "next", let alone "master".
I am not considering rewrite-commits for inclusion right now.
I was hoping that filter-branch will stay. Its interface is
something people are already familiar with since the days of its
its older incarnation cg-admin-rewritehist, and it would be
really really nice that anything that attempts to replace it
builds on and extends its external interface.
Maybe rewrite-commits can be used to delegate the implementation
of heavy lifting from filter-branch? IOW can the latter be
just a thin wrapper around the former?
^ permalink raw reply
* Re: CVS -> SVN -> Git
From: Steffen Prohaska @ 2007-07-14 18:14 UTC (permalink / raw)
To: Michael Haggerty, Shawn Pearce, Simon Hausmann
Cc: Martin Langhoff, Julian Phillips, Git Mailing List, dev
In-Reply-To: <4699034A.9090603@alum.mit.edu>
On Jul 14, 2007, at 7:09 PM, Michael Haggerty wrote:
> Martin Langhoff wrote:
>> On 7/14/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>>> Incidentally, now that cvs2svn 2.0.0 is nearly out, I am thinking
>>> about
>>> what it would take to write some other back ends for cvs2svn--
>>> turning
>>> it, essentially, into cvs2xxx. Most of the work that cvs2svn
>>> does is
>>> inferring the most plausible history of the repository from CVS's
>>> sketchy, incomplete, idiomatic, and often corrupt data. This work
>>> should also be useful for a cvs2git or cvs2hg or cvs2baz or ...
>>
>> Great to hear that. I'm game if we can do something in this direction
>> - surely we can make it talk to fastimport ;-)
>
> We added some hooks to cvs2svn 2.0 to start working in this direction.
> But I don't really know what information is needed for a git import.
> One quick-and-dirty idea that I had was to have cvs2svn output
> information compatible with cvsps's output, as I believe that several
> tools rely on cvsps to do the dirty work and so could perhaps be
> persuaded to use cvs2svn out of the box.
From my understanding, piping data to git fast-import would be
a sane gateway to git. The input format of fast-import is document
in [1].
Maybe Shaw Pearce has some comments on that. Shawn did most
(maybe all) of the work on git-fast-import.
Simon Hausmann wrote a p4 importer that uses fast-import as
its backend. Maybe, Simon can give hints how to get started.
I have no experience with neither git-fast-import nor the p4
importer but would be happy to test any improved way of importing
cvs to git. I experienced problems using git-cvsimport on a rather
large cvs repository. Hence it would be a real test of the superior
capabilities of cvs2svn.
Steffen
[1] http://www.kernel.org/pub/software/scm/git/docs/git-fast-import.html
^ permalink raw reply
* Confusing language in man page
From: Satyam Sharma @ 2007-07-14 18:08 UTC (permalink / raw)
To: git
Hi,
[ I'm using Fedora's latest package. ]
>From git-checkout(1) and git-branch(1):
-l Create the new branch's ref log. This activates recording of
all changes to made the
branch ref, enabling use of date
I'd be glad if someone could explain that a bit more verbosely in the man page
(or just here in a reply), or at least make that grammatically
correct/readable :-)
Thanks,
Satyam
^ permalink raw reply
* Re: CVS -> SVN -> Git
From: Chris Shoemaker @ 2007-07-14 17:32 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Martin Langhoff, Julian Phillips, git, dev
In-Reply-To: <4699034A.9090603@alum.mit.edu>
On Sat, Jul 14, 2007 at 07:09:30PM +0200, Michael Haggerty wrote:
> Martin Langhoff wrote:
> > On 7/14/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> >> Incidentally, now that cvs2svn 2.0.0 is nearly out, I am thinking about
> >> what it would take to write some other back ends for cvs2svn--turning
> >> it, essentially, into cvs2xxx. Most of the work that cvs2svn does is
> >> inferring the most plausible history of the repository from CVS's
> >> sketchy, incomplete, idiomatic, and often corrupt data. This work
> >> should also be useful for a cvs2git or cvs2hg or cvs2baz or ...
> >
> > Great to hear that. I'm game if we can do something in this direction
> > - surely we can make it talk to fastimport ;-)
>
> We added some hooks to cvs2svn 2.0 to start working in this direction.
> But I don't really know what information is needed for a git import.
> One quick-and-dirty idea that I had was to have cvs2svn output
> information compatible with cvsps's output, as I believe that several
> tools rely on cvsps to do the dirty work and so could perhaps be
> persuaded to use cvs2svn out of the box.
Depending on how difficult that is, it might be very useful, even
if it's not the best way to interface with fast-import (which I
suspect it's not). I, for one, would be interested to know how
cvs2svn's output compared to CVSps's, especially w.r.t. detecting each
branch's parent.
Perhaps one is always more correct than the other, but if not, I bet
that seeing the differences using the same format would help to
improve either one.
-chris
^ permalink raw reply
* [PATCH v2] Use $(RM) in makefiles instead of 'rm -f'
From: Emil Medve @ 2007-07-14 17:51 UTC (permalink / raw)
To: git; +Cc: Emil Medve
Use $(RM) in makefiles instead of 'rm -f'
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
---
Documentation/Makefile | 16 ++++++-----
Makefile | 68 ++++++++++++++++++++++++------------------------
contrib/emacs/Makefile | 3 +-
git-gui/Makefile | 16 ++++++-----
t/Makefile | 3 +-
templates/Makefile | 3 +-
6 files changed, 58 insertions(+), 51 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index f3a6c73..3ddc9ca 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -43,6 +43,8 @@ endif
INSTALL?=install
DOC_REF = origin/man
+RM ?= rm -f
+
-include ../config.mak.autogen
-include ../config.mak
@@ -84,7 +86,7 @@ install: man
# Determine "include::" file references in asciidoc files.
#
doc.dep : $(wildcard *.txt) build-docdep.perl
- rm -f $@+ $@
+ $(RM) $@+ $@
perl ./build-docdep.perl >$@+
mv $@+ $@
@@ -109,11 +111,11 @@ cmd-list.made: cmd-list.perl $(MAN1_TXT)
git.7 git.html: git.txt core-intro.txt
clean:
- rm -f *.xml *.xml+ *.html *.html+ *.1 *.5 *.7 howto-index.txt howto/*.html doc.dep
- rm -f $(cmds_txt) *.made
+ $(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7 howto-index.txt howto/*.html doc.dep
+ $(RM) $(cmds_txt) *.made
%.html : %.txt
- rm -f $@+ $@
+ $(RM) $@+ $@
$(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $<
mv $@+ $@
@@ -122,7 +124,7 @@ clean:
xmlto -m callouts.xsl man $<
%.xml : %.txt
- rm -f $@+ $@
+ $(RM) $@+ $@
$(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $<
mv $@+ $@
@@ -137,7 +139,7 @@ user-manual.html: user-manual.xml
xsltproc $(XSLTOPTS) -o $@ $(XSLT) $<
howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
- rm -f $@+ $@
+ $(RM) $@+ $@
sh ./howto-index.sh $(wildcard howto/*.txt) >$@+
mv $@+ $@
@@ -147,7 +149,7 @@ $(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
WEBDOC_DEST = /pub/software/scm/git/docs
$(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
- rm -f $@+ $@
+ $(RM) $@+ $@
sed -e '1,/^$$/d' $< | $(ASCIIDOC) -b xhtml11 - >$@+
mv $@+ $@
diff --git a/Makefile b/Makefile
index d7541b4..5f8d177 100644
--- a/Makefile
+++ b/Makefile
@@ -188,7 +188,7 @@ export TCL_PATH TCLTK_PATH
# explicitly what architecture to check for. Fix this up for yours..
SPARSE_FLAGS = -D__BIG_ENDIAN__ -D__powerpc__
-
+RM ?= rm -f
### --- END CONFIGURATION SECTION ---
@@ -729,7 +729,7 @@ export TAR INSTALL DESTDIR SHELL_PATH
all:: $(ALL_PROGRAMS) $(BUILT_INS) $(OTHER_PROGRAMS)
ifneq (,$X)
- $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), rm -f '$p';)
+ $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$p';)
endif
all::
@@ -743,7 +743,7 @@ strip: $(PROGRAMS) git$X
$(STRIP) $(STRIP_OPTS) $(PROGRAMS) git$X
gitk-wish: gitk GIT-GUI-VARS
- $(QUIET_GEN)rm -f $@ $@+ && \
+ $(QUIET_GEN)$(RM) $@ $@+ && \
sed -e '1,3s|^exec .* "$$0"|exec $(subst |,'\|',$(TCLTK_PATH_SQ)) "$$0"|' <gitk >$@+ && \
chmod +x $@+ && \
mv -f $@+ $@
@@ -759,10 +759,10 @@ git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
help.o: common-cmds.h
git-merge-subtree$X: git-merge-recursive$X
- $(QUIET_BUILT_IN)rm -f $@ && ln git-merge-recursive$X $@
+ $(QUIET_BUILT_IN)$(RM) $@ && ln git-merge-recursive$X $@
$(BUILT_INS): git$X
- $(QUIET_BUILT_IN)rm -f $@ && ln git$X $@
+ $(QUIET_BUILT_IN)$(RM) $@ && ln git$X $@
common-cmds.h: ./generate-cmdlist.sh
@@ -770,7 +770,7 @@ common-cmds.h: $(wildcard Documentation/git-*.txt)
$(QUIET_GEN)./generate-cmdlist.sh > $@+ && mv $@+ $@
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
- $(QUIET_GEN)rm -f $@ $@+ && \
+ $(QUIET_GEN)$(RM) $@ $@+ && \
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's|@@PERL@@|$(PERL_PATH_SQ)|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
@@ -782,7 +782,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/perl.mak
$(patsubst %.py,%,$(SCRIPT_PYTHON)) : % : %.py
- rm -f $@ $@+
+ $(RM) $@ $@+
sed -e '1s|#!.*/python|#!$(PYTHON_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
@@ -794,7 +794,7 @@ perl/perl.mak: GIT-CFLAGS
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' $(@F)
$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
- $(QUIET_GEN)rm -f $@ $@+ && \
+ $(QUIET_GEN)$(RM) $@ $@+ && \
INSTLIBDIR=`$(MAKE) -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!$(PERL_PATH_SQ)|' \
@@ -813,7 +813,7 @@ git-status: git-commit
$(QUIET_GEN)cp $< $@+ && mv $@+ $@
gitweb/gitweb.cgi: gitweb/gitweb.perl
- $(QUIET_GEN)rm -f $@ $@+ && \
+ $(QUIET_GEN)$(RM) $@ $@+ && \
sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
-e 's|++GIT_VERSION++|$(GIT_VERSION)|g' \
-e 's|++GIT_BINDIR++|$(bindir)|g' \
@@ -836,7 +836,7 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
mv $@+ $@
git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
- $(QUIET_GEN)rm -f $@ $@+ && \
+ $(QUIET_GEN)$(RM) $@ $@+ && \
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
@@ -849,11 +849,11 @@ git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
mv $@+ $@
configure: configure.ac
- $(QUIET_GEN)rm -f $@ $<+ && \
+ $(QUIET_GEN)$(RM) $@ $<+ && \
sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
$< > $<+ && \
autoconf -o $@ $<+ && \
- rm -f $<+
+ $(RM) $<+
# These can record GIT_VERSION
git.o git.spec \
@@ -908,7 +908,7 @@ $(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H) $(wildcard */*.h)
$(DIFF_OBJS): diffcore.h
$(LIB_FILE): $(LIB_OBJS)
- $(QUIET_AR)rm -f $@ && $(AR) rcs $@ $(LIB_OBJS)
+ $(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(LIB_OBJS)
XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o \
xdiff/xmerge.o
@@ -916,7 +916,7 @@ $(XDIFF_OBJS): xdiff/xinclude.h xdiff/xmacros.h xdiff/xdiff.h xdiff/xtypes.h \
xdiff/xutils.h xdiff/xprepare.h xdiff/xdiffi.h xdiff/xemit.h
$(XDIFF_LIB): $(XDIFF_OBJS)
- $(QUIET_AR)rm -f $@ && $(AR) rcs $@ $(XDIFF_OBJS)
+ $(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(XDIFF_OBJS)
perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS
@@ -927,11 +927,11 @@ doc:
$(MAKE) -C Documentation all
TAGS:
- rm -f TAGS
+ $(RM) TAGS
find . -name '*.[hcS]' -print | xargs etags -a
tags:
- rm -f tags
+ $(RM) tags
find . -name '*.[hcS]' -print | xargs ctags -a
### Detect prefix changes
@@ -1010,9 +1010,9 @@ endif
cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
fi
- $(foreach p,$(BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
+ $(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
ifneq (,$X)
- $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
+ $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
endif
install-doc:
@@ -1042,7 +1042,7 @@ dist: git.spec git-archive configure
$(GIT_TARNAME)/configure \
$(GIT_TARNAME)/version \
$(GIT_TARNAME)/git-gui/version
- @rm -rf $(GIT_TARNAME)
+ @$(RM) -r $(GIT_TARNAME)
gzip -f -9 $(GIT_TARNAME).tar
rpm: dist
@@ -1051,13 +1051,13 @@ rpm: dist
htmldocs = git-htmldocs-$(GIT_VERSION)
manpages = git-manpages-$(GIT_VERSION)
dist-doc:
- rm -fr .doc-tmp-dir
+ $(RM) -r .doc-tmp-dir
mkdir .doc-tmp-dir
$(MAKE) -C Documentation WEBDOC_DEST=../.doc-tmp-dir install-webdoc
cd .doc-tmp-dir && $(TAR) cf ../$(htmldocs).tar .
gzip -n -9 -f $(htmldocs).tar
:
- rm -fr .doc-tmp-dir
+ $(RM) -r .doc-tmp-dir
mkdir -p .doc-tmp-dir/man1 .doc-tmp-dir/man5 .doc-tmp-dir/man7
$(MAKE) -C Documentation DESTDIR=./ \
man1dir=../.doc-tmp-dir/man1 \
@@ -1066,31 +1066,31 @@ dist-doc:
install
cd .doc-tmp-dir && $(TAR) cf ../$(manpages).tar .
gzip -n -9 -f $(manpages).tar
- rm -fr .doc-tmp-dir
+ $(RM) -r .doc-tmp-dir
### Cleaning rules
clean:
- rm -f *.o mozilla-sha1/*.o arm/*.o ppc/*.o compat/*.o xdiff/*.o \
+ $(RM) *.o mozilla-sha1/*.o arm/*.o ppc/*.o compat/*.o xdiff/*.o \
$(LIB_FILE) $(XDIFF_LIB)
- rm -f $(ALL_PROGRAMS) $(BUILT_INS) git$X
- rm -f $(TEST_PROGRAMS)
- rm -f *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags
- rm -rf autom4te.cache
- rm -f configure config.log config.mak.autogen config.mak.append config.status config.cache
- rm -rf $(GIT_TARNAME) .doc-tmp-dir
- rm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
- rm -f $(htmldocs).tar.gz $(manpages).tar.gz
- rm -f gitweb/gitweb.cgi
+ $(RM) $(ALL_PROGRAMS) $(BUILT_INS) git$X
+ $(RM) $(TEST_PROGRAMS)
+ $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags
+ $(RM) -r autom4te.cache
+ $(RM) configure config.log config.mak.autogen config.mak.append config.status config.cache
+ $(RM) -r $(GIT_TARNAME) .doc-tmp-dir
+ $(RM) $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
+ $(RM) $(htmldocs).tar.gz $(manpages).tar.gz
+ $(RM) gitweb/gitweb.cgi
$(MAKE) -C Documentation/ clean
$(MAKE) -C perl clean
$(MAKE) -C templates/ clean
$(MAKE) -C t/ clean
ifndef NO_TCLTK
- rm -f gitk-wish
+ $(RM) gitk-wish
$(MAKE) -C git-gui clean
endif
- rm -f GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS
+ $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS
.PHONY: all install clean strip
.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags .FORCE-GIT-CFLAGS
diff --git a/contrib/emacs/Makefile b/contrib/emacs/Makefile
index 98aa0aa..5e94d6f 100644
--- a/contrib/emacs/Makefile
+++ b/contrib/emacs/Makefile
@@ -7,6 +7,7 @@ INSTALL ?= install
INSTALL_ELC = $(INSTALL) -m 644
prefix ?= $(HOME)
emacsdir = $(prefix)/share/emacs/site-lisp
+RM ?= rm -f
all: $(ELC)
@@ -17,4 +18,4 @@ install: all
%.elc: %.el
$(EMACS) -batch -f batch-byte-compile $<
-clean:; rm -f $(ELC)
+clean:; $(RM) $(ELC)
diff --git a/git-gui/Makefile b/git-gui/Makefile
index 1bac6fe..e98df9d 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -31,13 +31,15 @@ ifndef INSTALL
INSTALL = install
endif
+RM ?= rm -f
+
INSTALL_D0 = $(INSTALL) -d -m755 # space is required here
INSTALL_D1 =
INSTALL_R0 = $(INSTALL) -m644 # space is required here
INSTALL_R1 =
INSTALL_X0 = $(INSTALL) -m755 # space is required here
INSTALL_X1 =
-INSTALL_L0 = rm -f # space is required here
+INSTALL_L0 = $(RM) # space is required here
INSTALL_L1 = && ln # space is required here
INSTALL_L2 =
INSTALL_L3 =
@@ -59,7 +61,7 @@ ifndef V
INSTALL_L0 = dst=
INSTALL_L1 = && src=
INSTALL_L2 = && dst=
- INSTALL_L3 = && echo ' ' 'LINK ' `basename "$$dst"` '->' `basename "$$src"` && rm -f "$$dst" && ln "$$src" "$$dst"
+ INSTALL_L3 = && echo ' ' 'LINK ' `basename "$$dst"` '->' `basename "$$src"` && $(RM) "$$dst" && ln "$$src" "$$dst"
endif
TCL_PATH ?= tclsh
@@ -83,7 +85,7 @@ exedir = $(dir $(gitexecdir))share/git-gui/lib
exedir_SQ = $(subst ','\'',$(exedir))
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
- $(QUIET_GEN)rm -f $@ $@+ && \
+ $(QUIET_GEN)$(RM) $@ $@+ && \
GITGUI_RELATIVE= && \
if test '$(exedir_SQ)' = '$(libdir_SQ)'; then \
if test "$(uname_O)" = Cygwin; \
@@ -101,7 +103,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
mv $@+ $@
$(GITGUI_BUILT_INS): git-gui
- $(QUIET_BUILT_IN)rm -f $@ && ln git-gui $@
+ $(QUIET_BUILT_IN)$(RM) $@ && ln git-gui $@
lib/tclIndex: $(ALL_LIBFILES)
$(QUIET_INDEX)if echo \
@@ -110,7 +112,7 @@ lib/tclIndex: $(ALL_LIBFILES)
| $(TCL_PATH) $(QUIET_2DEVNULL); then : ok; \
else \
echo 1>&2 " * $(TCL_PATH) failed; using unoptimized loading"; \
- rm -f $@ ; \
+ $(RM) $@ ; \
echo '# Autogenerated by git-gui Makefile' >$@ && \
echo >>$@ && \
$(foreach p,$(PRELOAD_FILES) $(ALL_LIBFILES),echo '$(subst lib/,,$p)' >>$@ &&) \
@@ -151,8 +153,8 @@ dist-version:
@echo $(GITGUI_VERSION) > $(TARDIR)/version
clean::
- rm -f $(ALL_PROGRAMS) lib/tclIndex
- rm -f GIT-VERSION-FILE GIT-GUI-VARS
+ $(RM) $(ALL_PROGRAMS) lib/tclIndex
+ $(RM) GIT-VERSION-FILE GIT-GUI-VARS
.PHONY: all install dist-version clean
.PHONY: .FORCE-GIT-VERSION-FILE
diff --git a/t/Makefile b/t/Makefile
index b25caca..72d7884 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -6,6 +6,7 @@
#GIT_TEST_OPTS=--verbose --debug
SHELL_PATH ?= $(SHELL)
TAR ?= $(TAR)
+RM ?= rm -f
# Shell quote;
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
@@ -19,7 +20,7 @@ $(T):
@echo "*** $@ ***"; GIT_CONFIG=.git/config '$(SHELL_PATH_SQ)' $@ $(GIT_TEST_OPTS)
clean:
- rm -fr trash
+ $(RM) -r trash
# we can test NO_OPTIMIZE_COMMITS independently of LC_ALL
full-svn-test:
diff --git a/templates/Makefile b/templates/Makefile
index aaa39d3..6273ae2 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -8,6 +8,7 @@ INSTALL ?= install
TAR ?= tar
prefix ?= $(HOME)
template_dir ?= $(prefix)/share/git-core/templates
+RM ?= rm -f
# DESTDIR=
# Shell quote (do not use $(call) to accommodate ancient setups);
@@ -42,7 +43,7 @@ custom:
$(QUIET): no custom templates yet
clean:
- rm -rf blt boilerplates.made
+ $(RM) -r blt boilerplates.made
install: all
$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(template_dir_SQ)'
--
1.5.2.2.277.g4d9b5
^ permalink raw reply related
* Re: CVS -> SVN -> Git
From: Michael Haggerty @ 2007-07-14 17:09 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Julian Phillips, git, dev
In-Reply-To: <46a038f90707132230n120e6392uaf5cd86ff10b6012@mail.gmail.com>
Martin Langhoff wrote:
> On 7/14/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> Incidentally, now that cvs2svn 2.0.0 is nearly out, I am thinking about
>> what it would take to write some other back ends for cvs2svn--turning
>> it, essentially, into cvs2xxx. Most of the work that cvs2svn does is
>> inferring the most plausible history of the repository from CVS's
>> sketchy, incomplete, idiomatic, and often corrupt data. This work
>> should also be useful for a cvs2git or cvs2hg or cvs2baz or ...
>
> Great to hear that. I'm game if we can do something in this direction
> - surely we can make it talk to fastimport ;-)
We added some hooks to cvs2svn 2.0 to start working in this direction.
But I don't really know what information is needed for a git import.
One quick-and-dirty idea that I had was to have cvs2svn output
information compatible with cvsps's output, as I believe that several
tools rely on cvsps to do the dirty work and so could perhaps be
persuaded to use cvs2svn out of the box.
> Does cvs2svn handle incremental imports, remembering any "guesses"
> taken earlier? Last time I looked at it, it had far better logic than
> cvsps, but it didn't do incremental imports, and repeated imports done
> at different times would "guess" different branching points for new
> branches, so it _really_ didn't support incrementals
That's correct; cvs2svn does not support incremental conversion at all
(at least not yet).
Michael
^ permalink raw reply
* [PATCH] Add --show-size to git log to print message size
From: Marco Costalba @ 2007-07-14 16:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Print message size just before the corresponding message
to speedup the parsing by scripts/porcelains tools.
Because git log output is normally read incrementally by
porcelain tools, if message size is ignored then an
expensive seek of the delimiting char, as example '\0'
must be done when parsing the output stream.
With this patch it is possible to avoid an otherwise
mandatory seek for '\0' starting from the beginning
of log body.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
This little patch makes great difference in loading
performance of our loved ;-) tool....and probably
also others.
Please apply.
Thanks
Marco
log-tree.c | 3 +++
revision.c | 4 ++++
revision.h | 1 +
3 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 8624d5a..2fb7761 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -295,6 +295,9 @@ void show_log(struct rev_info *opt,
if (opt->add_signoff)
len = append_signoff(&msgbuf, &msgbuf_len, len,
opt->add_signoff);
+ if (opt->show_size)
+ printf("size %i\n", len);
+
printf("%s%s%s", msgbuf, extra, sep);
free(msgbuf);
}
diff --git a/revision.c b/revision.c
index 33ee9ee..3850a1e 100644
--- a/revision.c
+++ b/revision.c
@@ -1136,6 +1136,10 @@ int setup_revisions(int argc,
continue;
}
+ if (!strcmp(arg, "--show-size")) {
+ revs->show_size = 1;
+ continue;
+ }
/*
* Grepping the commit log
diff --git a/revision.h b/revision.h
index f46b4d5..584b3f1 100644
--- a/revision.h
+++ b/revision.h
@@ -81,6 +81,7 @@ struct rev_info {
const char *log_reencode;
const char *subject_prefix;
int no_inline;
+ int show_size;
/* Filter by commit log message */
struct grep_opt *grep_filter;
--
1.5.3.rc0.81.g1ed84-dirty
^ permalink raw reply related
* Re: [PATCH] fall back to mozilla's sha.h if openssl/sha.h is not available
From: Alex Riesen @ 2007-07-14 15:12 UTC (permalink / raw)
To: git
In-Reply-To: <20070714145013.GA14488@piper.oerlikon.madduck.net>
martin f krafft, Sat, Jul 14, 2007 16:50:13 +0200:
> also sprach Alex Riesen <raa.lkml@gmail.com> [2007.07.14.1623 +0200]:
> > > This should possibly go to configure.ac, but maybe *also* to Makefile to make
> >
> > Definitely. It should it least skip the test if NO_OPENSSL is already
> > defined.
>
> Reading this as a yes, here is the patch adding this. ...
I was not clear. Read it as NO.
> My autotools knowledge is limited, but I might then look at adding
> the fall back to configure.ac too.
Some (me, for one) will consider it the only place where it should be
> Btw: I've done a lot of things wrong on this mailing list already,
> for which I'd like to apologise. Thanks to those who told me
> privately off my faux pas. I hope those won't be necessary anymore.
If I were you, I would have considered CPPFLAGS and CFLAGS and added a
check if HAS_OPENSSL already set.
And BTW doesn't it strike you as a little bit odd that noone has done
that in Makefile before you? Could that be because configure is
considered the _right_ place for this kind of stuff?
^ permalink raw reply
* Re: [PATCH] fall back to mozilla's sha.h if openssl/sha.h is not available
From: martin f krafft @ 2007-07-14 14:50 UTC (permalink / raw)
To: git
In-Reply-To: <20070714142350.GB2544@steel.home>
[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]
also sprach Alex Riesen <raa.lkml@gmail.com> [2007.07.14.1623 +0200]:
> > This should possibly go to configure.ac, but maybe *also* to Makefile to make
>
> Definitely. It should it least skip the test if NO_OPENSSL is already
> defined.
Reading this as a yes, here is the patch adding this. I'll wait for
a few days before submitting a squashed patch to Junio then. If you
oppose, please speak up.
My autotools knowledge is limited, but I might then look at adding
the fall back to configure.ac too.
Btw: I've done a lot of things wrong on this mailing list already,
for which I'd like to apologise. Thanks to those who told me
privately off my faux pas. I hope those won't be necessary anymore.
commit c8cbe9e5a44174baabe17152d575b3ee46b82c36
Author: martin f. krafft <madduck@madduck.net>
Date: Sat Jul 14 16:44:46 2007 +0200
skip the openssl/sha.h test if NO_OPENSSL is already defined
diff --git a/Makefile b/Makefile
index 1676343..b0ce7f0 100644
--- a/Makefile
+++ b/Makefile
@@ -532,10 +532,12 @@ ifndef NO_CURL
endif
endif
-HAS_OPENSSL := $(shell echo "\#include <openssl/sha.h>" \
- | $(CPP) -o/dev/null - 2>/dev/null || echo no)
-ifeq "$(HAS_OPENSSL)" "no"
- NO_OPENSSL = "openssl_sha.h_not_found"
+ifndef NO_OPENSSL
+ HAS_OPENSSL := $(shell echo "\#include <openssl/sha.h>" \
+ | $(CPP) -o/dev/null - 2>/dev/null || echo no)
+ ifeq "$(HAS_OPENSSL)" "no"
+ NO_OPENSSL = "openssl_sha.h_not_found"
+ endif
endif
ifndef NO_OPENSSL
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"one should never do anything that
one cannot talk about after dinner."
-- oscar wilde
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: Restoring files from old commits
From: Alex Riesen @ 2007-07-14 14:32 UTC (permalink / raw)
To: git; +Cc: Nikodemus Siivola, martin f krafft
In-Reply-To: <20070714123754.GA29622@piper.oerlikon.madduck.net>
martin f krafft, Sat, Jul 14, 2007 14:37:54 +0200:
> also sprach Nikodemus Siivola <nikodemus@random-state.net> [2007.07.14.1409 +0200]:
> > What is the recommended way to restore individual files
> > (or directories) in the working tree to the content they
> > had in a given commit?
>
> As per my comment on IRC, I think
>
> git checkout <tree-ish> <path>
>
> is the way.
It does not work for directories, though. On can use
$ git ls-tree -r -z <tree-ish> -- <path> | git update-index -z --index-info
$ git ls-tree -r --name-only -z <tree-ish> -- <path> | git checkout-index -f -z --stdin
for a more generic way to do this.
P.S. Martin, would you please stop removing people from address lists
and stop using that Mail-Followup-To? People miss their mails when
they are not addressed to them anymore and you doing exactly that.
^ permalink raw reply
* Re: [PATCH] fall back to mozilla's sha.h if openssl/sha.h is not available
From: Alex Riesen @ 2007-07-14 14:23 UTC (permalink / raw)
To: martin f. krafft; +Cc: git
In-Reply-To: <11844050771857-git-send-email-madduck@madduck.net>
martin f. krafft, Sat, Jul 14, 2007 11:24:37 +0200:
> This should possibly go to configure.ac, but maybe *also* to Makefile to make
Definitely. It should it least skip the test if NO_OPENSSL is already
defined.
> from-source compilations easier. git HEAD already comes with a Makefile (rather
> than a Makefile.in), so I just ran it while testing out patches. I introduced
> the test because I thought the computer could find out about libssl for me,
> rather than myself having to forget to specify NO_OPENSSL every time.
You can simply create a config.mak and put NO_OPENSSL=Yes in it.
It gets included from Makefile.
^ permalink raw reply
* Re: Draft release notes for v1.5.3, as of -rc1
From: Johannes Schindelin @ 2007-07-14 14:22 UTC (permalink / raw)
To: skimo; +Cc: Junio C Hamano, git
In-Reply-To: <20070713092908.GO1528MdfPADPa@greensroom.kotnet.org>
Hi,
On Fri, 13 Jul 2007, Sven Verdoolaege wrote:
> On Thu, Jul 12, 2007 at 11:40:39PM -0700, Junio C Hamano wrote:
> > - "git-filter-branch" lets you rewrite the revision history of
> > the current branch, creating a new branch. You can specify a
> > number of filters to modify the commits, files and trees.
>
> Are you sure you want to announce this so publicly given that
> Dscho has basically declared git-filter-branch dead?
> (I know, I'm mostly to blame.)
It is really unfortunate that rewrite-commits came in so late in the
release cycle, and I am quite sure it should not be in 1.5.3. There is
just too much new in it, and too many things to flesh out.
Junio, if you want to include it in 1.5.3, it should be marked as alpha
code, as it has not seen any time in "next", let alone "master".
However, no matter if rewrite-commits is included in 1.5.3, I am not sure
what to do about filter-branch.
Since it saw a lot of testing in its admin-rewritehist form, and has had
at least some eye pairs looking over it, I have the feeling that it is
stable enough to include. How to tell people that it will soon be
obsoleted by rewrite-commits, I have no idea.
It would be a much less difficult problem if the syntax of filter-branch
and rewrite-commits was identical. Maybe we should make it so, by
changing filter-branch?
Thoughts?
Ciao,
Dscho
^ permalink raw reply
* git-svn: tagging trunk in SVN with git-svn?
From: martin f krafft @ 2007-07-14 14:03 UTC (permalink / raw)
To: git discussion list
[-- Attachment #1: Type: text/plain, Size: 978 bytes --]
Dear list,
I searched the list(s) and even read the code of git-svn, but I am
none the wiser now. From what I understand, git-svn is primarily
used to interact with subversion, rather than doing one-shot imports
(which it can do as well).
I am using it now and it works like a charm (thanks!). However,
I cannot really figure out how to tag the remote trunk from within
git-svn. I tried `git tag tags/1.2.57`, `git tag 1.2.57` and `git
branch tags/1.2.57`, but in none of the three cases does dcommit
think that it needs to push anything upstream.
Is what I am trying to do possible, or do I need to use svn for
that?
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"nothing can cure the soul but the senses,
just as nothing can cure the senses but the soul."
-- oscar wilde
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: mtimes of working files
From: Robin Rosenberg @ 2007-07-14 13:23 UTC (permalink / raw)
To: David Woodhouse
Cc: J. Bruce Fields, Linus Torvalds, Theodore Tso, Andy Parkins, git,
Jan Hudec, Johannes Schindelin
In-Reply-To: <1184374174.2785.104.camel@shinybook.infradead.org>
lördag 14 juli 2007 skrev David Woodhouse:
> On Fri, 2007-07-13 at 20:44 -0400, J. Bruce Fields wrote:
> > On Sat, Jul 14, 2007 at 01:36:33AM +0100, David Woodhouse wrote:
> > > Yeah, much of it. Although I've also seen other people trying to get
> > > to grips with git and tripping up over branches recently.
> >
> > Could you give any details? What specifically was it they were having
> > trouble with?
>
> Just conversations on IRC where stuff had to be explained. People not
> understanding that they'd actually cloned _multiple_ branches and they
> needed to select the one they wanted, making the same kind of stupid
> mistakes I did with committing to the wrong place, etc. Nothing specific
> stands out as being fixable, certainly.
That's why there are scripts that modify the bash prompt to show the current branch.
I made one for stacked git (it works with plain git too). The git completion scripts have
something also I think
It helps a lot for those of us with bad memory implants.
> Branches have their place, and some people seem very happy with them as
> part of their local workflow. I just wonder if we have to have them on
> the servers too; that's all.
Branches are bad if you don't need them as is any feature you don't need is bad, it is
just that many people need branches. Branches are a pain to manage with many SCM
tools, except git, which solves most of the problems with branches.
-- robin
^ permalink raw reply
* Re: [PATCH 2/2] Wire new date formats to --date=<format> parser.
From: Robin Rosenberg @ 2007-07-14 10:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodiflc3v.fsf_-_@assigned-by-dhcp.cox.net>
lördag 14 juli 2007 skrev Junio C Hamano:
> Now we can use all internally supported date formats with
>
> git log --date=<format>
>
> syntax. Earlier, we only allowed relative/local/default.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ack, 1/2 and 2/2.
-- robin
^ permalink raw reply
* Re: mtimes of working files
From: Julian Phillips @ 2007-07-14 13:09 UTC (permalink / raw)
To: David Woodhouse
Cc: Linus Torvalds, Theodore Tso, Andy Parkins, git, Jan Hudec,
Johannes Schindelin
In-Reply-To: <1184370414.2785.79.camel@shinybook.infradead.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2437 bytes --]
On Sat, 14 Jul 2007, David Woodhouse wrote:
> On Fri, 2007-07-13 at 16:18 -0700, Linus Torvalds wrote:
>> Why would anybody force you to do that?
>>
>> The "switch between branchs in the same repo" is really convenient.
>> But nobody *forces* you to do it.
>
> This is true. I already mirror a bunch of CVS and SVN repositories into
> git so that I can use them without too much pain¹, and I can do the same
> for git trees which use branches too; mirroring them into a bunch of
> separate trees for easy access.
>
> On the occasions I actually try to _use_ branches, I find it very
> suboptimal. Perhaps it's just because I'm stupid. I'm sure that's why I
> ended up committing changes to the wrong branch. But having to rebuild
> (even with ccache) after changing branches is a PITA. Just changing
> branches at all is a PITA if you have uncommitted changes (which I
> usually do because I've usually tested _some_ random patch in a build
> tree for the hardware which is closest to hand). Pulling a whole bunch
> of unwanted changes on the 'development' branch while on GPRS, when all
> I really needed was a single commit from the 'stable' branch also didn't
> amuse me, although I'm sure if I had the time to play with it I'd have
> been able to avoid that.
>
> I can, and do, mirror stuff from all kinds of suboptimal version control
> systems into single-branch git trees. And I include multi-branched git
> trees in my definition of 'suboptimal'. My ability to do that doesn't
> really help the newbies who are expected with branches, though.
You can flatten a multi-branched git repo without mirroring into multiple
single-branch repos - The ability to pull out branches into separate trees
from a single repository was what the git-new-workdir script in contrib
was written for.
While I find branches quite a natural concept having used the for the past
few years in Subversion and CVS before that (and after that branches in
git are a delight to use), I still like to have access to all of the
branches that I am working on as separate trees.
git-new-workdir allowed me to do that by scripting an approach described
by Junio. Though maybe it has been superseeded by some built-in feature?
I haven't been following things that closely recently, and ISTR that there
was talk of a feature that would make the script obsolete.
--
Julian
---
You're at Witt's End.
^ permalink raw reply
* 'push origin master' takes over 8 minutes (local ssh)
From: Yakov Lerner @ 2007-07-14 13:00 UTC (permalink / raw)
To: Git Mailing List
Something happened to the repo, and 'push origin master'
is taking now very long time: > 8 minutes (this is ssh to localhost).
It's in git-pack-objects.
The git-pack-objects sits there for >8 minutes using very low cpu (<1 %)
but lots of RAM (>300MB). Then it bombs with malloc error.
I could add swap to the machine [1], but this long time with
low cpu usage is suspicious, no ?
Repo counters are below [2]
I suspect one file, history of which accumulated thousands commits
from the script. I'd like to erase the history of this file but I don't know
how. And I don't know where there is a connection.
Yakov
[1] This is vps machine that hasb 128MB ram + 256MB swap.
[2] Repo counters.
- the master repo which is being pushed to (it is bare, the "master" repo):
count: 653
size: 140692
in-pack: 21730
packs: 2
prune-packable: 5
garbage: 0
the repo which does the push:
count: 369
size: 42960
in-pack: 22145
packs: 4
prune-packable: 9
garbage: 0
Don't ask me about workflow.
I synchronize files between four hosts using git.
I beleive this is very unusual workflow. No branches.
^ 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