* Importing from CVS issues
From: Alex Bennee @ 2005-08-16 10:41 UTC (permalink / raw)
To: git
Hi,
We've been having issues with CVS for some time and I thought I'd give
git a spin. To do some like-for-like tests I'm having a go at importing
our cvs repository into git so I can do some benchmarks on things like
branch creation as well as play around with the visualisation tools.
Obviously the CVS repo is non-trivial as we have many branches (one per
change developed). I've been trying to import script but it seems to
falling over. For starters cvsps is spitting out lots of messages along
the lines of:
WARNING: revision 1.3.2.1 of file scripts/xmltools/t/runtests.pl on
unnamed branch
Before the import script finally dies with:
WARNING: revision 1.3.2.1 of file
scripts/xmltools/t/data/gzip/DO-NOT-BACKUP on unnamed branch
DONE; creating master branch
cp: cannot stat `/export/test/cvstogit/.git/refs/heads/origin': No such
file or directory
usage: git-read-tree (<sha> | -m [-u] <sha1> [<sha2> [<sha3>]])
Is this a just a case of the cvsps not giving output the script can deal
with? Any suggestions on how I can proceed with diagnosing what went
wrong?
--
Alex, homepage: http://www.bennee.com/~alex/
Barometer, n.: An ingenious instrument which indicates what kind of
weather we are having. -- Ambrose Bierce, "The Devil's Dictionary"
^ permalink raw reply
* [PATCH] Add merge detection to git-cvsimport
From: Martin Langhoff @ 2005-08-16 10:35 UTC (permalink / raw)
To: git
[PATCH] Add merge detection to git-cvsimport
Added -m and -M flags for git-cvsimport to detect merge commits in cvs.
While this trusts the commit message, in repositories where merge commits
indicate 'merged from FOOBRANCH' the import works surprisingly well.
Even if some merges from CVS are bogus or incomplete, the resulting
branches are in better state to go forward (and merge) than without any
merge detection.
Signed-off-by: Martin Langhoff <martin.langhoff@gmail.com>
---
Documentation/git-cvsimport-script.txt | 13 ++++++++-
git-cvsimport-script | 48 +++++++++++++++++++++++++++++---
2 files changed, 56 insertions(+), 5 deletions(-)
066d2cb2435a963ee40e4899a76848ea51e972d2
diff --git a/Documentation/git-cvsimport-script.txt b/Documentation/git-cvsimport-script.txt
--- a/Documentation/git-cvsimport-script.txt
+++ b/Documentation/git-cvsimport-script.txt
@@ -11,7 +11,8 @@ SYNOPSIS
--------
'git-cvsimport-script' [ -o <branch-for-HEAD> ] [ -h ] [ -v ]
[ -d <CVSROOT> ] [ -p <options-for-cvsps> ]
- [ -C <GIT_repository> ] [ -i ] [ -k ] [ <CVS_module> ]
+ [ -C <GIT_repository> ] [ -i ] [ -k ]
+ [ -m ] [ -M regex ] [ <CVS_module> ]
DESCRIPTION
@@ -57,6 +58,16 @@ OPTIONS
If you need to pass multiple options, separate them with a comma.
+-m::
+ Attempt to detect merges based on the commit message. This option
+ will enable default regexes that try to capture the name source
+ branch name from the commit message.
+
+-M <regex>::
+ Attempt to detect merges based on the commit message with a custom
+ regex. It can be used with -m to also see the default regexes.
+ You must escape forward slashes.
+
-v::
Verbosity: let 'cvsimport' report what it is doing.
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -28,19 +28,19 @@ use POSIX qw(strftime dup2);
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our($opt_h,$opt_o,$opt_v,$opt_k,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i);
+our($opt_h,$opt_o,$opt_v,$opt_k,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_m,$opt_M);
sub usage() {
print STDERR <<END;
Usage: ${\basename $0} # fetch/update GIT from CVS
[ -o branch-for-HEAD ] [ -h ] [ -v ] [ -d CVSROOT ]
[ -p opts-for-cvsps ] [ -C GIT_repository ] [ -z fuzz ]
- [ -i ] [ -k ] [ CVS_module ]
+ [ -i ] [ -k ] [ -m ] [ -M regex] [ CVS_module ]
END
exit(1);
}
-getopts("hivko:d:p:C:z:") or usage();
+getopts("hivmko:d:p:C:z:M:") or usage();
usage if $opt_h;
@ARGV <= 1 or usage();
@@ -70,11 +70,19 @@ if ($#ARGV == 0) {
die 'Failed to open CVS/Repository';
$cvs_tree = <$f>;
chomp $cvs_tree;
- close $f
+ close $f;
} else {
usage();
}
+our @mergerx = ();
+if ($opt_m) {
+ @mergerx = ( qr/\W(?:from|of|merge|merging|merged) (\w+)/i );
+}
+if ($opt_M) {
+ push (@mergerx, qr/$opt_M/);
+}
+
select(STDERR); $|=1; select(STDOUT);
@@ -374,6 +382,22 @@ sub getwd() {
return $pwd;
}
+
+sub get_headref($$) {
+ my $name = shift;
+ my $git_dir = shift;
+ my $sha;
+
+ if (open(C,"$git_dir/refs/heads/$name")) {
+ chomp($sha = <C>);
+ close(C);
+ length($sha) == 40
+ or die "Cannot get head id for $name ($sha): $!\n";
+ }
+ return $sha;
+}
+
+
-d $git_tree
or mkdir($git_tree,0777)
or die "Could not create $git_tree: $!";
@@ -548,6 +572,22 @@ my $commit = sub {
my @par = ();
@par = ("-p",$parent) if $parent;
+
+ # loose detection of merges
+ # based on the commit msg
+ foreach my $rx (@mergerx) {
+ if ($logmsg =~ $rx) {
+ my $mparent = $1;
+ if ($mparent eq 'HEAD') { $mparent = 'origin'};
+ if ( -e "$git_dir/refs/heads/$mparent") {
+ $mparent = get_headref($mparent, $git_dir);
+ push @par, '-p', $mparent;
+ # printing here breaks import #
+ # # print "Merge parent branch: $mparent\n" if $opt_v;
+ }
+ }
+ }
+
exec("env",
"GIT_AUTHOR_NAME=$author",
"GIT_AUTHOR_EMAIL=$author",
^ permalink raw reply
* about git server & permissions
From: Dongsheng Song @ 2005-08-16 10:17 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0508161158400.3026@wgmdd8.biozentrum.uni-wuerzburg.de>
Hi,
Is there any guide or advise for deploy git server ? Especially
http/https/ssh server.
How do I set repository permissions correctly?
cauchy
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v4)
From: Dongsheng Song @ 2005-08-16 10:14 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0508161158400.3026@wgmdd8.biozentrum.uni-wuerzburg.de>
Hi,
Is there any guide or advise for deploy git server ?
How do I set repository permissions correctly?
cauchy
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v4)
From: Johannes Schindelin @ 2005-08-16 10:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Ryan Anderson, git
In-Reply-To: <7vy872fiin.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 978 bytes --]
Hi,
On Tue, 16 Aug 2005, Junio C Hamano wrote:
> - Glossary documentation Johannes Schindelin is working on.
Yeah, yeah. Call _me_ lazy :-) I'll try to come up with a discussable item
today.
> - git prune and git fsck-cache; think about their interactions
> with an object database that borrows from another. This
> includes the case where .git/objects itself is symlinked to
> somewhere else (i.e. running "git prune" that somewhere else
> without consulting this repository would lose objects), and
> alternates pointing at somewhere else (i.e. ditto).
I don´t see how git could help in the case you are pruning a repository
which another repository points to. After all, the first repository
doesn´t know about being used by the second.
> I am sure I am forgetting something, but the above would be a
> good start.
Maybe your $GIT_DIR/remotes idea? Along with a "--store <remotename>" flag
to git-pull-script?
Ciao,
Dscho
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v4)
From: Junio C Hamano @ 2005-08-16 7:28 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Ryan Anderson, git
In-Reply-To: <Pine.LNX.4.63.0508151453100.21501@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> It might be worth putting the list of things left to do before 1.0 in the
> tree (since they clearly covary), and it would be useful to know what
> you're thinking of as preventing the release at any particular stage.
Yeah, yeah. Call me lazy.
Excerpts from my "last mile to 1.0", my Itchlist, and pieces from
random other messages since then.
- Documentation. [I really need help here --- among ~7000 lines
there, I've written around 2500 lines, David Greaves another
2500, and Linus 1400. And it is not very easy to proofread
what you wrote yourself.]
- Are all the core commands described in Documentation/
directory?
- Many files under Documentation/ directory have become stale.
I've tried to do one pass of full sweep recently [and
another since I wrote the original "last mile" message], but
I'd like somebody else to make another pass to make sure
that the usage strings in programs, what the programs do,
and what Documentation says they do match. Also, the
spelling and grammar fixes, which I am very bad at and have
not done any attempt, needs to be done.
Volunteers?
- Are all the files in Documentation/ reachable from git(7)
or otherwise made into a standalone document using asciidoc
by the Makefile? I haven't looked into documentation
generation myself (I use only the text files as they are);
help to update the Makefile by somebody handy with asciidoc
suite is greatly appreciated here.
Volunteers?
- We may want to describe more Best Current Practices, along
the lines of "Working with Others" section in the tutorial.
Please write on your faviorite topic and send patches in
;-)) [ryan started collecting Documentation/howto which
would greatly help in this area].
- Glossary documentation Johannes Schindelin is working on.
I think coming up with the concensus of terms would come
fairly quickly on the list. Updating docs to match the
concensus may take some time. Help is greatly appreciated.
- Maybe doing another pass at tutorial. Could somebody run
(or preferably, find a friend who has never touched git and
have her run) the tutorial examples from the beginning to
the end, and find rooms of improvements? Does the order of
materials presented make sense? Do we talk about things
assuming that the user knows something else that we have not
talked about? Have we introduced better way of doing the
same thing since the tutorial was written?
I've done that once with the text that is currently in the
head of the master branch, but that is getting rather stale,
and also I did that myself so I am sure I've sidestepped
pitfalls without even realizing.
The above does not have to be all there in 0.99.5, but I
consider that lack of any of the above to block 1.0.
- Commit walker downloading from packed repository is finally
complete. Thanks, Daniel!
- Teach fetch-pack reference renaming.
On the push side, send-pack now knows updating arbitrary
remote references from local references. We need something
similar for fetching [since then I outlined the design of the
new shorthand file format and semantics but have not got
around to actually do it. Maybe on my next GIT day...]. This
is scheduled for 0.99.5.
- commit template filler discussed with Pasky some time ago,
with perhaps pre-commit and post-commit hooks. Somehow the
discussion died out but that does not mean _I_ forgot about
it.
- Binary packaging. Should _I_ worry about "/usr/bin/git" stay
there myself --- I think not. But I _do_ want to help Debian
packaging folks if that path is causing problems in their
effort to push git-core into the official Debian archive.
As Linus mentioned earlier, this seems to be a Debian specific
problem, and will not block 1.0 --- if Debian heavyweights do
not want to stay compatible with the rest of the world, so be
it.
- I have not heard from Darwin or BSD people for some time. Is
your portfile up to date? Do you have updates you want me to
include? Have we introduced non-Linux non-GNU
incompatibilities lately that you want to see fixed and/or
worked around?
Again, I consider binary packaging issue independent from our
release schedule; it is a distribution local issue, so this
would not block 1.0 in any way. But I _am_ willing to help
them.
- Oh, another itch I did not list in the previous message. Is
anybody interested in doing an Emacs VC back-end for GIT?
- git prune and git fsck-cache; think about their interactions
with an object database that borrows from another. This
includes the case where .git/objects itself is symlinked to
somewhere else (i.e. running "git prune" that somewhere else
without consulting this repository would lose objects), and
alternates pointing at somewhere else (i.e. ditto).
My personal feeling is that we should just warn users about
doing .git/objects symlinking and/or alternates pointing ---
do not do it unless you have an off-line arrangement with the
owner of the repository you are borrowing from. Even if that
would become our official position to take, it needs to be
documented clearly before we declare this issue to have been
"dealt with".
I am sure I am forgetting something, but the above would be a
good start.
^ permalink raw reply
* Re: symlinked directories in refs are now unreachable
From: Junio C Hamano @ 2005-08-16 6:25 UTC (permalink / raw)
To: Matt Draisey; +Cc: git
In-Reply-To: <1124171194.762.74.camel@della.draisey.ca>
Matt Draisey <mattdraisey@sympatico.ca> writes:
> On Sun, 2005-08-14 at 22:12 -0700, Junio C Hamano wrote:
>> I would like to know
>> a use case or two to illustrate why there are symlinks pointing
>> at real files outside .git/refs/ hierarchy, and how that
>> arrangement is useful.
>...
> This email is a bit long-winded so I didn't CC it to the mailing list.
Thanks for a clear explanation. Your arrangement indeed is an
intriguing one, in that there are very similar issues in the
fsck/prune area even with arrangements quite different from
yours. I personally think your reasoning about this issue
deserves to be shared with the list. I'll CC _this_ message to
the list and leave it up to you to forward your words there as
well.
People are known to do something similar to what you are doing
without having any special commit tool. They just do this:
$ mkdir A B
$ cd A && git init-db
$ cd ../B && git init-db
$ rm -fr .git/objects && ln -s ../../A/.git/objects .git/objects
The repositories A and B share the same object database,
and they have independent sets of refs. For the exact same
reason as your arrangement, you cannot "git prune" in either
repository, because they do not know about objects reachable
only from the other side.
Further, one repository can borrow objects from another
repository via the .git/objects/info/alternates mechanism. This
is useful when a repository is a local clone of another. You
would do this:
$ git clone -l -s linux-2.6/.git/ my-linux
$ cd my-linux && cat .git/objects/info/alternates
/path/to/linux-2.6/.git/
The new repository my-linux has the .git/objects with 256
fan-out subdirectories, but starts out without any object files
in it. It literally borrows the existing objects from the
neighbouring repository, and its own .git/objects hierarchy is
only used to hold newly created objects in it. For the same
reason as your arrangement, you should not "git prune" the
linux-2.6 repository, either. However, my-linux repository can
be pruned as long as somebody else does not "borrow" from it.
So while I find your "do follow symlink" patch an improvement in
that it makes things a little bit safer, I think there should be
a more generalized way to say "this object database holds things
that are refered by these refs/ directories outside. fsck/prune
had better hold onto objects referenced by them, not just by the
refs directory that happens to be next to th objects directory".
That would be the inverse of .git/objects/info/alternates.
-jc
^ permalink raw reply
* [PATCH] Add -k kill keyword expansion option to git-cvsimport - revised
From: Martin Langhoff @ 2005-08-16 5:39 UTC (permalink / raw)
To: git
[PATCH] Add -k kill keyword expansion option to git-cvsimport - revised
Early versions of git-cvsimport defaulted to using preexisting keyword
expansion settings. This change preserves compatibility with existing cvs
imports and allows new repository migrations to kill keyword expansion.
After exploration of the different -k modes in the cvs protocol, we use -kk
which kills keyword expansion wherever possible. Against the protocol
spec, -ko and -kb will sometimes expand keywords.
Should improve our chances of detecting merges and reduce imported
repository size.
Signed-off: Martin Langhoff <martin.langhoff@gmail.com>
---
Documentation/git-cvsimport-script.txt | 7 ++++++-
git-cvsimport-script | 12 +++++++-----
2 files changed, 13 insertions(+), 6 deletions(-)
3be96ff6fee32974b66fe1743eb701e93032fee5
diff --git a/Documentation/git-cvsimport-script.txt b/Documentation/git-cvsimport-script.txt
--- a/Documentation/git-cvsimport-script.txt
+++ b/Documentation/git-cvsimport-script.txt
@@ -11,7 +11,7 @@ SYNOPSIS
--------
'git-cvsimport-script' [ -o <branch-for-HEAD> ] [ -h ] [ -v ]
[ -d <CVSROOT> ] [ -p <options-for-cvsps> ]
- [ -C <GIT_repository> ] [ -i ] [ <CVS_module> ]
+ [ -C <GIT_repository> ] [ -i ] [ -k ] [ <CVS_module> ]
DESCRIPTION
@@ -38,6 +38,11 @@ OPTIONS
ensures the working directory and cache remain untouched and will
not create them if they do not exist.
+-k::
+ Kill keywords: will extract files with -kk from the CVS archive
+ to avoid noisy changesets. Highly recommended, but off by default
+ to preserve compatibility with early imported trees.
+
-o <branch-for-HEAD>::
The 'HEAD' branch from CVS is imported to the 'origin' branch within
the git repository, as 'HEAD' already has a special meaning for git.
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -28,19 +28,19 @@ use POSIX qw(strftime dup2);
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our($opt_h,$opt_o,$opt_v,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i);
+our($opt_h,$opt_o,$opt_v,$opt_k,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i);
sub usage() {
print STDERR <<END;
Usage: ${\basename $0} # fetch/update GIT from CVS
[ -o branch-for-HEAD ] [ -h ] [ -v ] [ -d CVSROOT ]
[ -p opts-for-cvsps ] [ -C GIT_repository ] [ -z fuzz ]
- [ -i ] [ CVS_module ]
+ [ -i ] [ -k ] [ CVS_module ]
END
exit(1);
}
-getopts("hivo:d:p:C:z:") or usage();
+getopts("hivko:d:p:C:z:") or usage();
usage if $opt_h;
@ARGV <= 1 or usage();
@@ -218,8 +218,10 @@ sub _file {
my($self,$fn,$rev) = @_;
$self->{'socketo'}->write("Argument -N\n") or return undef;
$self->{'socketo'}->write("Argument -P\n") or return undef;
- # $self->{'socketo'}->write("Argument -ko\n") or return undef;
- # -ko: Linus' version doesn't use it
+ # -kk: Linus' version doesn't use it - defaults to off
+ if ($opt_k) {
+ $self->{'socketo'}->write("Argument -kk\n") or return undef;
+ }
$self->{'socketo'}->write("Argument -r\n") or return undef;
$self->{'socketo'}->write("Argument $rev\n") or return undef;
$self->{'socketo'}->write("Argument --\n") or return undef;
^ permalink raw reply
* Re: [patch] possible memory leak in diff.c::diff_free_filepair()
From: Junio C Hamano @ 2005-08-16 4:32 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <8764u6ponn.wl@mail2.atmark-techno.com>
Yasushi SHOJI <yashi@atmark-techno.com> writes:
> parepare_temp_file() and diff_populate_filespec() has a lot in
> similarity. so it'd be nice to refactor some. and re-introduce
> diff_free_filespec_data() and call right after prep_temp_blob() in
> prepare_temp_file().
Another thing that may (or may not) help would be to move that
prepare_temp_file() and stuff to happen in the forked child
process instead of the parent, so that we do not have to worry
about freeing the buffer; it has been some time since I worked
on that part of the code so this may not be an option to make
things easier.
> Junio, did you also mean to clean-up these functions when you said in
> the thread of "Re: gitweb - option to disable rename detection"?
No. I was talking about cleaning up the similar option parsing
code, and the call into diffcore_std() which takes more
arguments every time a new option is added to the family.
^ permalink raw reply
* [PATCH] Support packs in local-pull
From: Daniel Barkalow @ 2005-08-16 4:10 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <Pine.LNX.4.63.0508160004460.23242@iabervon.org>
If it doesn't find an object, it looks for an index that contains it
and uses the same methods on that instead.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
local-pull.c | 112 +++++++++++++++++++++++++++++++++++++++++++++++-----------
1 files changed, 91 insertions(+), 21 deletions(-)
aafbc7fb9ae059b9c9afa42e8d2c0548ea960f9f
diff --git a/local-pull.c b/local-pull.c
--- a/local-pull.c
+++ b/local-pull.c
@@ -15,34 +15,54 @@ void prefetch(unsigned char *sha1)
{
}
-int fetch(unsigned char *sha1)
+static struct packed_git *packs = NULL;
+
+void setup_index(unsigned char *sha1)
{
- static int object_name_start = -1;
- static char filename[PATH_MAX];
- char *hex = sha1_to_hex(sha1);
- const char *dest_filename = sha1_file_name(sha1);
+ struct packed_git *new_pack;
+ char filename[PATH_MAX];
+ strcpy(filename, path);
+ strcat(filename, "/objects/pack/pack-");
+ strcat(filename, sha1_to_hex(sha1));
+ strcat(filename, ".idx");
+ new_pack = parse_pack_index_file(sha1, filename);
+ new_pack->next = packs;
+ packs = new_pack;
+}
- if (object_name_start < 0) {
- strcpy(filename, path); /* e.g. git.git */
- strcat(filename, "/objects/");
- object_name_start = strlen(filename);
+int setup_indices()
+{
+ DIR *dir;
+ struct dirent *de;
+ char filename[PATH_MAX];
+ unsigned char sha1[20];
+ sprintf(filename, "%s/objects/pack/", path);
+ dir = opendir(filename);
+ while ((de = readdir(dir)) != NULL) {
+ int namelen = strlen(de->d_name);
+ if (namelen != 50 ||
+ strcmp(de->d_name + namelen - 5, ".pack"))
+ continue;
+ get_sha1_hex(sha1, de->d_name + 5);
+ setup_index(sha1);
}
- filename[object_name_start+0] = hex[0];
- filename[object_name_start+1] = hex[1];
- filename[object_name_start+2] = '/';
- strcpy(filename + object_name_start + 3, hex + 2);
+ return 0;
+}
+
+int copy_file(const char *source, const char *dest, const char *hex)
+{
if (use_link) {
- if (!link(filename, dest_filename)) {
+ if (!link(source, dest)) {
pull_say("link %s\n", hex);
return 0;
}
/* If we got ENOENT there is no point continuing. */
if (errno == ENOENT) {
- fprintf(stderr, "does not exist %s\n", filename);
+ fprintf(stderr, "does not exist %s\n", source);
return -1;
}
}
- if (use_symlink && !symlink(filename, dest_filename)) {
+ if (use_symlink && !symlink(source, dest)) {
pull_say("symlink %s\n", hex);
return 0;
}
@@ -50,25 +70,25 @@ int fetch(unsigned char *sha1)
int ifd, ofd, status;
struct stat st;
void *map;
- ifd = open(filename, O_RDONLY);
+ ifd = open(source, O_RDONLY);
if (ifd < 0 || fstat(ifd, &st) < 0) {
close(ifd);
- fprintf(stderr, "cannot open %s\n", filename);
+ fprintf(stderr, "cannot open %s\n", source);
return -1;
}
map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, ifd, 0);
close(ifd);
if (map == MAP_FAILED) {
- fprintf(stderr, "cannot mmap %s\n", filename);
+ fprintf(stderr, "cannot mmap %s\n", source);
return -1;
}
- ofd = open(dest_filename, O_WRONLY | O_CREAT | O_EXCL, 0666);
+ ofd = open(dest, O_WRONLY | O_CREAT | O_EXCL, 0666);
status = ((ofd < 0) ||
(write(ofd, map, st.st_size) != st.st_size));
munmap(map, st.st_size);
close(ofd);
if (status)
- fprintf(stderr, "cannot write %s\n", dest_filename);
+ fprintf(stderr, "cannot write %s\n", dest);
else
pull_say("copy %s\n", hex);
return status;
@@ -77,6 +97,56 @@ int fetch(unsigned char *sha1)
return -1;
}
+int fetch_pack(unsigned char *sha1)
+{
+ struct packed_git *target;
+ char filename[PATH_MAX];
+ if (setup_indices())
+ return -1;
+ target = find_sha1_pack(sha1, packs);
+ if (!target)
+ return error("Couldn't find %s: not separate or in any pack",
+ sha1_to_hex(sha1));
+ if (get_verbosely) {
+ fprintf(stderr, "Getting pack %s\n",
+ sha1_to_hex(target->sha1));
+ fprintf(stderr, " which contains %s\n",
+ sha1_to_hex(sha1));
+ }
+ sprintf(filename, "%s/objects/pack/pack-%s.pack",
+ path, sha1_to_hex(sha1));
+ copy_file(filename, sha1_pack_name(sha1), sha1_to_hex(sha1));
+ sprintf(filename, "%s/objects/pack/pack-%s.idx",
+ path, sha1_to_hex(sha1));
+ copy_file(filename, sha1_pack_index_name(sha1), sha1_to_hex(sha1));
+ install_packed_git(target);
+ return 0;
+}
+
+int fetch_file(unsigned char *sha1)
+{
+ static int object_name_start = -1;
+ static char filename[PATH_MAX];
+ char *hex = sha1_to_hex(sha1);
+ const char *dest_filename = sha1_file_name(sha1);
+
+ if (object_name_start < 0) {
+ strcpy(filename, path); /* e.g. git.git */
+ strcat(filename, "/objects/");
+ object_name_start = strlen(filename);
+ }
+ filename[object_name_start+0] = hex[0];
+ filename[object_name_start+1] = hex[1];
+ filename[object_name_start+2] = '/';
+ strcpy(filename + object_name_start + 3, hex + 2);
+ return copy_file(filename, dest_filename, hex);
+}
+
+int fetch(unsigned char *sha1)
+{
+ return fetch_file(sha1) && fetch_pack(sha1);
+}
+
int fetch_ref(char *ref, unsigned char *sha1)
{
static int ref_name_start = -1;
^ permalink raw reply
* [PATCH] Add function to read an index file from an arbitrary filename.
From: Daniel Barkalow @ 2005-08-16 4:10 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <Pine.LNX.4.63.0508160004460.23242@iabervon.org>
Note that the pack file has to be in the usual location if it gets
installed later.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
cache.h | 2 ++
sha1_file.c | 10 ++++++++--
2 files changed, 10 insertions(+), 2 deletions(-)
59e5c6d163edae5da6136560d48a4750cceacdc6
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -319,6 +319,8 @@ extern int get_ack(int fd, unsigned char
extern struct ref **get_remote_heads(int in, struct ref **list, int nr_match, char **match);
extern struct packed_git *parse_pack_index(unsigned char *sha1);
+extern struct packed_git *parse_pack_index_file(unsigned char *sha1,
+ char *idx_path);
extern void prepare_packed_git(void);
extern void install_packed_git(struct packed_git *pack);
diff --git a/sha1_file.c b/sha1_file.c
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -476,12 +476,18 @@ struct packed_git *add_packed_git(char *
struct packed_git *parse_pack_index(unsigned char *sha1)
{
+ char *path = sha1_pack_index_name(sha1);
+ return parse_pack_index_file(sha1, path);
+}
+
+struct packed_git *parse_pack_index_file(unsigned char *sha1, char *idx_path)
+{
struct packed_git *p;
unsigned long idx_size;
void *idx_map;
- char *path = sha1_pack_index_name(sha1);
+ char *path;
- if (check_packed_git_idx(path, &idx_size, &idx_map))
+ if (check_packed_git_idx(idx_path, &idx_size, &idx_map))
return NULL;
path = sha1_pack_name(sha1);
^ permalink raw reply
* [PATCH 0/2] Fix local-pull on packed repository
From: Daniel Barkalow @ 2005-08-16 4:09 UTC (permalink / raw)
To: git
This adds essentially the same logic to local-pull that http-pull has,
with the exception that it reads the index out of the source directory,
rather than copying it. This, in turn, requires the ability to use an
index file in some other directory.
1: Use index file in another directory
2: Copy/link/symlink pack files as appropriate
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Add SubmittingPatches
From: Ryan Anderson @ 2005-08-16 3:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0508160335420.1574@wgmdd8.biozentrum.uni-wuerzburg.de>
On Tue, Aug 16, 2005 at 03:41:04AM +0200, Johannes Schindelin wrote:
> On Mon, 15 Aug 2005, Junio C Hamano wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > Maybe we should enhance git-applymbox to detect whitespace corruption in
> > > particular, and output the User-Agent header (or if that does not
> > > exist, the Message-ID header; thanks, pine) on error.
> >
>
> Alternatively, SubmittingPatches could include a big fat CAVEAT, and a
> note that the submitter might want to send a single SP to herself, save
> the received mail and check that all is well, prior to sending the first
> patch. I mean, well, erm, it is sort of, uh, annoying, to send out a
> corrupt patch *speaksofyourstruly*.
If you have some trouble sending them out, you can use
git format-patch --mbox
and
git send-email
which seems to consistently do the right thing.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: How do I track pu branch?
From: Martin Langhoff @ 2005-08-16 3:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q9qr4gn.fsf@assigned-by-dhcp.cox.net>
On 8/16/05, Junio C Hamano <junkio@cox.net> wrote:
> Martin Langhoff <martin.langhoff@gmail.com> writes:
>
> > Following an extenal repo, I am not getting all the heads. This is by
> > design, AFAIK, and the question is how do I find what heads the repo
> > offers and pull them in so I can call them by name?
>
> I suspect the Subject: line and your question do not mesh well,
> but anyway..
And even then, your answer is great. Thanks!
I was half-expecting a mechanism to track "all branches/heads from a
remote repo" by rsync'ing the refs/heads directory outside of the git
protocol. That's perhaps why I had the wrong mindset.
All in all, it is a bit of a roundabout way of tracking things.
cheers,
martin
^ permalink raw reply
* Re: [patch] possible memory leak in diff.c::diff_free_filepair()
From: Yasushi SHOJI @ 2005-08-16 3:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viry9le0g.fsf@assigned-by-dhcp.cox.net>
At Sat, 13 Aug 2005 14:31:59 -0700,
Junio C Hamano wrote:
>
> Yasushi SHOJI <yashi@atmark-techno.com> writes:
>
> > oops. probably my english wasn't clear. my patch fixes
> > diff_free_filepair().
>
> When the command is run on linux-2.6 repository, virtual memory
> consumption of git-diff-tree command skyrockets to about half a
> gig, because it maps all files in two adjacent revisions of the
> entire kernel tree. But it seems to reclaim things reasonably
> well and goes back down to less than 10m when it starts to
> process the next commit pair.
it tunes out that, at least for my problem is to populating filespec
data in parepare_temp_file() and not freeing it after creating temp
file with prep_temp_blob().
parepare_temp_file() and diff_populate_filespec() has a lot in
similarity. so it'd be nice to refactor some. and re-introduce
diff_free_filespec_data() and call right after prep_temp_blob() in
prepare_temp_file().
Junio, did you also mean to clean-up these functions when you said in
the thread of "Re: gitweb - option to disable rename detection"?
regards,
--
yashi
^ permalink raw reply
* Re: How do I track pu branch?
From: Junio C Hamano @ 2005-08-16 2:55 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <7v4q9qr4gn.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Martin Langhoff <martin.langhoff@gmail.com> writes:
>
>> Following an extenal repo, I am not getting all the heads. This is by
>> design, AFAIK, and the question is how do I find what heads the repo
>> offers and pull them in so I can call them by name?
Sorry, "git ls-remote" was the answer to only the first
question. Regarding your second question.
Once you have found out about them, the way to use shorthand the
current tool offers is:
$ echo 'http://www.kernel.org/pub/scm/git/git.git/#pu' \
>.git/branches/ko-pu
$ git fetch ko-pu
Any "git fetch" creates .git/FETCH_HEAD file which holds the
SHA1 object name of the fetched commit, but when shorthand
recorded in .git/branches is involved, it additionally creates
the file ".git/refs/heads/ko-pu". Then you could:
$ git checkout -b for-junio ko-pu
$ git apply --index <cvsimport-use-kk-flag.patch
$ git commit -v -s
$ git format-patch ko-pu..HEAD
Note. As I may have said elsewhere, "pu" branch in git.git
repository is rebased almost daily, so please be prepared to
throw away any branches you may fork off from it.
Note. The shorthand notation for the pull/fetch side is planned
to be enhanced so that you can keep track of multiple remote
heads. That has not happened yet.
^ permalink raw reply
* Re: How do I track pu branch?
From: Junio C Hamano @ 2005-08-16 2:38 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f9050815185629e5c4b6@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> Following an extenal repo, I am not getting all the heads. This is by
> design, AFAIK, and the question is how do I find what heads the repo
> offers and pull them in so I can call them by name?
I suspect the Subject: line and your question do not mesh well,
but anyway..
$ git ls-remote http://www.kernel.org/pub/scm/git/git.git/
2150cc99fe29fd81db1e9c5971e13bcb78373ebf refs/heads/master
ce1eb6614e4e8308585b75029ad0823389890eb9 refs/heads/pu
14fb44880c1143ae0259842c808c036e78b516f6 refs/heads/rc
0918385dbd9656cab0d1d81ba7453d49bbc16250 refs/tags/junio-gpg-pub
d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99
f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/v0.99.1
c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2
7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3
b3e9704ecdf48869f635f0aa99ddfb513f885aff refs/tags/v0.99.4
NOTE. When talking to http(s) URL, the server side needs to be
prepared to support the dumb server protocol. That is, to have
run git-update-server-info there whenever the repository is
updated. Other transports do not have this restriction.
-jc
^ permalink raw reply
* How do I track pu branch?
From: Martin Langhoff @ 2005-08-16 1:56 UTC (permalink / raw)
To: GIT
Following an extenal repo, I am not getting all the heads. This is by
design, AFAIK, and the question is how do I find what heads the repo
offers and pull them in so I can call them by name?
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Add SubmittingPatches
From: Johannes Schindelin @ 2005-08-16 1:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6imr7x0.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 15 Aug 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Maybe we should enhance git-applymbox to detect whitespace corruption in
> > particular, and output the User-Agent header (or if that does not
> > exist, the Message-ID header; thanks, pine) on error.
>
Alternatively, SubmittingPatches could include a big fat CAVEAT, and a
note that the submitter might want to send a single SP to herself, save
the received mail and check that all is well, prior to sending the first
patch. I mean, well, erm, it is sort of, uh, annoying, to send out a
corrupt patch *speaksofyourstruly*.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add SubmittingPatches
From: Junio C Hamano @ 2005-08-16 1:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508160252310.26927@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Maybe we should enhance git-applymbox to detect whitespace corruption in
> particular, and output the User-Agent header (or if that does not
> exist, the Message-ID header; thanks, pine) on error.
We _could_ but I doubt it would help anybody. The damage is
already done.
^ permalink raw reply
* Re: gitweb - option to disable rename detection
From: Junio C Hamano @ 2005-08-16 1:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508151542290.3553@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> This makes it somewhat more expensive - I was thinking about disabling it
> in git-diff-tree, since the rename logic already knows how many
> new/deleted files there are.
That's doable. I'll rig something up on my next GIT day, along
with the clean-up for diff option handling which we have
postponed for some time. Clearly this would introduce another
option to diffcore.
OTOH, you could take totally the opposite avenue and take
advantage of the fact that git commit ancestry is immultable.
Once commitdiff is made, you do not have to regenerate it but
cache it and reuse for the next request. I may be mistaken, but
I vaguely recall kernel.org webservers already does something
like that.
If you have infinite amount of disk space, you could choose to
cache everything, and also prime the cache before any real users
ask for a page. Once you go that route, you could even give -C
flag for copy detection, with --find-copies-harder which is an
ultra expensive option, and nobody would notice.
^ permalink raw reply
* Re: [PATCH] Add SubmittingPatches
From: Johannes Schindelin @ 2005-08-16 1:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0508151715520.3553@g5.osdl.org>
Hi,
On Mon, 15 Aug 2005, Linus Torvalds wrote:
> On Tue, 16 Aug 2005, Johannes Schindelin wrote:
> >
> > BTW, I don't know how many people still use pine, but for those poor souls
> > it may be good to mention that the quell-flowed-text is needed for recent
> > versions.
>
> And 4.58 needs at least this
>
>[...]
Sorry, I forgot the "no-strip-whitespace-before-send" option, too. AFAIK
it was introduced in 4.60 (the "fix" Junio was referring to).
Maybe we should enhance git-applymbox to detect whitespace corruption in
particular, and output the User-Agent header (or if that does not
exist, the Message-ID header; thanks, pine) on error.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add SubmittingPatches
From: Junio C Hamano @ 2005-08-16 0:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.58.0508151715520.3553@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> And 4.58 needs at least this
> diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from e886a61f76edf5410573e92e38ce22974f9c40f1)
> Author: Linus Torvalds <torvalds@g5.osdl.org>
> Date: Mon Aug 15 17:23:51 2005 -0700
>
> Fix pine whitespace-corruption bug
>
> There's no excuse for unconditionally removing whitespace from
> the pico buffers on close.
Wow.
This is a _terrible_ one. Isn't pico code also supposed to be a
standalone editor of some sort? I wonder how anybody could
tolerate this kind of "dictatorship ;-)".
At least the changelog entry seems to say that 4.60 removed this
"feature".
^ permalink raw reply
* Re: [PATCH] Add SubmittingPatches
From: Linus Torvalds @ 2005-08-16 0:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0508160147560.26580@wgmdd8.biozentrum.uni-wuerzburg.de>
On Tue, 16 Aug 2005, Johannes Schindelin wrote:
>
> BTW, I don't know how many people still use pine, but for those poor souls
> it may be good to mention that the quell-flowed-text is needed for recent
> versions.
And 4.58 needs at least this
Linus
---
diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from e886a61f76edf5410573e92e38ce22974f9c40f1)
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Mon Aug 15 17:23:51 2005 -0700
Fix pine whitespace-corruption bug
There's no excuse for unconditionally removing whitespace from
the pico buffers on close.
diff --git a/pico/pico.c b/pico/pico.c
--- a/pico/pico.c
+++ b/pico/pico.c
@@ -219,7 +219,9 @@ PICO *pm;
switch(pico_all_done){ /* prepare for/handle final events */
case COMP_EXIT : /* already confirmed */
packheader();
+#if 0
stripwhitespace();
+#endif
c |= COMP_EXIT;
break;
^ permalink raw reply
* Re: [PATCH] Add SubmittingPatches
From: Junio C Hamano @ 2005-08-16 0:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508160147560.26580@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> BTW, I don't know how many people still use pine, but for those poor souls
> it may be good to mention that the quell-flowed-text is needed for recent
> versions.
Contributions from pine users are very much appreciated. Among
the patches I either receive or pick up from the list, 15-20%
have WS corruption one way or another, which is starting to
annoy me. What annoys me more are MIME quoted printable,
though, but that is partly my fault.
I haven't counted what percentage of those WS corrupted ones are
from Pine, so please do not take the above 15-20% number to have
anything to do with Pine.
^ 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