* [PATCH] tar-tree: file/dirmode fix.
From: Junio C Hamano @ 2006-03-04 5:35 UTC (permalink / raw)
To: git; +Cc: Matt McCutchen
In-Reply-To: <1141446331.3171.4.camel@mattlaptop>
This fixes two bugs introduced when we switched to generic tree
traversal code.
(1) directory mode recorded silently became 0755, not 0777
(2) if passed a tree object (not a commit), it emitted an
alarming error message (but proceeded anyway).
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
tar-tree.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
815afaf1bd0ddf419231d2d9f129260ce1ddbecc
diff --git a/tar-tree.c b/tar-tree.c
index e85a1ed..e478e13 100644
--- a/tar-tree.c
+++ b/tar-tree.c
@@ -304,9 +304,11 @@ static void write_header(const unsigned
}
if (S_ISDIR(mode))
- mode |= 0755; /* GIT doesn't store permissions of dirs */
- if (S_ISLNK(mode))
- mode |= 0777; /* ... nor of symlinks */
+ mode |= 0777;
+ else if (S_ISREG(mode))
+ mode |= (mode & 0100) ? 0777 : 0666;
+ else if (S_ISLNK(mode))
+ mode |= 0777;
sprintf(&header[100], "%07o", mode & 07777);
/* XXX: should we provide more meaningful info here? */
@@ -391,7 +393,7 @@ int main(int argc, char **argv)
usage(tar_tree_usage);
}
- commit = lookup_commit_reference(sha1);
+ commit = lookup_commit_reference_gently(sha1, 1);
if (commit) {
write_global_extended_header(commit->object.sha1);
archive_time = commit->date;
--
1.2.4.gfe04
^ permalink raw reply related
* Re: Producing tar file with 666/777 permissions
From: Junio C Hamano @ 2006-03-04 5:03 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1141446331.3171.4.camel@mattlaptop>
Matt McCutchen <hashproduct@verizon.net> writes:
> Dear GIT people,
>
> How do I package a git repository in a tar file with 666 and 777
> embedded permissions? There's evidently some way to do it because the
> Linux kernel source packages have 666 and 777 embedded permissions, but
> git-tar-tree gives me a tar file with 644 and 755 permissions and
> there's no obvious way to tell it to do otherwise.
Ouch, thanks for reporting this. You have spotted a recent
regression.
^ permalink raw reply
* [PATCH] cvsserver: nested directory creation fixups for Eclipse clients
From: Martin Langhoff @ 2006-03-04 4:47 UTC (permalink / raw)
To: git, junkio; +Cc: Martin Langhoff
To create nested directories without (or before) sending file entries
is rather tricky. Most clients just work. Eclipse, however, expects
a very specific sequence of events. With this patch, cvsserver meets
those expectations.
Note: we may want to reuse prepdir() in req_update -- should move it
outside of req_co. Right now prepdir() is tied to how req_co() works.
---
git-cvsserver.perl | 73 ++++++++++++++++++++++++++++++++++++++++------------
1 files changed, 56 insertions(+), 17 deletions(-)
701168bf1ddad1dbc3788e58181589dc082ce536
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index ab32d3e..b450792 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -592,6 +592,11 @@ sub req_co
print $state->{CVSROOT} . "/$module/\n";
print "Clear-static-directory $checkout_path/\n";
print $state->{CVSROOT} . "/$module/\n";
+ print "Clear-sticky $checkout_path/\n"; # yes, twice
+ print $state->{CVSROOT} . "/$module/\n";
+ print "Template $checkout_path/\n";
+ print $state->{CVSROOT} . "/$module/\n";
+ print "0\n";
# instruct the client that we're checking out to $checkout_path
print "E cvs checkout: Updating $checkout_path\n";
@@ -599,6 +604,43 @@ sub req_co
my %seendirs = ();
my $lastdir ='';
+ # recursive
+ sub prepdir {
+ my ($dir, $repodir, $remotedir, $seendirs) = @_;
+ my $parent = dirname($dir);
+ $dir =~ s|/+$||;
+ $repodir =~ s|/+$||;
+ $remotedir =~ s|/+$||;
+ $parent =~ s|/+$||;
+ $log->debug("announcedir $dir, $repodir, $remotedir" );
+
+ if ($parent eq '.' || $parent eq './') {
+ $parent = '';
+ }
+ # recurse to announce unseen parents first
+ if (length($parent) && !exists($seendirs->{$parent})) {
+ prepdir($parent, $repodir, $remotedir, $seendirs);
+ }
+ # Announce that we are going to modify at the parent level
+ if ($parent) {
+ print "E cvs checkout: Updating $remotedir/$parent\n";
+ } else {
+ print "E cvs checkout: Updating $remotedir\n";
+ }
+ print "Clear-sticky $remotedir/$parent/\n";
+ print "$repodir/$parent/\n";
+
+ print "Clear-static-directory $remotedir/$dir/\n";
+ print "$repodir/$dir/\n";
+ print "Clear-sticky $remotedir/$parent/\n"; # yes, twice
+ print "$repodir/$parent/\n";
+ print "Template $remotedir/$dir/\n";
+ print "$repodir/$dir/\n";
+ print "0\n";
+
+ $seendirs->{$dir} = 1;
+ }
+
foreach my $git ( @{$updater->gethead} )
{
# Don't want to check out deleted files
@@ -606,6 +648,17 @@ sub req_co
( $git->{name}, $git->{dir} ) = filenamesplit($git->{name});
+ if (length($git->{dir}) && $git->{dir} ne './'
+ && $git->{dir} ne $lastdir ) {
+ unless (exists($seendirs{$git->{dir}})) {
+ prepdir($git->{dir}, $state->{CVSROOT} . "/$module/",
+ $checkout_path, \%seendirs);
+ $lastdir = $git->{dir};
+ $seendirs{$git->{dir}} = 1;
+ }
+ print "E cvs checkout: Updating /$checkout_path/$git->{dir}\n";
+ }
+
# modification time of this file
print "Mod-time $git->{modified}\n";
@@ -617,24 +670,10 @@ sub req_co
print "M U $checkout_path/$git->{name}\n";
}
- if (length($git->{dir}) && $git->{dir} ne './'
- && $git->{dir} ne $lastdir && !exists($seendirs{$git->{dir}})) {
-
- # Eclipse seems to need the Clear-sticky command
- # to prepare the 'Entries' file for the new directory.
- print "Clear-sticky $checkout_path/$git->{dir}\n";
- print $state->{CVSROOT} . "/$module/$git->{dir}\n";
- print "Clear-static-directory $checkout_path/$git->{dir}\n";
- print $state->{CVSROOT} . "/$module/$git->{dir}\n";
- print "E cvs checkout: Updating /$checkout_path/$git->{dir}\n";
- $lastdir = $git->{dir};
- $seendirs{$git->{dir}} = 1;
- }
-
- # instruct client we're sending a file to put in this path
- print "Created $checkout_path/" . ( defined ( $git->{dir} ) and $git->{dir} ne "./" ? $git->{dir} . "/" : "" ) . "\n";
+ # instruct client we're sending a file to put in this path
+ print "Created $checkout_path/" . ( defined ( $git->{dir} ) and $git->{dir} ne "./" ? $git->{dir} . "/" : "" ) . "\n";
- print $state->{CVSROOT} . "/$module/" . ( defined ( $git->{dir} ) and $git->{dir} ne "./" ? $git->{dir} . "/" : "" ) . "$git->{name}\n";
+ print $state->{CVSROOT} . "/$module/" . ( defined ( $git->{dir} ) and $git->{dir} ne "./" ? $git->{dir} . "/" : "" ) . "$git->{name}\n";
# this is an "entries" line
print "/$git->{name}/1.$git->{revision}///\n";
--
1.2.4.g09a27-dirty
^ permalink raw reply related
* Producing tar file with 666/777 permissions
From: Matt McCutchen @ 2006-03-04 4:25 UTC (permalink / raw)
To: git
Dear GIT people,
How do I package a git repository in a tar file with 666 and 777
embedded permissions? There's evidently some way to do it because the
Linux kernel source packages have 666 and 777 embedded permissions, but
git-tar-tree gives me a tar file with 644 and 755 permissions and
there's no obvious way to tell it to do otherwise.
There was lots of discussion on the mailing list about what permissions
to preserve when copying in and out of repositories (I obviously side
with those who want a single execute bit), but I could not find any
mention of permission issues in reference to git-tar-tree.
Please reply to me as I am off-list.
--
Matt McCutchen
hashproduct@verizon.net
http://hashproduct.metaesthetics.net/
^ permalink raw reply
* Re: On recording renames
From: Paul Jakma @ 2006-03-04 4:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfylyx3e3.fsf@assigned-by-dhcp.cox.net>
Hi Junio,
On Fri, 3 Mar 2006, Junio C Hamano wrote:
> Recently some people said "I want to tell git that I renamed fileA
> to fileB" on the list and #git channel,
> *1* This is by design, and I am not going to debate if that is a
> good design or not here.
Thanks for your detailed email. Before I continue digesting it, I'd
like to revise my original proposal (having now read the
more of the 'design philosophy'):
- I want to tell git that object A is related to object B between two
trees.
I think at this stage a proof-of-concept would be an idea. I'll try
get back with that before end of the month.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
we just switched to Sprint.
^ permalink raw reply
* On recording renames
From: Junio C Hamano @ 2006-03-04 4:03 UTC (permalink / raw)
To: git; +Cc: paul
Recently some people said "I want to tell git that I renamed
fileA to fileB" on the list and #git channel, and I made some
vague comments on the issue that might have confused people.
This message is to clarify where I stand.
First of all, I understand some people "want to tell git", but
at the same time, I know very well that "git does not even want
to hear". It does not care about names -- it only tracks
contents [*1*].
Having said that, there are at least two cases that renamed
files matter in practice from the end user's point of view.
Diff and merge.
For diff, it is often __very__ frustrating when you know you
renamed hello.c to world.c and then edited just a bit and "git
diff -M hello.c world.c" does not notice. You can do one of two
things to help:
(1) figure out why git (diffcore-rename) does not think they
are similar enough, and improve its similarity estimator.
Some of you who are paying attention to what is in my
"next" branch might have noticed that I have been working
in this area recently.
(2) add a way to tell git-diff-files to compare hello.c in the
index with working tree file world.c:
$ git-diff-files -p 'hello.c->world.c'
And people who "want to tell git" are after the second way.
Although this can probably be implemented as an extension to
diffcore-rename [*2*], I have to say that is kludging around the
real problem. Only as a workaround for pathological cases it
may be OK, but I am really reluctant to accept such a change
without trying avenue (1) first.
About merge. Currently recursive merge strategy claims to
handle renames and I've seen it handle renames well in some
cases. However, it only uses three trees. The rename between
merge base and one head, and the rename between merge base and
the other head are computed, compared and usual three-way merge
rules are applied (e.g. if you kept it there while she moved it
to somewhere else, result is to move it to somewhere else). If
two development tracks forked long time ago are being merged,
and corresponding files deviated from each other beyond
recognition, there is no way for any heuristics to figure out
one is a rename-edit of the other only by looking at these three
trees:
a1--a2--a3--a4--a5--A
/ \
---O---b1--b2--b3--b4--B---*
O has hello.c
a1 renames file hello.c to world.c and a2-a5-A modifies world.c
b1-b4-B modifies hello.c
we are about to merge A and B
comparing O and A may not notice O's hello.c and A's world.c
are similar!
But you are allowed to write a new merge strategy that is more
careful about renames. There is no reason you can only look at
three trees. Such a merge strategy, when given commit A and B,
would walk the history back, running "diff-tree -M" for each
commit along the way, and difference between O's hello.c and
a1's world.c would be hopefully *much* smaller than O's hello.c
and A's world.c -- even the current similarity estimator may
recognize it is a rename.
That is the first thing I'd like to see. I do not want to even
think about recording renames in commit objects before anybody
explores that avenue.
Even with that, if O's hello.c and a1's world.c are _so_
different that if the changes are beyond recognition, you
_might_ want to "tell git" about the rename, or even record such
a rename in the commit object a1. But I personally doubt it
would help anything in practice. After such a huge rewrite
between O->a1, merging between A and B will be very hard anyway,
and you would need some off-line method to extract the intention
of the developer who originally did a1 commit while merging A
and B. And when you inspect that change yourself, you may
decide O's hello.c correspond to a1's world.c yourself. At that
point you will be hand merging the mess, so your being able to tell
git about it would not help you much.
[Footnotes]
*1* This is by design, and I am not going to debate if that is a
good design or not here. There is a "Linus once said 'you say
users know better but users cannot be trusted -- trust me'"
factor involved. I am a trusting kind and somebody needs to
convince me not to trust Linus.
*2* You would supply "in what you are comparing, the source path
hello.c and destination path world.c are similar with similarity
index 80% -- do not bother to estimate yourself, I am telling
you their similarity index so trust me".
$ git-diff-files -p -M --similarity='hello.c world.c 80%'
^ permalink raw reply
* Re: [PATCH] diff-delta: bound hash list length to avoid O(m*n) behavior
From: Nicolas Pitre @ 2006-03-04 3:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfylzx7t3.fsf@assigned-by-dhcp.cox.net>
On Fri, 3 Mar 2006, Junio C Hamano wrote:
> In short, I'd love to get a tighter packing, but as it
> currently stands, I do not think 5% resulting packsize reduction
> warrants making 100% slower operation the default.
Agreed. Please just drop that one patch for now.
I'll rework the hash limiting patch so the 16-byte block version behaves
better with the large 20MB files.
Nicolas
^ permalink raw reply
* Re: [PATCH] diff-delta: bound hash list length to avoid O(m*n) behavior
From: Junio C Hamano @ 2006-03-04 2:39 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <7vfylzx7t3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> The first round. The set of objects packed were from
> today's Linus tip (everything down to epoch v2.6.12-rc2), 193309
> objects in total, on my Duron 750 with slow disks.
>
> real user sys bytes savings
> master 11m17.121s 10m23.280s 0m47.290s 109045599 N/A
> nico 25m37.058s 23m0.770s 2m20.460s 104401392 4.25%
> jc 24m12.072s 21m45.120s 2m16.400s 104409761 4.25%
Minor correction in numbers. The size for nico and jc are
swapped. jc variant created the smallest pack in this
experiment.
Which puzzles me even more...
^ permalink raw reply
* Re: [PATCH] diff-delta: bound hash list length to avoid O(m*n) behavior
From: Junio C Hamano @ 2006-03-04 2:28 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <7vbqwrq4yi.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>> These numbers are misleading.
>>
>> The 36K objects pack I used in my previous tests gives 9971223
>> (from "next" branch) vs 9664546 (this patch) final pack size.
>> The wallclock time on my machine is 1m35 vs 3m30. I doubt many
>> people are willing to pay 100% more waiting time for 3% tighter
>> pack.
I started to suspect that the above benchmark was
unreliable, because I do not know how the original linux-2.6
repository I used for my testing were packed, and I was letting
the delta reusing to do its thing, so the times were probably
off (the 3-byte finer grained deltifier would have spent a lot
more time during the initial packing) and the result size were
too (the finer grained one would have packed things a lot more
tightly if the delta it was allowed to reuse was made by itself,
not by the old one).
So I tried a fresh packing without reusing delta at all,
with three variants: the original 16-byte one (master), 3-byte
finer grained one with your hash limit (nico), and 3-byte finer
grained one with my more aggressive hash limit (jc). The
benchmark is not meant to be scientific, but to see how well it
serves the kernel community ;-).
The first round. The set of objects packed were from
today's Linus tip (everything down to epoch v2.6.12-rc2), 193309
objects in total, on my Duron 750 with slow disks.
real user sys bytes savings
master 11m17.121s 10m23.280s 0m47.290s 109045599 N/A
nico 25m37.058s 23m0.770s 2m20.460s 104401392 4.25%
jc 24m12.072s 21m45.120s 2m16.400s 104409761 4.25%
My hack does not change things much in the overall picture
compared to yours, although it does cut down runtime by about
5%. We can immediately see that finer grained ones are
significantly more expensive than the original loose one either
way.
The next round of test is to place the "full pack"
generated in the previous experiment in .git/objects/pack and
generate packs by reusing delta. When testing the "master"
version, I move the pack produced above with "master" under
.git/objects/pack, and run this to emulate pack generation for
downloader who has v2.6.14 and wants v2.6.15-rc1 (the same 36K
objects test I did previously):
git rev-list --objects-edge v2.6.14..v2.6.15-rc1 |
time git-pack-objects --stdout | wc -c
When switching to test "nico" deltifier implementation, I start
with the full pack generated by "nico" in .git/object/pack to
make comparison fair. Here is the result:
real user sys bytes savings
master 1m37.703s 1m28.970s 0m5.860s 9968386 N/A
nico 3m39.982s 3m24.420s 0m14.380s 9182761 7.88%
jc 3m0.434s 2m35.940s 0m13.730s 9139460 8.31%
In thin transfer, base object is omitted, so the generated pack
has higher delta to non-delta ratio than usual -- and that is
the reason we see much more savings. Still, we are paying quite
a lot of overhead by finer grained delta code.
The last test is not to do a thin pack but still reusing
delta. This is to emulate "git repack" performance. Again, I
had the matching pack in .git/objects/pack to make the
compararison fair:
git rev-list --objects v2.6.14..v2.6.15-rc1 |
time git-pack-objects --stdout | wc -c
And here is the result:
real user sys bytes savings
master 1m0.866s 0m57.590s 0m2.810s 34601417 N/A
nico 2m8.059s 2m0.360s 0m6.350s 33888419 2.06%
jc 1m49.894s 1m42.250s 0m6.780s 33838262 2.20%
This one is not getting much savings compared to the full pack
case, but still spending about twice the time.
In short, I'd love to get a tighter packing, but as it
currently stands, I do not think 5% resulting packsize reduction
warrants making 100% slower operation the default. And the
experiment I did does not account for the memory pressure the
new delitifier imposes us (two pointers per every byte of source
material -- it could be reduced to one pointer though), so when
we start talking about huge files I am not sure we can manage to
keep the runtime reasonably low.
It maybe is an option to have a flag to tell "I want a
lot tighter pack made; you can spend all the time while I am
sleeping" and switch between two deltifiers, but otherwise...
One thing I do not understand is why my patch improves
the compressed result size. The patch was primarily to brutally
pessimize the selection of "copied from source" to avoid the
corner case performance problems, so I would understand why it
is faster than yours, but I expected it to *always* create a
looser pack. I am puzzled.
Swapping window scan order is orthogonal to this, so
maybe we could do it first and make it work, then start reusing
the refindex to see how well things improve. But we should be
reminded of the recent report that pack-object ran out of space
even with the current code that does not reuse the refindex when
packing 8 huge objects X-<.
^ permalink raw reply
* [PATCH] Use Cogito when possible in the "tutorial" test.
From: Pavel Roskin @ 2006-03-04 1:23 UTC (permalink / raw)
To: git, Petr Baudis
In particular, use Cogito branch support. Document why git has to be
used in some places.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
Documentation/tutorial-script/script.sh | 29 +++++++++++++++++------------
1 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/Documentation/tutorial-script/script.sh b/Documentation/tutorial-script/script.sh
index edcebda..4d6b732 100755
--- a/Documentation/tutorial-script/script.sh
+++ b/Documentation/tutorial-script/script.sh
@@ -1,8 +1,9 @@
#!/bin/bash
#
-# FIXME: This script has many GITisms. Some of them are unnecessary, while
-# some stem from missing Cogito features (especially no support for pushing
-# tags, and consequently no support for remotes/).
+# FIXME: This script has some GITisms. They stem from missing Cogito
+# features, such as exporting patches to mbox format, applying patches
+# from e-mail, merging multiple tags at once, verifying signed tags and
+# repacking the repository.
# This function is appended as "&& should_fail" to commands which should
@@ -34,7 +35,7 @@ cd $ALICE
tar xf $TOP/0001-alice.tar
cd rpn
-# Being a tidy girl, she places it under git
+# Being a tidy girl, she places it under Cogito
echo "Alice's first version" | cg-init
cg-tag -d "First ever version of RPN" rpn-0.1
@@ -108,8 +109,8 @@ cg-export ../rpn-0.3.tar.bz2
### Bob tells Alice of his changes, Alice prepares to get them.
cd $ALICE/rpn
-git checkout -b bob
-git branch
+cg-switch -r master bob
+cg-status -g
# Alice needs to register his remote branch
cg-branch-add bobswork $BOB/rpn
@@ -163,14 +164,16 @@ cg-commit -m "Add proper header file for
-m "Update dependencies in Makefile"
# Charlie emails the patch to Alice:
+# cg-mkpatch -d .. -r rpn-0.3..master
git format-patch -o .. --mbox --signoff -r rpn-0.3
- # Result is in $TOP/0014-charlie-email
+# Only git can create mbox formatted output
+# Compare the result to 0014-charlie-email
### Alice is busy meanwhile...
cd $ALICE/rpn
-git checkout master
+cg-switch master
patch -p1 -i $TOP/0015-alice-mod.patch
@@ -189,21 +192,23 @@ cg-push public
### Alice gets Charlie's fix, creates a new branch for his changes
cd $ALICE/rpn
-git checkout master
-git checkout -b charlie rpn-0.3
-git branch
+cg-switch -r rpn-0.3 charlie
+cg-status -g
+# Check what's inside the patch. There is no Cogito equivalent yet.
git apply --stat $TOP/0014-charlie-email
git apply --summary $TOP/0014-charlie-email
git apply --check $TOP/0014-charlie-email
# Everything looks OK
git applymbox $TOP/0014-charlie-email
+# This doesn't work well yet
+# cg-patch < $TOP/0014-charlie-email
### Alice integrates the changes in the branches for the next release
cd $ALICE/rpn
-git checkout master
+cg-switch master
# Alice tries "git merge" instead of "cg-merge" since she wanted to
# merge both branches at once, which "cg-merge" cannot do.
git merge "Integrate changes from Bob and Charlie" master bob charlie \
^ permalink raw reply related
* Re: git-repack && git-prune-packed isn't doing it's job anymore?
From: Martin Langhoff @ 2006-03-04 1:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64mv2for.fsf@assigned-by-dhcp.cox.net>
On 3/4/06, Junio C Hamano <junkio@cox.net> wrote:
> If that is the case, "git prune" would be the right tool to use.
Spot on. Thanks!
> And this is not something that changed recently.
Of course, my bad. I had not seen this before. I guess it was because
I hadn't actually paid much attention at leftover objects in
oft-rebased repositories. I used to look at the .git/objects directory
a lot in my early git days, when I didn't do any rebasing.
thanks again!
martin
^ permalink raw reply
* Re: git-repack && git-prune-packed isn't doing it's job anymore?
From: Junio C Hamano @ 2006-03-04 0:53 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90603031629qbbb287ckd8da1ef56a831dba@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> $ find .git/objects -type f | grep -v pack | wc -l
> 3297
> $ git-repack && git-prune-packed
> Generating pack...
> Done counting 664 objects.
> Deltifying 664 objects.
> 100% (664/664) done
> Writing 664 objects.
> 100% (664/664) done
> Total 664, written 664 (delta 384), reused 0 (delta 0)
> Pack pack-f38c51a5d5194d6a2f6e711586b9a51980c8d524 created.
> $ find .git/objects -type f | grep -v pack | wc -l
> 2583
The last one would be "git count-objects", but repack packs
things that are reachable from your refs and prune-packed
removes what are in packs, so perhaps these are unreachable
objects? I'd imagine fsck-objects would say they are dangling.
If that is the case, "git prune" would be the right tool to use.
And this is not something that changed recently.
^ permalink raw reply
* git-repack && git-prune-packed isn't doing it's job anymore?
From: Martin Langhoff @ 2006-03-04 0:29 UTC (permalink / raw)
To: Git Mailing List
$ find .git/objects -type f | grep -v pack | wc -l
3297
$ git-repack && git-prune-packed
Generating pack...
Done counting 664 objects.
Deltifying 664 objects.
100% (664/664) done
Writing 664 objects.
100% (664/664) done
Total 664, written 664 (delta 384), reused 0 (delta 0)
Pack pack-f38c51a5d5194d6a2f6e711586b9a51980c8d524 created.
$ find .git/objects -type f | grep -v pack | wc -l
2583
Strange! This is from todays master,
$ git --version
git version 1.2.4.g0a60
cheers,
martin
^ permalink raw reply
* Re: bug?: stgit creates (unneccessary?) conflicts when pulling
From: Catalin Marinas @ 2006-03-03 22:07 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20060303142413.GB16456@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> On 2006-02-28 22:45:56 +0000, Catalin Marinas wrote:
>>I attached another patch that should work properly. It also pushes
>>empty patches on the stack if they were merged upstream (a 'stg
>>clean' is required to remove them). This is useful for the push
>>--undo command if you are not happy with the result.
>
> It appears to work for me. I still had to fix things up manually when
> pulling the uncommit patch though, since you had made a minor change
> in "uncommit.py":
>
> Pushing patch "uncommit"...Error: File "stgit/commands/uncommit.py" added in branches but different
Yes, I made some minor modifications (one of them was the copyright).
> Is there a way to make stgit not fall on its face when faced with this
> situation? Surely it ought to be possible to create a merged file with
> conflict markers? (I realize this is harder when there is no common
> ancestor, but these files are 95% identical!)
I've been thinking about this but it's not straight-forward. I tried
using /dev/null as the common ancestor but both diff3 and wiggle put the
whole file text in the conflict regions. These tools are not smart
enough to compare the conflict regions and reduce them.
Another approach would be to have a script that creates the common
ancestor only with the common lines between the two files and pass this
file as an argument to diff3. This wouldn't probably be that difficult,
maybe some combination of diff and sed and apply the result to one of
the files to remove the diff'ed lines.
Catalin
^ permalink raw reply
* Re: bug?: stgit creates (unneccessary?) conflicts when pulling
From: Catalin Marinas @ 2006-03-03 21:57 UTC (permalink / raw)
To: git
In-Reply-To: <20060303141329.GA16456@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> We could perhaps do a little better. Instead of just noting whether
> the patch vanishes when reverse-applied, save the top and bottom of
> the patch as reverse-applied, and then replace the patch with the
> reverse of that. If the patch vanishes, this does what your patch does
> right now. If the patch does not vanish, all that remains is the parts
> that upstream didn't accept. (And as before, if the patch didn't
> reverse-apply cleanly, assume upstream hasn't accepted it at all yet.)
I don't fully understand this. If a patch reverse-applies cleanly, it
means that it was fully merged upstream. If it wasn't fully merged,
direct applying would fail and we should fall back to a three-way merge.
I'm not sure whether the latter would cause conflicts or not. The
disadvantage would be more time spent with trying two types of merges.
Anyway, I'll push the current patch but remain open to improvements. If
you get something working with your idea, please post a patch.
Catalin
^ permalink raw reply
* [PATCH] contrib/git-svn: fix a copied-tree bug in an overzealous assertion
From: Eric Wong @ 2006-03-03 21:35 UTC (permalink / raw)
To: Junio C Hamano, git list
I thought passing --stop-on-copy to svn would save us from all
the trouble svn-arch-mirror had with directory (project) copies.
I was wrong, there was one thing I overlooked.
If a tree was moved from /foo/trunk to /bar/foo/trunk with no
other changes in r10, but the last change was done in r5, the
Last Changed Rev (from svn info) in /bar/foo/trunk will still be
r5, even though the copy in the repository didn't exist until
r10.
Now, if we ever detect that the Last Changed Rev isn't what
we're expecting, we'll run svn diff and only croak if there are
differences between them.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
35f4b65079f730e7413b8b585e44526e489e8b1c
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index 25d2935..c575883 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -337,10 +337,17 @@ sub assert_svn_wc_clean {
my ($svn_rev, $treeish) = @_;
croak "$svn_rev is not an integer!\n" unless ($svn_rev =~ /^\d+$/);
croak "$treeish is not a sha1!\n" unless ($treeish =~ /^$sha1$/o);
- my $svn_info = svn_info('.');
- if ($svn_rev != $svn_info->{'Last Changed Rev'}) {
- croak "Expected r$svn_rev, got r",
- $svn_info->{'Last Changed Rev'},"\n";
+ my $lcr = svn_info('.')->{'Last Changed Rev'};
+ if ($svn_rev != $lcr) {
+ print STDERR "Checking for copy-tree ... ";
+ # use
+ my @diff = grep(/^Index: /,(safe_qx(qw(svn diff),
+ "-r$lcr:$svn_rev")));
+ if (@diff) {
+ croak "Nope! Expected r$svn_rev, got r$lcr\n";
+ } else {
+ print STDERR "OK!\n";
+ }
}
my @status = grep(!/^Performing status on external/,(`svn status`));
@status = grep(!/^\s*$/,@status);
--
1.2.4.g198d
^ permalink raw reply related
* Re: [PATCH 1/3] cg-mv doesn't work with bash 3.1.7 due to excessive quotes
From: Josef Weidendorfer @ 2006-03-03 16:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git, Petr Baudis
In-Reply-To: <7vbqwo3xo4.fsf@assigned-by-dhcp.cox.net>
On Friday 03 March 2006 06:27, you wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
> > - ARGS2["${#ARGS2[@]}"]="$_git_relpath${arg%/}"
> > + ARGS2[${#ARGS2[@]}]="$_git_relpath${arg%/}"
>
> Is this an application bug? It looks like a workaround for a
> bug in the shell...
This line in cg-mv is needed to work around at least two
bugs in git-mv:
* "git-mv a/ b/" not working.
Fix was to strip all trailing slashes of args (fixed in 1.2.4)
* "cd subdir; git-mv ../file ."
Fix is to run git-mv from base directory (see separate patch for git-mv)
I think cg-mv should be able to be a direct wrapper for git-mv with
the next maintenance release.
Pasky: do you know of other problems with git-mv?
Josef
^ permalink raw reply
* [PATCH] git-mv: fix moves into a subdir from outside
From: Josef Weidendorfer @ 2006-03-03 16:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
git-mv needs to be run from the base directory so that
the check if a file is under revision also covers files
outside of a subdirectory. Previously, e.g. in the git repo,
cd Documentation; git-mv ../README .
produced the error
Error: '../README' not under version control
The test is extended for this case; it previously only tested
one direction.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---
git-mv.perl | 8 ++++++++
t/t7001-mv.sh | 18 ++++++++++++++++--
2 files changed, 24 insertions(+), 2 deletions(-)
08d21abe95064934ea559b88801415e09b19f628
diff --git a/git-mv.perl b/git-mv.perl
index f3e859a..0a63860 100755
--- a/git-mv.perl
+++ b/git-mv.perl
@@ -62,9 +62,17 @@ else {
$dstDir = "";
}
+my $subdir_prefix = `git rev-parse --show-prefix`;
+chomp($subdir_prefix);
+
+# run in git base directory, so that git-ls-files lists all revisioned files
+chdir "$GIT_DIR/..";
+
# normalize paths, needed to compare against versioned files and update-index
# also, this is nicer to end-users by doing ".//a/./b/.//./c" ==> "a/b/c"
for (@srcArgs, @dstArgs) {
+ # prepend git prefix as we run from base directory
+ $_ = $subdir_prefix.$_;
s|^\./||;
s|/\./|/| while (m|/\./|);
s|//+|/|g;
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index 43d74c5..811a479 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -11,17 +11,31 @@ test_expect_success \
git-commit -m add -a'
test_expect_success \
- 'moving the file' \
+ 'moving the file out of subdirectory' \
'cd path0 && git-mv COPYING ../path1/COPYING'
# in path0 currently
test_expect_success \
'commiting the change' \
- 'cd .. && git-commit -m move -a'
+ 'cd .. && git-commit -m move-out -a'
test_expect_success \
'checking the commit' \
'git-diff-tree -r -M --name-status HEAD^ HEAD | \
grep -E "^R100.+path0/COPYING.+path1/COPYING"'
+test_expect_success \
+ 'moving the file back into subdirectory' \
+ 'cd path0 && git-mv ../path1/COPYING COPYING'
+
+# in path0 currently
+test_expect_success \
+ 'commiting the change' \
+ 'cd .. && git-commit -m move-in -a'
+
+test_expect_success \
+ 'checking the commit' \
+ 'git-diff-tree -r -M --name-status HEAD^ HEAD | \
+ grep -E "^R100.+path1/COPYING.+path0/COPYING"'
+
test_done
--
1.2.0.g719b
^ permalink raw reply related
* Re: [PATCH] Add --temp and --stage=all options to checkout-index.
From: Shawn Pearce @ 2006-03-03 15:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzg83xro.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Unfortunately this change lead me down a path which changed the core
> > checkout code also used by apply and read-tree.
>
> ... which makes it much harder to swallow without careful
> inspection X-<.
>
> I think the patch only appears much bigger than it actually is,
> because of reindentation effect coming from "if (to-temp-file)".
> However, I am too tired to carefully examine them tonight, so I
> hope you do not mind my postponing this for now.
Not at all. I read over the diff before sending it and thought it
made the patch look much worse than it really is, simply because
of the reindentation. :-|
Sometimes good 'ole diff ain't that great for conveying a change.
--
Shawn.
^ permalink raw reply
* Re: bug?: stgit creates (unneccessary?) conflicts when pulling
From: Karl Hasselström @ 2006-03-03 14:24 UTC (permalink / raw)
To: git
In-Reply-To: <b0943d9e0602281445w7160d915y@mail.gmail.com>
On 2006-02-28 22:45:56 +0000, Catalin Marinas wrote:
> On 27/02/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
>
> > An idea (untested, I don't even know whether it's feasible) would
> > be to check which patches were merged by reverse-applying them
> > starting with the last. In this situation, all the merged patches
> > should just revert their changes. You only need to do a git-diff
> > between the bottom and the top of the patch and git-apply the
> > output (maybe without even modifying the tree). If this operation
> > succeeds, the patch was integrated and you don't even need to push
> > it.
>
> I attached another patch that should work properly. It also pushes
> empty patches on the stack if they were merged upstream (a 'stg
> clean' is required to remove them). This is useful for the push
> --undo command if you are not happy with the result.
>
> I'll try this patch for a bit more before pushing into the
> repository.
It appears to work for me. I still had to fix things up manually when
pulling the uncommit patch though, since you had made a minor change
in "uncommit.py":
Pushing patch "uncommit"...Error: File "stgit/commands/uncommit.py" added in branches but different
Is there a way to make stgit not fall on its face when faced with this
situation? Surely it ought to be possible to create a merged file with
conflict markers? (I realize this is harder when there is no common
ancestor, but these files are 95% identical!)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: bug?: stgit creates (unneccessary?) conflicts when pulling
From: Karl Hasselström @ 2006-03-03 14:13 UTC (permalink / raw)
To: git
In-Reply-To: <b0943d9e0603010953iccf64a4v@mail.gmail.com>
On 2006-03-01 17:53:53 +0000, Catalin Marinas wrote:
> This won't solve the problem since testing whether patch "a" was
> merged upstream will fail because its reverse won't apply cleanly
> onto the upstream HEAD. Of course, you can try combination of
> upstream commits and local patches but it's not really feasible.
>
> As I said, this method doesn't solve all the upstream merge
> situations but it is OK for most of them.
We could perhaps do a little better. Instead of just noting whether
the patch vanishes when reverse-applied, save the top and bottom of
the patch as reverse-applied, and then replace the patch with the
reverse of that. If the patch vanishes, this does what your patch does
right now. If the patch does not vanish, all that remains is the parts
that upstream didn't accept. (And as before, if the patch didn't
reverse-apply cleanly, assume upstream hasn't accepted it at all yet.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 1/3] cg-mv doesn't work with bash 3.1.7 due to excessive quotes
From: Pavel Roskin @ 2006-03-03 14:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqwo3xo4.fsf@assigned-by-dhcp.cox.net>
On Thu, 2006-03-02 at 21:27 -0800, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
> > - ARGS2["${#ARGS2[@]}"]="$_git_relpath${arg%/}"
> > + ARGS2[${#ARGS2[@]}]="$_git_relpath${arg%/}"
>
> Is this an application bug? It looks like a workaround for a
> bug in the shell...
Indeed, bash 3.00.16 (FC4) is fine with the original cg-mv. On the
other hand, bash 3.1.7 (FC development) doesn't even like this:
$ arg["0"]=0
bash: "0": syntax error: operand expected (error token is ""0"")
I don't see any relevant information in the NEWS file, so even if it's
no a bug, it's an undocumented feature :-)
Anyway, the quotes are excessive, bash is (sort of) correct to complain
about it, and I don't see any other instances of quoting array arguments
in cogito.
The quotes in question have always existed in cg-mv, they were not added
to work around anything.
--
Regards,
Pavel Roskin
^ permalink raw reply
* workaround fat/ntfs deficiencies for t3600-rm.sh (git-rm)
From: Alex Riesen @ 2006-03-03 10:20 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Carl Worth
[-- Attachment #1: Type: text/plain, Size: 243 bytes --]
Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
---
chmod u-w and even chmod a-w dont work on fat and ntfs.
The actually do something, but rm a file from that directory
will succeed anyway. That's windows permission model to you...
[-- Attachment #2: 0001-workaround-fat-ntfs-deficiencies-for-t3600-rm.sh-git-rm.txt --]
[-- Type: text/plain, Size: 1900 bytes --]
>From nobody Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Fri Mar 3 11:15:05 2006 +0100
Subject: workaround fat/ntfs deficiencies for t3600-rm.sh (git-rm)
---
t/t3600-rm.sh | 23 +++++++++++++++++------
1 files changed, 17 insertions(+), 6 deletions(-)
583a9faeab3a200fc970577458b7827d86aa7df1
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index cabfadd..d1947e1 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -8,11 +8,20 @@ test_description='Test of the various op
. ./test-lib.sh
# Setup some files to be removed, some with funny characters
-touch -- foo bar baz 'space embedded' 'tab embedded' 'newline
-embedded' -q
-git-add -- foo bar baz 'space embedded' 'tab embedded' 'newline
-embedded' -q
-git-commit -m "add files"
+touch -- foo bar baz 'space embedded' -q
+git-add -- foo bar baz 'space embedded' -q
+git-commit -m "add normal files"
+test_tabs=y
+if touch -- 'tab embedded' 'newline
+embedded'
+then
+git-add -- 'tab embedded' 'newline
+embedded'
+git-commit -m "add files with tabs and newlines"
+else
+ say 'Your filesystem does not allow tabs in filenames.'
+ test_tabs=n
+fi
test_expect_success \
'Pre-check that foo exists and is in index before git-rm foo' \
@@ -42,16 +51,18 @@ test_expect_success \
'Test that "git-rm -- -q" succeeds (remove a file that looks like an option)' \
'git-rm -- -q'
-test_expect_success \
+test "$test_tabs" = y && test_expect_success \
"Test that \"git-rm -f\" succeeds with embedded space, tab, or newline characters." \
"git-rm -f 'space embedded' 'tab embedded' 'newline
embedded'"
+if test "$test_tabs" = y; then
chmod u-w .
test_expect_failure \
'Test that "git-rm -f" fails if its rm fails' \
'git-rm -f baz'
chmod u+w .
+fi
test_expect_success \
'When the rm in "git-rm -f" fails, it should not remove the file from the index' \
--
1.2.4.ga091
^ permalink raw reply related
* [PATCH] send-email: accept --no-signed-off-by-cc as the documentation states
From: Eric Wong @ 2006-03-03 9:28 UTC (permalink / raw)
To: junkio, ryan; +Cc: git, Eric Wong
--no-signed-off-cc is still supported, for backwards compatibility
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-send-email.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
374f3e5c7fd49c4949df9b29ed03287e6ceb2e2c
diff --git a/git-send-email.perl b/git-send-email.perl
index b0d095b..7c8d512 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -54,7 +54,7 @@ my $rc = GetOptions("from=s" => \$from,
"compose" => \$compose,
"quiet" => \$quiet,
"suppress-from" => \$suppress_from,
- "no-signed-off-cc" => \$no_signed_off_cc,
+ "no-signed-off-cc|no-signed-off-by-cc" => \$no_signed_off_cc,
);
# Now, let's fill any that aren't set in with defaults:
--
1.2.3.g4676
^ permalink raw reply related
* [PATCH 8/9] contrib/git-svn: add --id/-i=$GIT_SVN_ID command-line switch
From: Eric Wong @ 2006-03-03 9:20 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <11413776092493-git-send-email-normalperson@yhbt.net>
I ended up using GIT_SVN_ID far more than I ever thought I
would. Typing less is good.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 19 +++++++++++--------
1 files changed, 11 insertions(+), 8 deletions(-)
1d3dc63f7ed276863c71f9a212471658f359ef75
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index 041791b..db199a3 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -10,13 +10,6 @@ use vars qw/ $AUTHOR $VERSION
$AUTHOR = 'Eric Wong <normalperson@yhbt.net>';
$VERSION = '0.10.0';
$GIT_DIR = $ENV{GIT_DIR} || "$ENV{PWD}/.git";
-$GIT_SVN = $ENV{GIT_SVN_ID} || 'git-svn';
-$GIT_SVN_INDEX = "$GIT_DIR/$GIT_SVN/index";
-$ENV{GIT_DIR} ||= $GIT_DIR;
-$SVN_URL = undef;
-$REV_DIR = "$GIT_DIR/$GIT_SVN/revs";
-$SVN_WC = "$GIT_DIR/$GIT_SVN/tree";
-
# make sure the svn binary gives consistent output between locales and TZs:
$ENV{TZ} = 'UTC';
$ENV{LC_ALL} = 'C';
@@ -78,7 +71,17 @@ foreach (keys %cmd) {
my %opts;
%opts = %{$cmd{$cmd}->[2]} if (defined $cmd);
-GetOptions(%opts, 'help|H|h' => \$_help, 'version|V' => \$_version ) or exit 1;
+GetOptions(%opts, 'help|H|h' => \$_help,
+ 'version|V' => \$_version,
+ 'id|i=s' => \$GIT_SVN) or exit 1;
+
+$GIT_SVN ||= $ENV{GIT_SVN_ID} || 'git-svn';
+$GIT_SVN_INDEX = "$GIT_DIR/$GIT_SVN/index";
+$ENV{GIT_DIR} ||= $GIT_DIR;
+$SVN_URL = undef;
+$REV_DIR = "$GIT_DIR/$GIT_SVN/revs";
+$SVN_WC = "$GIT_DIR/$GIT_SVN/tree";
+
usage(0) if $_help;
version() if $_version;
usage(1) unless defined $cmd;
--
1.2.3.g4676
^ permalink raw reply related
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