* Re: win2k/cygwin cannot handle even moderately sized packs
From: Johannes Schindelin @ 2006-11-13 12:45 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0611070302h50541cd5mf0758afe0d6befda@mail.gmail.com>
Hi,
On Tue, 7 Nov 2006, Alex Riesen wrote:
> For me, it fails even on 332Mb pack:
>
> $ git reset --hard 61bb7fcb
> fatal: packfile .git/objects/pack/pack-ad37...pack cannot be mapped.
>
> Instrumenting the code reveals that it fails on 348876870 bytes.
> Strangely enough, a cygwin program which just reads that pack
> many times without freeing the mem goes up to 1395507480 (1330Mb).
>
> If I replace the malloc (cygwin) with native VirtualAlloc(MEM_COMMIT)
> it reports that "Not enough storage is available to process this command",
> which is just ENOMEM, I think.
This looks to me as if you have NO_MMAP=1 set in your Makefile (which I
also do automatically when compiling on cygwin).
The old problem: Windows does not have fork.
<digression> And before somebody starts cygwin bashing: don't. It is not
cygwin's problem, it is Windows'. The cygwin people worked long and hard
on something truly useful, and it helps me _every_ time I have to work on
a Windows platform (which _is_ utter crap). Some problems of Windows are
so unhideable though, that even cygwin cannot work around them.
</digression>
Cygwin provides a mmap(), which works remarkably well even with the
emulated fork(), but one thing is not possible: since mmap()ed files
have to be _reopened_ after a fork(), and git uses the
open-temp-file-then-delete-it-but-continue-to-use-it paradigm quite often,
we work around it by setting NO_MMAP=1. Again, this is _not_ Cygwin's
fault!
And I think that a mmap() of 332MB would not fail.
Long time ago (to be precise, July 18th), Linus suggested (in Message-Id:
<Pine.LNX.4.64.0607180837260.3386@evo.osdl.org>) to find out which mmap()
calls are _not_ used before a fork(), and not emulate them by malloc().
I never came around to do that, but maybe others do?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Catch errors when writing an index that contains invalid objects.
From: Johannes Sixt @ 2006-11-13 13:50 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt
In-Reply-To: <11634257784001-git-send-email-j.sixt@eudaptics.com>
From: Johannes Sixt <johannes.sixt@telecom.at>
If git-write-index is called without --missing-ok, it reports invalid
objects that it finds in the index. But without this patch it dies
right away or may run into an infinite loop.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
cache-tree.c | 2 ++
t/t0000-basic.sh | 22 ++++++++++++++++++++++
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/cache-tree.c b/cache-tree.c
index a803262..9b73c86 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -282,6 +282,8 @@ static int update_one(struct cache_tree
baselen + sublen + 1,
missing_ok,
dryrun);
+ if (subcnt < 0)
+ return subcnt;
i += subcnt - 1;
sub->used = 1;
}
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index 2c9bbb5..6aff0b8 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -209,6 +209,28 @@ test_expect_success \
'validate object ID for a known tree.' \
'test "$ptree" = 3c5e5399f3a333eddecce7a9b9465b63f65f51e2'
+cat >badobjects <<EOF
+100644 blob 1000000000000000000000000000000000000000 dir/file1
+100644 blob 2000000000000000000000000000000000000000 dir/file2
+100644 blob 3000000000000000000000000000000000000000 dir/file3
+100644 blob 4000000000000000000000000000000000000000 dir/file4
+100644 blob 5000000000000000000000000000000000000000 dir/file5
+EOF
+
+rm .git/index
+test_expect_success \
+ 'put invalid objects into the index.' \
+ 'git-update-index --index-info < badobjects'
+
+test_expect_failure \
+ 'writing this tree without --missing-ok.' \
+ 'git-write-tree'
+
+test_expect_success \
+ 'writing this tree with --missing-ok.' \
+ 'git-write-tree --missing-ok'
+
+
################################################################
rm .git/index
test_expect_success \
--
1.4.1.rc1.g47e5
^ permalink raw reply related
* [PATCH] test-lib.sh: A command dying due to a signal is an unexpected failure.
From: Johannes Sixt @ 2006-11-13 13:50 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt
From: Johannes Sixt <johannes.sixt@telecom.at>
When test_expect_failure detects that a command failed, it still has to
treat a program that crashed from a signal as unexpected failure.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
t/test-lib.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 07cb706..3895f16 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -129,7 +129,7 @@ test_expect_failure () {
error "bug in the test script: not 2 parameters to test-expect-failure"
say >&3 "expecting failure: $2"
test_run_ "$2"
- if [ "$?" = 0 -a "$eval_ret" != 0 ]
+ if [ "$?" = 0 -a "$eval_ret" != 0 -a "$eval_ret" -lt 129 ]
then
test_ok_ "$1"
else
--
1.4.1.rc1.g47e5
^ permalink raw reply related
* Re: Non-ASCII paths and git-cvsserver
From: sf @ 2006-11-13 13:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Langhoff
In-Reply-To: <7vvelnjd4p.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> sf <sf@b-i-t.de> writes:
>
>> I want to access a git repository via git-cvsserver. The problem is
>> that the repository contains paths with umlauts. These paths come out
>> quoted and escaped when checked out with cvs.
>
> I think this is because the cvsserver invokes diff-tree and
> ls-tree without -z and the output from these command quote
> non-ascii letters as unsafe.
I knew I had seen that kind of quoting before but right then I thought
it was related to Perl or SQLite.
> Martin's sqlite may probably be needed as well, but regardless
> of that something like this patch is needed -- otherwise what
> populates sqlite database will be quoted to begin with so it
> would not help much.
Martin, are you sure your patch is needed? (see below)
> I've tested with your reproduction recipe, but otherwise not
> tested this patch.
Thanks, Junio. Paths with umlauts are returned correctly now both in
UTF-8 and ISO-8859-1. I guess git-cvsserver is now as encoding agnostic
as git core.
Regards
^ permalink raw reply
* Re: Non-ASCII paths and git-cvsserver
From: Jakub Narebski @ 2006-11-13 14:20 UTC (permalink / raw)
To: git
In-Reply-To: <45587A09.3020605@b-i-t.de>
sf wrote:
> Thanks, Junio. Paths with umlauts are returned correctly now both in
> UTF-8 and ISO-8859-1. I guess git-cvsserver is now as encoding agnostic
> as git core.
By the way, now that git has per user config file, ~/.gitconfig, perhaps
it is time to add i18n.filesystemEncoding configuration variable, to
automatically convert between filesystem encoding (somthing you usually
don't have any control over) and UTF-8 encoding of paths in tree objects.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* directory is not in cache
From: Michael S. Tsirkin @ 2006-11-13 14:47 UTC (permalink / raw)
To: git
Hi!
I tried to check out a directory from a branch:
$ git-ls-tree --name-only demo_branch
drivers/infiniband/
drivers/infiniband/Kconfig
drivers/infiniband/Makefile
drivers/infiniband/core
drivers/infiniband/hw
drivers/infiniband/ulp
$ git checkout demo_branch
drivers/infiniband/
git-checkout-index: drivers/infiniband/ is not in the cache
$ git --version
git version 1.4.2.3.g128e
--
^ permalink raw reply
* Re: Getting new branches from remote repo.
From: Matthias Hopf @ 2006-11-13 16:57 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Junio C Hamano, Alexander Litvinov, git
In-Reply-To: <20061113091736.GA31693@diana.vm.bytemark.co.uk>
On Nov 13, 06 10:17:36 +0100, Karl Hasselström wrote:
> > > I have a trouble I don't know how to solve. When I am cloning
> > > remote repo I automatically get all it's branches stored at my
> > > repo (they are listed at .git/remotes/origin). When someone adds
> > > new branch(es) to remote repo git pull (git fetch) does not
> > > automatically add them to my repo. I have a tool to list all
> > > remote branches (git ls-remote --heads origin) but I can't find
> > > how to add interesting (or all) branches to by repo.
> >
> > After finding out $that_new_branch's name, add either
> > Pull: refs/heads/$that_new_branch:refs/heads/$that_new_branch
> > or if you are in "separate remote" school, then perhaps
> > Pull: refs/heads/$that_new_branch:refs/remotes/origin/$that_new_branch
> > to .git/remotes/origin and running git fetch would give you what you
> > want, I think.
>
> There really should be a flag to make git fetch do this job. And if we
> use separate remotes, the flag should probably default to "on".
This was an issue I stumbled upon recently, which was discussed on
X.org's mailing list. I wanted to sumarize that here, but didn't have
time for that so far.
Right now I use the following UGLY script to do exactly that:
git-ls-remote -h origin | cut -f 2 | perl -e 'while (<>) { chomp;
$h{$_}=$_; } open F, ".git/remotes/origin" or die; while (<F>) { print;
if (/^Pull:\s+([^: ]*):/) { delete $h{$1}; } } foreach $f (keys %h) {
print "Pull: ${f}:$f\n"; }' > newfile
mv newfile .git/remotes/origin
(modulo some safety tests), but that doesn't work right for origin files
with multiple URL: statements (I very much assume they are possible).
I second that there should be a flag to make git fetch do that
automatically, and at least all "git for CVS users" tutorials should
include this flag, as this is exactly how CVS works (otherwise you
cannot check out another branch that happens to be added upstream).
Matthias
--
Matthias Hopf <mhopf@suse.de> __ __ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de
Phone +49-911-74053-715 __) |_| __) |__ labs www.mshop
^ permalink raw reply
* Re: win2k/cygwin cannot handle even moderately sized packs
From: Alex Riesen @ 2006-11-13 17:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611131333000.13772@wbgn013.biozentrum.uni-wuerzburg.de>
> This looks to me as if you have NO_MMAP=1 set in your Makefile (which I
> also do automatically when compiling on cygwin).
Kind of. I use mmap (from cygwin) in specially selected places.
I remember posting the patches once.
> The old problem: Windows does not have fork.
As if it have anything non-fubar at all...
> <digression> And before somebody starts cygwin bashing: don't. It is not
> cygwin's problem, it is Windows'.
I didn't bash cygwin. I just pity the whole effort (and myself, atm).
> And I think that a mmap() of 332MB would not fail.
It does not in isolated environment. It just fails in my particular context.
And before anyone suggests: yes, CreateFileMapping, and VirtualAlloc were
tried. They do return errors suggesting the same reason (ENOMEM).
> Long time ago (to be precise, July 18th), Linus suggested (in Message-Id:
> <Pine.LNX.4.64.0607180837260.3386@evo.osdl.org>) to find out which mmap()
> calls are _not_ used before a fork(), and not emulate them by malloc().
>
> I never came around to do that, but maybe others do?
I'm trying to find some time to make Shawn's sliding window work.
It looks promising (patches, not the time).
On 11/13/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 7 Nov 2006, Alex Riesen wrote:
>
> > For me, it fails even on 332Mb pack:
> >
> > $ git reset --hard 61bb7fcb
> > fatal: packfile .git/objects/pack/pack-ad37...pack cannot be mapped.
> >
> > Instrumenting the code reveals that it fails on 348876870 bytes.
> > Strangely enough, a cygwin program which just reads that pack
> > many times without freeing the mem goes up to 1395507480 (1330Mb).
> >
> > If I replace the malloc (cygwin) with native VirtualAlloc(MEM_COMMIT)
> > it reports that "Not enough storage is available to process this command",
> > which is just ENOMEM, I think.
>
> This looks to me as if you have NO_MMAP=1 set in your Makefile (which I
> also do automatically when compiling on cygwin).
>
> The old problem: Windows does not have fork.
>
> <digression> And before somebody starts cygwin bashing: don't. It is not
> cygwin's problem, it is Windows'. The cygwin people worked long and hard
> on something truly useful, and it helps me _every_ time I have to work on
> a Windows platform (which _is_ utter crap). Some problems of Windows are
> so unhideable though, that even cygwin cannot work around them.
> </digression>
>
> Cygwin provides a mmap(), which works remarkably well even with the
> emulated fork(), but one thing is not possible: since mmap()ed files
> have to be _reopened_ after a fork(), and git uses the
> open-temp-file-then-delete-it-but-continue-to-use-it paradigm quite often,
> we work around it by setting NO_MMAP=1. Again, this is _not_ Cygwin's
> fault!
>
> And I think that a mmap() of 332MB would not fail.
>
> Long time ago (to be precise, July 18th), Linus suggested (in Message-Id:
> <Pine.LNX.4.64.0607180837260.3386@evo.osdl.org>) to find out which mmap()
> calls are _not_ used before a fork(), and not emulate them by malloc().
>
> I never came around to do that, but maybe others do?
>
> Ciao,
> Dscho
>
^ permalink raw reply
* Re: win2k/cygwin cannot handle even moderately sized packs
From: Alex Riesen @ 2006-11-13 17:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <81b0412b0611130934u67f4da98rd39412b07f2169c0@mail.gmail.com>
oh, damn. Sorry for the appended copy. It's behind a broken corporate
^ permalink raw reply
* Re: Getting new branches from remote repo.
From: Shawn Pearce @ 2006-11-13 17:44 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Junio C Hamano, Alexander Litvinov, git
In-Reply-To: <20061113091736.GA31693@diana.vm.bytemark.co.uk>
Karl Hasselstr?m <kha@treskal.com> wrote:
> On 2006-11-12 20:49:33 -0800, Junio C Hamano wrote:
> > After finding out $that_new_branch's name, add either
> >
> > Pull: refs/heads/$that_new_branch:refs/heads/$that_new_branch
> >
> > or if you are in "separate remote" school, then perhaps
> >
> > Pull: refs/heads/$that_new_branch:refs/remotes/origin/$that_new_branch
> >
> > to .git/remotes/origin and running git fetch would give you what you
> > want, I think.
>
> There really should be a flag to make git fetch do this job. And if we
> use separate remotes, the flag should probably default to "on".
And also to automatically stop fetching any branch which is no longer
listed on the remote system, rather than reporting a "Fetch failure".
I probably would keep the local ref (they are cheap) just in case
the user was counting on that branch and then the remote system
pulled the rug out from under them. :-)
--
^ permalink raw reply
* Re: Getting new branches from remote repo.
From: Karl Hasselström @ 2006-11-13 17:53 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, Alexander Litvinov, git
In-Reply-To: <20061113174457.GA16979@spearce.org>
On 2006-11-13 12:44:57 -0500, Shawn Pearce wrote:
> Karl Hasselström <kha@treskal.com> wrote:
>
> > There really should be a flag to make git fetch do this job. And
> > if we use separate remotes, the flag should probably default to
> > "on".
>
> And also to automatically stop fetching any branch which is no
> longer listed on the remote system, rather than reporting a "Fetch
> failure".
Yes.
> I probably would keep the local ref (they are cheap) just in case
> the user was counting on that branch and then the remote system
> pulled the rug out from under them. :-)
Sounds like good default behavior. But I smell the potential for
another command flag here. :-)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: Getting new branches from remote repo.
From: Junio C Hamano @ 2006-11-13 18:17 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061113091736.GA31693@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
>> After finding out $that_new_branch's name, add either
>>
>> Pull: refs/heads/$that_new_branch:refs/heads/$that_new_branch
>>
>> or if you are in "separate remote" school, then perhaps
>>
>> Pull: refs/heads/$that_new_branch:refs/remotes/origin/$that_new_branch
>>
>> to .git/remotes/origin and running git fetch would give you what you
>> want, I think.
>
> There really should be a flag to make git fetch do this job. And if we
> use separate remotes, the flag should probably default to "on".
While I do not necessarily agree that "git fetch" is the place
to do so, I think it is sensible to have a way to easily manage
remotes/$origin file.
Things to consider are:
- We need to notice new branches at the other end.
- We need to remember old branches that the user is not
interested in, so that we do not even ask to add it only
because it does not have a local tracking branch.
- We need to notice branches that disappeared at the other
end. We may want to offer the choice between droping the
local tracking branch and keeping it in the 'the last
fetched' state.
So from the UI point of view, considering that "git fetch" might
be called as a part of "git pull", a sensible thing to do would
be:
- Add "Pull-ignored:" lines to list remote branches that the
user is not interested in to .git/remotes/$origin file, and
teach existing tools to ignore them.
- Make "git fetch" to always run "ls-remote" (we would need to
do this anyway to enable commit walkers to fetch from a
repository that has packed and then pruned its refs) upfront,
and do the "noticing" part and issue an info message when
there are new branches (we should only do this when a
shorthand from .git/remotes/ is used).
- Add "git maint-remote" command that lets the user compare
ls-remote output and Pull: lines from remotes/$origin file,
and add/modify/delete the mapping to local tracking branches.
I think the last one is probably the easiest for the users if
done with something like dialog or whiptail.
^ permalink raw reply
* Re: Non-ASCII paths and git-cvsserver
From: Martin Langhoff @ 2006-11-13 18:22 UTC (permalink / raw)
To: sf; +Cc: Junio C Hamano, git
In-Reply-To: <45587A09.3020605@b-i-t.de>
On 11/13/06, sf <sf@b-i-t.de> wrote:
> Martin, are you sure your patch is needed? (see below)
Not 100% sure. I was just making sure we crossed all the Ts and dotted
the Is. I gather you have tried my patch and it didn't make any
difference. What SQLite and Perl versions are you using?
cheers,
^ permalink raw reply
* Re: Non-ASCII paths and git-cvsserver
From: Robin Rosenberg @ 2006-11-13 18:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ej9utk$44p$1@sea.gmane.org>
måndag 13 november 2006 15:20 skrev Jakub Narebski:
> sf wrote:
> > Thanks, Junio. Paths with umlauts are returned correctly now both in
> > UTF-8 and ISO-8859-1. I guess git-cvsserver is now as encoding agnostic
> > as git core.
>
> By the way, now that git has per user config file, ~/.gitconfig, perhaps
> it is time to add i18n.filesystemEncoding configuration variable, to
> automatically convert between filesystem encoding (somthing you usually
> don't have any control over) and UTF-8 encoding of paths in tree objects.
I'd prefer git to store filenames and comments in UTF-8 and convert on
input/output when and if it is necessary rather than forcing everybody to
take the hit. Most systems, but far from all, already use UTF-8 so it's a
noop for them. The only reason I want conversion is for the years to come
where we still live in two worlds of non-utf-8 and utf-8 and then forget
about everything non-utf-8, rather than carry around the baggage forever.
^ permalink raw reply
* Re: Getting new branches from remote repo.
From: Jakub Narebski @ 2006-11-13 18:40 UTC (permalink / raw)
To: git
In-Reply-To: <7vr6w78b4x.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> - We need to remember old branches that the user is not
> interested in, so that we do not even ask to add it only
> because it does not have a local tracking branch.
Wouldn't it be easier just to add --all flag to git-fetch,
which would fetch _all_ the branches, and --save to write remotes
file... or rather appropriate config entry?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Non-ASCII paths and git-cvsserver
From: Jakub Narebski @ 2006-11-13 18:57 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200611131930.18300.robin.rosenberg.lists@dewire.com>
Dnia poniedziałek 13. listopada 2006 19:30, Robin Rosenberg napisał:
> måndag 13 november 2006 15:20 skrev Jakub Narebski:
>> sf wrote:
>>> Thanks, Junio. Paths with umlauts are returned correctly now both in
>>> UTF-8 and ISO-8859-1. I guess git-cvsserver is now as encoding agnostic
>>> as git core.
>>
>> By the way, now that git has per user config file, ~/.gitconfig, perhaps
>> it is time to add i18n.filesystemEncoding configuration variable, to
>> automatically convert between filesystem encoding (somthing you usually
>> don't have any control over) and UTF-8 encoding of paths in tree objects.
>
> I'd prefer git to store filenames and comments in UTF-8 and convert on
> input/output when and if it is necessary rather than forcing everybody to
> take the hit. Most systems, but far from all, already use UTF-8 so it's a
> noop for them. The only reason I want conversion is for the years to come
> where we still live in two worlds of non-utf-8 and utf-8 and then forget
> about everything non-utf-8, rather than carry around the baggage forever.
That was my idea, to have i18n.filesystemEncoding configuration variable
to convert between filesystem encoding (which is usually something you don't
have control over, and which depends from place to place, but not from
repository to repository) and UTF-8 encoding git would store filenames.
--
Jakub Narebski
^ permalink raw reply
* Re: information for a 60-minute "intro to git" needed
From: Jon Loeliger @ 2006-11-13 18:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git List
In-Reply-To: <20061111143304.GA7201@pasky.or.cz>
On Sat, 2006-11-11 at 08:33, Petr Baudis wrote:
>
> see
>
> http://news.gmane.org/find-root.php?message_id=<7vvepqi6x6.fsf@assigned-by-dhcp.cox.net>
>
> and replies for some slides from OLS (dunno if jdl's made his
> available?), and http://git.or.cz/gitwiki/GitLinks for links to plenty
> of "using git" pages for various projects and other introductory
> articles.
All of my git papers published in Linux Magazine as well
as my OLS presentation are available off of www.jdl.com.
(Yes, I still need to make them available off of
opensource.freescale.com as well still. *sigh*)
jdl
^ permalink raw reply
* Re: should git download missing objects?
From: Alex Riesen @ 2006-11-13 19:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Anand Kumria, git
In-Reply-To: <7vwt60bggs.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Sun, Nov 12, 2006 20:41:23 +0100:
> Since this is not everyday anyway, a far easier way would be to
> clone-pack from the upstream into a new repository, take the
> pack you downloaded from that new repository and mv it into your
> corrupt repository. You can run fsck-objects to see if you got
> back everything you lost earlier.
I get into such a situation annoyingly often, by using
"git clone -l -s from to" and doing some "cleanup" in the
origin repository. For example, it happens that I remove a tag,
or a branch, and do a repack or prune afterwards. The related
repositories, which had "accidentally" referenced the pruned
objects become "corrupt", as you put it.
At the moment, if I run into the situation, I copy packs/objects from
all repos I have (objects/info/alternates are useful here too), run a
fsck-objects/repack and hope nothing is lost. It works, as I almost
always have "accidental" backups somewhere, but is kind of annoying to
setup. A tool to do this job more effectively will be very handy (at
least, it wont have to copy gigabytes of data over switched windows
network. Not often, I hope. Not _so_ many gigabytes, possibly).
^ permalink raw reply
* Re: Non-ASCII paths and git-cvsserver
From: Junio C Hamano @ 2006-11-13 19:48 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200611131930.18300.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> måndag 13 november 2006 15:20 skrev Jakub Narebski:
>> sf wrote:
>> > Thanks, Junio. Paths with umlauts are returned correctly now both in
>> > UTF-8 and ISO-8859-1. I guess git-cvsserver is now as encoding agnostic
>> > as git core.
>>
>> By the way, now that git has per user config file, ~/.gitconfig, perhaps
>> it is time to add i18n.filesystemEncoding configuration variable, to
>> automatically convert between filesystem encoding (somthing you usually
>> don't have any control over) and UTF-8 encoding of paths in tree objects.
>
> I'd prefer git to store filenames and comments in UTF-8 and convert on
> input/output when and if it is necessary rather than forcing everybody to
> take the hit. Most systems, but far from all, already use UTF-8 so it's a
> noop for them. The only reason I want conversion is for the years to come
> where we still live in two worlds of non-utf-8 and utf-8 and then forget
> about everything non-utf-8, rather than carry around the baggage forever.
Pathnames in git core are encoding agnostic just like UNIX
pathnames are. As you say, if the project convention is UTF-8
then it would not make any difference either way, so the status
quo is fine for people living in UTF-8 only world.
To people for whom it is inconvenient to work with UTF-8,
including me, it is always wrong to record UTF-8 at the core
level and try to autoconvert. If (non-git) tools, libraries and
legacy-to-unicode roundtrip conversion were perfect, we would
have already converted and living in UTF-8 only world. Projects
that choose to run with legacy pathname encoding should be
allowed to do so without taking the roundtrip risk converting to
and from UTF-8.
Interestingly enough, Linus mentioned this once, a lot better
than myself would have, here:
http://thread.gmane.org/gmane.comp.version-control.git/12240/focus=12279
Having said that, I am not opposed to have an option to make the
external interface to do the pathname conversion. If your
project chooses to use euc-jp for commit messages, your
configuration variable i18n.commitencoding is set to euc-jp, and
if gitweb always wants to do its thing in utf-8 (which is
probably a sensible thing to do), it would make a lot of sense
to take the commit message and convert it from euc-jp to utf-8
before rendering it in HTML. Maybe i18n.pathnameencoding could
be used for similar purposes for external interfaces.
But the core will stay encoding agnostic; pathnames stored in
the index and tree are what you can feed stat() and open(), and
what you read from readdir(). Maybe we could revisit this
decision in five years, but not now.
^ permalink raw reply
* Re: should git download missing objects?
From: Shawn Pearce @ 2006-11-13 19:54 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Anand Kumria, git
In-Reply-To: <20061113194532.GA4547@steel.home>
Alex Riesen <fork0@t-online.de> wrote:
> Junio C Hamano, Sun, Nov 12, 2006 20:41:23 +0100:
> > Since this is not everyday anyway, a far easier way would be to
> > clone-pack from the upstream into a new repository, take the
> > pack you downloaded from that new repository and mv it into your
> > corrupt repository. You can run fsck-objects to see if you got
> > back everything you lost earlier.
>
> I get into such a situation annoyingly often, by using
> "git clone -l -s from to" and doing some "cleanup" in the
> origin repository. For example, it happens that I remove a tag,
> or a branch, and do a repack or prune afterwards. The related
> repositories, which had "accidentally" referenced the pruned
> objects become "corrupt", as you put it.
>
> At the moment, if I run into the situation, I copy packs/objects from
> all repos I have (objects/info/alternates are useful here too), run a
> fsck-objects/repack and hope nothing is lost. It works, as I almost
> always have "accidental" backups somewhere, but is kind of annoying to
> setup. A tool to do this job more effectively will be very handy (at
> least, it wont have to copy gigabytes of data over switched windows
> network. Not often, I hope. Not _so_ many gigabytes, possibly).
One of my coworkers recently lost a single loose tree object.
We suspect his Windows virus scanner deleted the file. :-(
Copying the one bad object from another repository immediately fixed
the breakage caused, but it was very annoying to not be able to run a
"git fetch --missing-objects" or some such. Fortunately it was just
the one object and it was also still loose in another repository.
scp was handy. :-)
--
^ permalink raw reply
* Re: should git download missing objects?
From: Petr Baudis @ 2006-11-13 20:03 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Alex Riesen, Junio C Hamano, Anand Kumria, git
In-Reply-To: <20061113195414.GD17244@spearce.org>
On Mon, Nov 13, 2006 at 08:54:14PM CET, Shawn Pearce wrote:
> Alex Riesen <fork0@t-online.de> wrote:
> > Junio C Hamano, Sun, Nov 12, 2006 20:41:23 +0100:
> > > Since this is not everyday anyway, a far easier way would be to
> > > clone-pack from the upstream into a new repository, take the
> > > pack you downloaded from that new repository and mv it into your
> > > corrupt repository. You can run fsck-objects to see if you got
> > > back everything you lost earlier.
> >
> > I get into such a situation annoyingly often, by using
> > "git clone -l -s from to" and doing some "cleanup" in the
> > origin repository. For example, it happens that I remove a tag,
> > or a branch, and do a repack or prune afterwards. The related
> > repositories, which had "accidentally" referenced the pruned
> > objects become "corrupt", as you put it.
> >
> > At the moment, if I run into the situation, I copy packs/objects from
> > all repos I have (objects/info/alternates are useful here too), run a
> > fsck-objects/repack and hope nothing is lost. It works, as I almost
> > always have "accidental" backups somewhere, but is kind of annoying to
> > setup. A tool to do this job more effectively will be very handy (at
> > least, it wont have to copy gigabytes of data over switched windows
> > network. Not often, I hope. Not _so_ many gigabytes, possibly).
cg-fetch -f locally or over HTTP should be able to fix that up, if used
cleverly.
> One of my coworkers recently lost a single loose tree object.
> We suspect his Windows virus scanner deleted the file. :-(
>
> Copying the one bad object from another repository immediately fixed
> the breakage caused, but it was very annoying to not be able to run a
> "git fetch --missing-objects" or some such. Fortunately it was just
> the one object and it was also still loose in another repository.
> scp was handy. :-)
If it's over ssh, this is still where the heavily dusty (and heavily
"plumby") git-ssh-fetch command is useful, since it can get passed an
undocumented --recover argument and then it will fetch _all_ the objects
you are missing, not assuming anything.
Perhaps I should reintroduce support for git-ssh-fetch to cg-fetch to be
used in case of -f over SSH. But it would be silly if I did that and
next Git would remove the command from its suite. Junio, what's its life
expectancy? I guess this usage scenario is something to take into
account when thinking about removing it, I know that I wanted to get rid
of it in the past but now my opinion is changing.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: should git download missing objects?
From: Junio C Hamano @ 2006-11-13 20:05 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20061113194532.GA4547@steel.home>
fork0@t-online.de (Alex Riesen) writes:
> Junio C Hamano, Sun, Nov 12, 2006 20:41:23 +0100:
>> Since this is not everyday anyway, a far easier way would be to
>> clone-pack from the upstream into a new repository, take the
>> pack you downloaded from that new repository and mv it into your
>> corrupt repository. You can run fsck-objects to see if you got
>> back everything you lost earlier.
>
> I get into such a situation annoyingly often, by using
> "git clone -l -s from to" and doing some "cleanup" in the
> origin repository. For example, it happens that I remove a tag,
> or a branch, and do a repack or prune afterwards. The related
> repositories, which had "accidentally" referenced the pruned
> objects become "corrupt", as you put it.
>
> At the moment, if I run into the situation, I copy packs/objects from
> all repos I have (objects/info/alternates are useful here too), run a
> fsck-objects/repack and hope nothing is lost. It works, as I almost
> always have "accidental" backups somewhere, but is kind of annoying to
> setup. A tool to do this job more effectively will be very handy (at
> least, it wont have to copy gigabytes of data over switched windows
> network. Not often, I hope. Not _so_ many gigabytes, possibly).
I suspect it is a different issue. Maybe you would need reverse
links from the origin directory to .git/refs/ directroy of
repositories that borrow from it to prevent pruning. No amount
of butchering fetch-pack to look behind incomplete refs that lie
and claim they are complete would solve your problem if you do
not have any "accidental backups".
In general, 'git clone -l -s' origin directories may not be
writable by the person who is making the clone, so we should not
do this inside 'git clone'. Also you could add alternates after
you set up your repository, so maybe something like this would
help?
#!/bin/sh
#
# Usage: git-add-alternates other_repo
#
: ${GIT_DIR=.git}
my_refs=`cd $GIT_DIR/refs && pwd`
other=$1
test -d "$other/.git" && test -d "$other/objects" || {
echo >&2 "I do not see a repository at $other"
exit 1
}
mkdir -p "$other/.git/refs/borrowers" || {
echo >&2 "You cannot write in $other"
echo >&2 "Arrange with the owner of it to make"
echo >&2 "sure the objects you need are not pruned."
exit 2
}
cnt=0
while test -d "$other/.git/refs/borrowers/$cnt"
do
cnt=$(($cnt + 1))
done
ln -s "$my_refs" "$other/.git/refs/borrowers/$cnt"
^ permalink raw reply
* Re: should git download missing objects?
From: Shawn Pearce @ 2006-11-13 20:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: Alex Riesen, Junio C Hamano, Anand Kumria, git
In-Reply-To: <20061113200358.GF7201@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> On Mon, Nov 13, 2006 at 08:54:14PM CET, Shawn Pearce wrote:
> > Copying the one bad object from another repository immediately fixed
> > the breakage caused, but it was very annoying to not be able to run a
> > "git fetch --missing-objects" or some such. Fortunately it was just
> > the one object and it was also still loose in another repository.
> > scp was handy. :-)
>
> If it's over ssh, this is still where the heavily dusty (and heavily
> "plumby") git-ssh-fetch command is useful, since it can get passed an
> undocumented --recover argument and then it will fetch _all_ the objects
> you are missing, not assuming anything.
Interesting. Since its undocumented I didn't know it existed
until now. :)
I'm thinking though that a --recover should just be part of
git-fetch, and that it should work on all transports, not just SSH.
Of course you could get into a whole world of hurt where you keep
doing fsck-objects --full (listing out the missing), fetching them,
only to find more missing, etc. After a coule of cycles of that it
may just be better to claim to the other end that you have nothing
but want everything (e.g. an initial clone) and get a new pack from
which you can pull objects.
But I think that was sort of Junio's point on this topic. I'm just
trying to throw in my +1 in favor of a feature that would have
recovered that sole missing object without making the end user
reclone their entire repository and move pack files around by hand.
And I'm being more verbose about it than just +1. :)
--
^ permalink raw reply
* Re: should git download missing objects?
From: Junio C Hamano @ 2006-11-13 20:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061113200358.GF7201@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> ... Junio, what's its life
> expectancy? I guess this usage scenario is something to take into
> account when thinking about removing it, I know that I wanted to get rid
> of it in the past but now my opinion is changing.
It uses the same commit walker semantics and mechanism so I do
not think it is too much burden to carry it, but I'd rather have
something that works over git native protocol if we really care
about this. People without ssh access needs to be able to
recover over git:// protocol.
^ permalink raw reply
* Re: [PATCH] Rework cvsexportcommit to handle binary files for all cases.
From: Robin Rosenberg @ 2006-11-13 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz6wark9.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]
måndag 13 november 2006 05:39 skrev Junio C Hamano:
> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> > Now adding, removing and changing binary files works. I added
> > test cases to make sure qit works and can be verified by
> > others. Som other corner cases were resolved too.
> >
> > Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
>
> Thanks.
>
> It is necessary to clarify what these other corner cases are in
> the commit log message. Three months down the road you yourself
> would not remember what they were.
I hardly remember now. I wrote test cases and modified the code until it
worked. I'll skip that remark.
>
> You seem to like:
>
> my $p = "m,^$pathname\$,";
> if (grep $p,@array) { do this... }
>
I can't say I'm fond of any perl syntax, really. Perl is a very usable, but
ugly tool.
> but this is a bad habit. $pathname can contain regexp
> metacharacters or a comma. You should just say:
>
> if (grep { $_ eq $pathname } @arrray) { do this... }
>
> instead. I'd fix them up with the attached patch.
Thanks.
> It would also be nice to rework this program so that it can work
> with whitespaces in pathnames. I do not think it currently
> works with them at all.
I sent a patch earlier, which was not applied, due to imperfections that I
cannot solve fully. One issue was that patch 2.5.9 was required and hacking
it to handle binary diffs with spaces would require and even worse kludge,
I can, however, send the previous patch adapted onto this one.
> It appears that this program was never used in western
> hemisphere, by the way ;-).
Now, Sweden is definitely in the northern hemisphere, even during the cold
war, though a number of computer games colored it red (or was it only
Finland) during the cold war.
The tests work with my locale (swedish ISO-8859-15), even though they like
all other tests run in the C "hemishpere" by default. AFAIK, git isn't very
user friendly with non-ascii filenames as it is today and cvsexportcommit
didn't work on such files before, and it doesn't now. No change there.
Another patch, another day, maybe.
-- robin
[-- Attachment #2: 0001-Rework-cvsexportcommit-to-handle-binary-files-for-all-cases.txt --]
[-- Type: text/plain, Size: 19041 bytes --]
From b591652ab3a65d3e319cbf59bcd161e3588a4696 Mon Sep 17 00:00:00 2001
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Date: Mon, 13 Nov 2006 21:29:01 +0100
Subject: [PATCH] Rework cvsexportcommit to handle binary files for all cases.
Also adds test cases for adding removing and deleting
binary and text files plus two tests for the checks on
binary files.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 5e23851f8cf866112baf3e76973a8ca649d5c105..facb4667eefe79cbd4d29e542ec5e8111a7a973c 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -1,10 +1,10 @@
#!/usr/bin/perl -w
# Known limitations:
-# - cannot add or remove binary files
# - does not propagate permissions
# - tells "ready for commit" even when things could not be completed
-# (eg addition of a binary file)
+# (not sure this is true anymore, maybe more testing is needed)
+# - does not handle whitespace in pathnames at all.
use strict;
use Getopt::Std;
@@ -139,6 +139,17 @@ foreach my $f (@files) {
push @dfiles, $fields[5];
}
}
+my (@binfiles, @abfiles, @dbfiles, @bfiles, @mbfiles);
+@binfiles = grep m/^Binary files/, safe_pipe_capture('git-diff-tree', '-p', $parent, $commit);
+map { chomp } @binfiles;
+@abfiles = grep s/^Binary files \/dev\/null and b\/(.*) differ$/$1/, @binfiles;
+@dbfiles = grep s/^Binary files a\/(.*) and \/dev\/null differ$/$1/, @binfiles;
+@mbfiles = grep s/^Binary files a\/(.*) and b\/(.*) differ$/$1/, @binfiles;
+push @bfiles, @abfiles;
+push @bfiles, @dbfiles;
+push @bfiles, @mbfiles;
+push @mfiles, @mbfiles;
+
$opt_v && print "The commit affects:\n ";
$opt_v && print join ("\n ", @afiles,@mfiles,@dfiles) . "\n\n";
undef @files; # don't need it anymore
@@ -153,6 +164,10 @@ foreach my $d (@dirs) {
}
foreach my $f (@afiles) {
# This should return only one value
+ if ($f =~ m,(.*)/[^/]*$,) {
+ my $p = $1;
+ next if (grep { $_ eq $p } @dirs);
+ }
my @status = grep(m/^File/, safe_pipe_capture('cvs', '-q', 'status' ,$f));
if (@status > 1) { warn 'Strange! cvs status returned more than one line?'};
if (-d dirname $f and $status[0] !~ m/Status: Unknown$/
@@ -162,6 +177,7 @@ foreach my $f (@afiles) {
warn "Status was: $status[0]\n";
}
}
+
foreach my $f (@mfiles, @dfiles) {
# TODO:we need to handle removed in cvs
my @status = grep(m/^File/, safe_pipe_capture('cvs', '-q', 'status' ,$f));
@@ -200,24 +216,31 @@ foreach my $d (@dirs) {
print "'Patching' binary files\n";
-my @bfiles = grep(m/^Binary/, safe_pipe_capture('git-diff-tree', '-p', $parent, $commit));
-@bfiles = map { chomp } @bfiles;
foreach my $f (@bfiles) {
# check that the file in cvs matches the "old" file
# extract the file to $tmpdir and compare with cmp
- my $tree = safe_pipe_capture('git-rev-parse', "$parent^{tree}");
- chomp $tree;
- my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
- chomp $blob;
- `git-cat-file blob $blob > $tmpdir/blob`;
- if (system('cmp', '-s', $f, "$tmpdir/blob")) {
- warn "Binary file $f in CVS does not match parent.\n";
- $dirty = 1;
- next;
+ if (not(grep { $_ eq $f } @afiles)) {
+ my $tree = safe_pipe_capture('git-rev-parse', "$parent^{tree}");
+ chomp $tree;
+ my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
+ chomp $blob;
+ `git-cat-file blob $blob > $tmpdir/blob`;
+ if (system('cmp', '-s', $f, "$tmpdir/blob")) {
+ warn "Binary file $f in CVS does not match parent.\n";
+ if (not $opt_f) {
+ $dirty = 1;
+ next;
+ }
+ }
+ }
+ if (not(grep { $_ eq $f } @dfiles)) {
+ my $tree = safe_pipe_capture('git-rev-parse', "$commit^{tree}");
+ chomp $tree;
+ my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
+ chomp $blob;
+ # replace with the new file
+ `git-cat-file blob $blob > $f`;
}
-
- # replace with the new file
- `git-cat-file blob $blob > $f`;
# TODO: something smart with file modes
@@ -231,7 +254,10 @@ ## apply non-binary changes
my $fuzz = $opt_p ? 0 : 2;
print "Patching non-binary files\n";
-print `(git-diff-tree -p $parent -p $commit | patch -p1 -F $fuzz ) 2>&1`;
+
+if (scalar(@afiles)+scalar(@dfiles)+scalar(@mfiles) != scalar(@bfiles)) {
+ print `(git-diff-tree -p $parent -p $commit | patch -p1 -F $fuzz ) 2>&1`;
+}
my $dirtypatch = 0;
if (($? >> 8) == 2) {
@@ -242,7 +268,11 @@ if (($? >> 8) == 2) {
}
foreach my $f (@afiles) {
- system('cvs', 'add', $f);
+ if (grep { $_ eq $f } @bfiles) {
+ system('cvs', 'add','-kb',$f);
+ } else {
+ system('cvs', 'add', $f);
+ }
if ($?) {
$dirty = 1;
warn "Failed to cvs add $f -- you may need to do it manually";
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
new file mode 100755
index 0000000000000000000000000000000000000000..0ae03f80694a5d4ca3e61b40f6787a89fe8a496e
--- /dev/null
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -0,0 +1,145 @@
+#!/bin/bash
+#
+# Copyright (c) Robin Rosenberg
+#
+test_description='CVS export comit. '
+
+. ./test-lib.sh
+
+cvs >/dev/null 2>&1
+if test $? -ne 1
+then
+ test_expect_success 'skipping git-cvsexportcommit tests, cvs not found' :
+ test_done
+ exit
+fi
+
+export CVSROOT=$(pwd)/cvsroot
+export CVSWORK=$(pwd)/cvswork
+rm -rf "$CVSROOT" "$CVSWORK"
+mkdir "$CVSROOT" &&
+cvs init &&
+cvs -Q co -d "$CVSWORK" . &&
+export GIT_DIR=$(pwd)/.git &&
+echo >empty &&
+git add empty &&
+git commit -a -m "Initial" 2>/dev/null ||
+exit 1
+
+test_expect_success \
+ 'New file' \
+ 'mkdir A B C D E F &&
+ echo hello1 >A/newfile1.txt &&
+ echo hello2 >B/newfile2.txt &&
+ cp ../test9200a.png C/newfile3.png &&
+ cp ../test9200a.png D/newfile4.png &&
+ git add A/newfile1.txt &&
+ git add B/newfile2.txt &&
+ git add C/newfile3.png &&
+ git add D/newfile4.png &&
+ git commit -a -m "Test: New file" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ git cvsexportcommit -c $id &&
+ test "$(echo $(sort A/CVS/Entries|cut -d/ -f2,3,5))" = "newfile1.txt/1.1/" &&
+ test "$(echo $(sort B/CVS/Entries|cut -d/ -f2,3,5))" = "newfile2.txt/1.1/" &&
+ test "$(echo $(sort C/CVS/Entries|cut -d/ -f2,3,5))" = "newfile3.png/1.1/-kb" &&
+ test "$(echo $(sort D/CVS/Entries|cut -d/ -f2,3,5))" = "newfile4.png/1.1/-kb" &&
+ diff A/newfile1.txt ../A/newfile1.txt &&
+ diff B/newfile2.txt ../B/newfile2.txt &&
+ diff C/newfile3.png ../C/newfile3.png &&
+ diff D/newfile4.png ../D/newfile4.png
+ )'
+
+test_expect_success \
+ 'Remove two files, add two and update two' \
+ 'echo Hello1 >>A/newfile1.txt &&
+ rm -f B/newfile2.txt &&
+ rm -f C/newfile3.png &&
+ echo Hello5 >E/newfile5.txt &&
+ cp ../test9200b.png D/newfile4.png &&
+ cp ../test9200a.png F/newfile6.png &&
+ git add E/newfile5.txt &&
+ git add F/newfile6.png &&
+ git commit -a -m "Test: Remove, add and update" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ git cvsexportcommit -c $id &&
+ test "$(echo $(sort A/CVS/Entries|cut -d/ -f2,3,5))" = "newfile1.txt/1.2/" &&
+ test "$(echo $(sort B/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
+ test "$(echo $(sort C/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
+ test "$(echo $(sort D/CVS/Entries|cut -d/ -f2,3,5))" = "newfile4.png/1.2/-kb" &&
+ test "$(echo $(sort E/CVS/Entries|cut -d/ -f2,3,5))" = "newfile5.txt/1.1/" &&
+ test "$(echo $(sort F/CVS/Entries|cut -d/ -f2,3,5))" = "newfile6.png/1.1/-kb" &&
+ diff A/newfile1.txt ../A/newfile1.txt &&
+ diff D/newfile4.png ../D/newfile4.png &&
+ diff E/newfile5.txt ../E/newfile5.txt &&
+ diff F/newfile6.png ../F/newfile6.png
+ )'
+
+# Should fail (but only on the git-cvsexportcommit stage)
+test_expect_success \
+ 'Fail to change binary more than one generation old' \
+ 'cat F/newfile6.png >>D/newfile4.png &&
+ git commit -a -m "generatiion 1" &&
+ cat F/newfile6.png >>D/newfile4.png &&
+ git commit -a -m "generation 2" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ ! git cvsexportcommit -c $id
+ )'
+
+# Should fail, but only on the git-cvsexportcommit stage
+test_expect_success \
+ 'Fail to remove binary file more than one generation old' \
+ 'git reset --hard HEAD^ &&
+ cat F/newfile6.png >>D/newfile4.png &&
+ git commit -a -m "generation 2 (again)" &&
+ rm -f D/newfile4.png &&
+ git commit -a -m "generation 3" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ ! git cvsexportcommit -c $id
+ )'
+
+# We reuse the state from two tests back here
+
+# This test is here because a patch for only binary files will
+# fail with gnu patch, so cvsexportcommit must handle that.
+test_expect_success \
+ 'Remove only binary files' \
+ 'git reset --hard HEAD^^^ &&
+ rm -f D/newfile4.png &&
+ git commit -a -m "test: remove only a binary file" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ git cvsexportcommit -c $id &&
+ test "$(echo $(sort A/CVS/Entries|cut -d/ -f2,3,5))" = "newfile1.txt/1.2/" &&
+ test "$(echo $(sort B/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
+ test "$(echo $(sort C/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
+ test "$(echo $(sort D/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
+ test "$(echo $(sort E/CVS/Entries|cut -d/ -f2,3,5))" = "newfile5.txt/1.1/" &&
+ test "$(echo $(sort F/CVS/Entries|cut -d/ -f2,3,5))" = "newfile6.png/1.1/-kb" &&
+ diff A/newfile1.txt ../A/newfile1.txt &&
+ diff E/newfile5.txt ../E/newfile5.txt &&
+ diff F/newfile6.png ../F/newfile6.png
+ )'
+
+test_expect_success \
+ 'Remove only a text file' \
+ 'rm -f A/newfile1.txt &&
+ git commit -a -m "test: remove only a binary file" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ git cvsexportcommit -c $id &&
+ test "$(echo $(sort A/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
+ test "$(echo $(sort B/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
+ test "$(echo $(sort C/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
+ test "$(echo $(sort D/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
+ test "$(echo $(sort E/CVS/Entries|cut -d/ -f2,3,5))" = "newfile5.txt/1.1/" &&
+ test "$(echo $(sort F/CVS/Entries|cut -d/ -f2,3,5))" = "newfile6.png/1.1/-kb" &&
+ diff E/newfile5.txt ../E/newfile5.txt &&
+ diff F/newfile6.png ../F/newfile6.png
+ )'
+
+test_done
diff --git a/t/test9200a.png b/t/test9200a.png
new file mode 100644
index 0000000000000000000000000000000000000000..7b181d15cebb4c86a6ad7fed3dbf30ce2223b4c5
GIT binary patch
literal 5660
zc$`Id1yoe;^Zo)$N(e0J(p}QEfPi$DQW8>2hjdCvBQ2c^N=U=fEQ%l<OE*Zj)FMj$
z_VYjAbN=_7_s)Cf+&g#PnP=v?6Q`@KLPS7I0001p)KnGq(GvdO!oxw|WyWxX&;rL=
zLq!o#3}6JD5q?UcKx^<lR8719fafg#Ee!uJvc6~~uD6<&67C!}76@A+ze^|xt)lZ*
zGWJ$*cXhRM^9Cq*+F5zq*)sY$dOI+_a<F4mQPa{rwPkYy04T!L6y;y}FP#*)x`19U
z4?K2;EPnZ}m4_D*|7mH8Eb&57u38Jik~sH^?kl_U(~Q48dvnsHNa~{}zdt5Nt}*E5
zikv5GD3NPue*dxh7f`vl7%RR~(J)J59p_3~+O<^D1-DxcdEsKe+S1fy4;}Avtqaw!
zJo)YY2lCCU;K*zbVvpIWj!VXv>ZvF%gb^3Uo{Hx{HuQcc9lxw_w{~z~g<>)9VYESF
z9Gq}_*o5t%FVT#8d*scY-TdptZBgpXqn{gtNC=55me$ro4Z(adx7mm2&Hfc!(~-Qt
zlU{8#Y|nbzoE2hkeI~#OrBwm3l``6d^zzd=F+P^lx+@O&E;?8;eo8OsT?%S%b8B~*
zG}a>Ic5(kKK7O=yc|w^zJuA^l_j)6D1(1tvTZ&T<&$#ZdQ&@QxfxB=}TA`O+BX`18
zoaI7@6~>nAxoZrLnKR3oBJb`Liv;6JPVcvuSN4KNp)g-Mhfdn>cnfGZB?SF}95~6v
zur@(awR4tHWfd_F=|5dTPk7CH@n&i<PZY8C!&k+SpK={9<2OdtPjnCOvk#0XP~#W2
zDh43z63*QBp|9I;61|oSFanuD)m+pZh@rl}9S5VmXxouhOk?po7RJyAZLNouh}_v8
z;8<XKOE`P=DNo_{#?1P`Pc3bdL?`1*%~M`f&H6adt79HM!qVi+J3ALxhd3{k)`?Mw
zU}U6CG;O3xAjGQqk?UBY{VhB$Q2-sMOc%nS=i?*0@&Ovnu*vbX1DR@`P>XQWG}h$@
zWn_hXQ+PFQ<RRBRd!YqHMq6yThrN4UM~ni9k*eC4*1C%cr%B%YNnO{{GWWVT!2b^I
z*D<&2cVR@+8QL97e|x@qY<U3@!EGE7l57OoR!-cGKZfg1VVzg3WZ~-+iOM;}VreJ%
zjUr_kI26Dh;kXA>kUA@wDl3^L&J``Pn(?nZFWt1Ns|s?w9}a2q8P;GW!(YAKPEFq3
zD~QSuH?dQ6PpjD7YR7PGVJexd*t42D3^uJl<8<C;QyZqsZVGS|X8U3iE_PUe`hLbT
z)0Np1;O`)+kdlzQe@7etOpDLS&YWxJ4gL7ef;LDgUy^dKMZc}PZs9_dEN*2j0mey?
z%OGj%sJOigLmRAIcutmh(<nD|dJdmGOTu@^j22B_zk<ITfN=4foPgiwCbw~wNqe_g
ziD$h`^gbUgcylG)?qJDhqID`{v~0KJlTsy61%dApwB9E`{oMXC-RGz^@+Lp~X=2=9
z?WM3&ddQq`!=|P`KHf3i9JImaHZRn1cxaSurx*E|vy86Tq=Ii&A*i`Hzt!KpPZYD+
zvOt;fY5k1anA?}q^mMb7=}xPal(k4xJrEERgOiqi#fjII)<M?LKY+-o)33LUD^rh6
zrh6`}!*MD00)2iqVS(F9)uMq>si$}zvMamMcW)+jS7OOOsCY0vH0?T9_fNz#+g$&q
z1{A~LGkTr)5n-#He)e}EmX-{d;bCr?_tR@fe+H1y<n)WC;}`Vue0N3EZ}Lp&UV*R$
zO$tT05|qh3AWT0Svvf~|X$w-G5lf;Gr!(ZCu=)a;HAB>nM*Vs6jX0B9nq;;TsdY4=
z0&kgwn|S8S_cFf{8=={nb?*Ie1M#)=7<A#c6pp{5sO?F+ff#fKf%GCPI18KJh|tcC
z1={9;Y4NWJ1024&^uwn$)|;7ZtIAtM;P&B?WTa-D-(2i~XrwJQ5MjA$*bE944|ZcL
zC*<ij*%5XXUe$X-V;qZ598~o{OzLEqC6RKB06h?$D_BX7am2IH;2*qqu%trDrOAJg
z5YeZ{f5M6ELU@&Jca(6Zu*SVfw#y0ENCUn*cIW;mSYd7zV<p8CzY9c`STV*kW9m;0
zeU_r-p_3(xTd=s^B0%z1qU~mHZ2FKKPJpO543$rK2W+9)*>s7~MEXg}H_oi0c~=6$
zlH0^0tscGKY3xg=n~1<Ny&Xi&4OY^(ArGYwT5d_u;0h?%3DNP-n0FV9bknprCT>Sr
zLt2Y>Wpqe^7^jcxk3xt!PF>ytwWIeRqv@2D`PhpC`V-Q0q>C7YaCxuo{YIVom20t1
z#$#GTW4u`P^L&ii?1-49eZ&j-7<|eqWNy#0D#@1`tesSL`vxs^giY|oshoqc;D8=8
z(y;|aB|;!${NcQD2iJ#I3ZPf1+>P*U7w=Y>GNIX<MnpPI2FH8@HhDRgR&F0xXh`XU
zS=9mu8L2l%QCf*+oGX-^!<Ba<)1-5OW?t$Lc4Eq9J*GNHqp#m_z4I1)k`WWvczjC^
z9P;M+YWU_HLNT1q6qCxN#-ES8Xt5~Vr@>wtPgS6Dl9v;4dT@9Cf*TM*sS*yQb2<j6
z!6}Kmyj8W0E}t6ZnX1V^BOp!+Dx0&r@>0?<8F?+8VM@--TYFwgjdmZZiB%7|8l5`N
zBx2Y?KE0Ya^c9KTrCPSTj#Nf`nS^nB{a!R?38;*G#lKw4Nd_93*XeJq#_h8|ddrRU
z&6nJC7)<4}&&hY77N@Q<nt$VaHQYV|%~xshH>5-~ZE}qa9V)9?%gU|{3XkN3i_tFU
zTmqp|>XGL@dRr_CIH&emGH4pi>+lt!9dnRVO8u45?jb^}#7ZUzXB0*^=a-K%1qUAV
z15IGxpM!x28A-U^;(7j%*OMjWVtXC(V-_V41Ha(!oTgoV7Au~M&QmY2L#GhIkiCzh
zsFbcJv&~I3$Nk{%*DrazGBrz6W>v^L`Si4j1sA(SF5AJ<MZ(#ROpyaF;)@QLK-io|
zLC<!<5GGmNP}rGt>MQqb(V%P{r#CrKy<~_oIXN6gyO0M+Q_L<6x2+I&vgep>E|)bm
zbZnL<(H~93gQ*lUO%2|Ge;89$B^r|_+}QGztuK(ZH6Z0uJ=IChscAbXL4Sbb#bJhk
zBSz2fg&h0+)E8EUMMHxuC%cAFR`bA#J3%0PQ1YIf6sSn9hsVWV(kAwd;oG@f*ymIN
zuZ|z%Jk4~!1MO{g2;^<3_KF@zQ_R#8J0zszOR`%&XCB+8a$Vrz)%8}3rta**npb3X
z>eI1ziAn6Yq~#j-l^K%{;@TE96`zXCJ8!QD&;qz{<kA>FPX%E{0iJ7sC}OPvNE7&k
zh~%jFd=TrPI*@)j#Kz5&mXuLo=G|a?g#I1XB$Q*Ykx=P|rxaF>ZjmBI5pM$r;+Yd-
z@g@na;<|C|Luk`h$r@i0athMKE4vguWQ$oO>x_$#>eS8Zg6uq%%UXPSca7e{2Zx`)
zlz7<{^uq*m`G%yCHXO&Qj&Dt6PE`5mJ)ilT7&59g{!S?u6?Eiu+rBBjMbj#$Iyq+e
zF_FwU#UXH6V|f4sXlQs;Rd;b=9v2_^-lgxbowIJ%wP!q3V(@lEwJ_qV#~|Do`;E-d
z`ry{OF*s`4V?^yb@7N_@*f_`K*reD%(2dz@nei*&Y5Mb=&YmW|$qqXkwRlh2KsoK?
z$)^fJfhjKc;GD4WYoXEa3;lBrGn5rdN*IbcxAo=PrgPU6!ZJU`j>(~87<@1FMw8zY
zgk|$8=%rD3=r>xg3tMR!lDMLV%Ef*%s4jS%eO$94^LH{jkW)@+rUz|jo3O<>hQ4*$
z+=X>KHDHS2cuP+{5n?}d9PSk(=oH1^mK3=45)yqVRStPU!a<6{8eLH!iqWBbE%UC!
z6#)=V;JY(apqt6FBOkq+5kp2^h5R&LH#(MF9;Qi}%%FIrGtMF1H~Vya{sFp@#%#w4
zNeF1_lXp*}%jXv0c*d!Wf}*A_KD$I4O<afpy|sgwH!~N-JcZWIR`<@Zk?cCIY{iMH
z>d%F^0GI&KP$xx3U{!stV<-AEh3)?|4`_I3aLXwL@07inQ%BWC0IVcshch0%XY3}0
z*kZm{ic*_(mAvv_uYT%g*4&qYkrp?>7E^6E#66wYIW;E{7Ovi<Q8LPjFAE{7QX1VA
zB~UA&{hzSK@rZvYVueD8<W`}vq3Kc2ay7xcKy#KGU(7Rd&NZbA-gHGNBjstS@@vmK
zn*mjaa6w=F)b%thc^=_mv$Nbod$=>^SBp+q+oax`M#;U=PA=@^dY4b~WtgEH(xMux
z_2iq)Z&(c!{MlSN@i3VoKD$FUKt&@1dMKFtGKr#DklirpJT?JAJz{!a9Z0mHOb2%g
zot^VC+D?{Iyc=!spR=LO?{L3*F(x6QAlDQq!NK9D9dM#4c-A-JfD%43&!g(=S`PQ)
z^XpJ(I$UYP(%KXjqW-t4h?nopdMMKn=_uX9R;*_5^8e2T{}UKm%sY`61%Fv!n*epn
zJ*(Xs`ABulK@!}-3j@XT9$@qh`QOVuJ=CK>1XEs9Ukir08EM~-*{E#GtmL#|X(tmh
zK=I=MY5wonQolz59PK2}Z!fN+G9)!F>unXNFP$zbuT(p3PE^4KV;>~0uVSymh}WNf
zZxsK*>CE{#lbJ?eXIY?oNhr4G$(-J{5LbSa2uY}Wk-R{<W@R<(DS8`@HnoD=v3ZUu
z{rB7(w5p0vo)$o{O5OK?K}Y517WQup^K*ZUua72?Z!zrnROcvo@rrMXlroFOh*0@o
z0*uecMVzq7{A&E|a}UmXLCB3~m=&%}6Pk?^2J<Z-reKBdG{sp6(z5Iv+aOKEabo?w
z+=NN4$|7MJ3%4_;2sn@$CvYfQz$AA&`{M-^Z+|nMu?CO^p6$vF1{ncQFakH62t-xK
zNAUcj!wM}`)^fJHK6(rgdRIuuz4l@?dZnKeqx&w5AIX-04^2zZ6}}iCM2)`TI@R>l
zslIE70kgrmRsY)xVreaxsk+5y$i}m%O0r?*D$1p+77}R<0^4D7OCN;D<0^xSt6Atx
zGwsm-m%WznI}D#Yj%4z2a&!Nft9gU(koI`B7IeC?)a>kkz3Ruc&DhRTXx0BSfokCX
zs0x{IWtQ~6`E3y9ze3?7N&@q`WsCx|4tu6Z98G=E_<Pn%GP$;vblQDOO!eGMjuZ4_
zOnm+0;h|Htc_*chkB|TDNh=4!Z!A~T8169HR^;R7SK8bxy0u<aQxnCA7yY{dfuJ)t
zH;*0IN@pL>0TD#i2mkY234Oc=d1_LeEHq%%bzKm=f4uiwonH+)MMwmq_CFWJ^jev9
z`ns-6lxgKf_w<bR*0E~6f8Sd8;%1*k`W`i1CTrvD%v0#UiLVn0-iEo(pr5M`x%DlZ
zcj`IL!r$57udsK~mRtVpy4;fZAz-pZ$-%{?4~s-PY_Z9H>+avBMDSmM7Pr;-bPgS-
zKodZ2VO>)bdC;F@nrmSty<*Pz%Ak<L%5q(O{fOGy=N~_Q{QTg16XH-=U;h*xT?KP<
zx+rjawL!Ty?CV!<3d(8=1T918onU-?JUimg;cS(0r!U{1({=YD=i$cuhzW;5c@yHa
z+O_{qJ?gje4)@RTVky2b07O9nYi_1!U4Jh{lk@@4;hFb75;k+4C+@B+Q61XS2X~yV
z54eO1fiX_B(19)Qw%2m3F>6mFRFMlZP*6~)JhdOsA3_z<2t!jg?g+j8{KSWchjk4N
z#l}l_el$ZT3TqB(u0CfRF#f~a54rsVYi*@MAP|31(>h*<rXyMWIw9Yj=bx8d*LNpv
z>lIJO*dbo?%UT=_aTIBWtWQlv81t6h1}f<xr=~V(I4>?9AXqk=`Vts2*jEcS$ySSv
zc7U*r4XbL?W&$a{-}&$oF$g5SK+4a0_UmhEdip=3_x#57Z_VtdpG>R;9`Sw3$}0W*
z88|jJR=X}$16tbNK*!+&8cX>yL6k<dW<5<4FB1IL0&sbZYBg&>?;rl{?H?Rib^p$?
zd><$3JogKAFx^p?&Z_1W<^FK@&%xF8XUO$x`R#+x(cBk;FNQUyQ8zb%uU@}~q4Si*
zZ`ogIP=0pOx?WOO=e}}l5qj_AvQQr$Hm;PBk-<cn0E59WIJENt02B&Ejp<(kfj}C6
zRF_Ye>y(z3vhX15x^K9N>7`@029j<3{i$(@!QaENa2tI$`}_M>u8}e_G7Fu4{IwPc
z2$$Q;vpMK!cDM>d2<QpbbJSh4P-SBy*?RCLQH$$xbY>=HzLcN#rO(dJj{im!)!CE=
z|A9qaZ7nfF@EOMYe>+qLuJ1<pS_Nj!|ARznDOMfg53TR<f?(wmKeo>M7r(o2-K0@S
z1>;sXI=9XfvH9>8L}qDM7g+Wlm0p?0!_Uu<HGXl}Yz#^scz5^rUGU@mwM6KHGywsD
z$F!EX)xp#k<1T+evN&Kw&-N#F5P?bI$_2W-vpi7ydT7{eCCfg@$;)Hxj^)J+538>P
z>=k5-jpcB_0?L9v?LBv_vq*5{9Gy_{@e%!6RV5l)v?kBZ%`Ht1LD&70tE;Puy1Hwn
z3VSJJ3<*PjcgU^Bzl$9;g-*!lClLaUF;Nis?S`r0?D~50USW`%S!N^}Z0K$hi_WXb
zrQgA?`cG1USEhj-{^!g~OG{@*b>Fnrmx)M7O6%%KibDR-;Nalsb2Vw@iIL`f+Bqw8
za&po)Npj)l<NMk30aws@j#nsOZSqI_nDt^Ih&bkaGl9PZUC!t%+lpKu*Ji0KgToO)
z*G^@}WjaMk@$m$)C9&V`Puy*JWwGc8qC~z;d~wG3o-gTjc6T{J?$}Q6DIy|*p07bq
zD0#oLBul5I&ogT=k(j@J9ksT$mfuYo#~#J{A4$^SKwe}sI;WbE^MsDdkzA1@S+Dzs
z8HADO(5oA=wX+*OWQYHLw2G`&_tg4-jU5Xg^{A?wZWi`$fRvEPgIE&q%UdPCTEo*!
zxlI`8efnV4_<ZOc&BpjsBo>Ft`7-In6zd*pIaLBpqDxpJ0B<ppv<$VRAx`(`@E6xt
zc!5itD8|LQ!WOIi+rU1HVvJu^d>`5ZGtsZzdS4xLb}v~=(+XgtenkPTAH66_=N+$7
z`YcQ5(}RgDR3)(Bw1MEDOInknKJ$UKE~vyzJ)sC7|85)daL*m!L?%0NcWP9(xy>=J
zW!dZbZ+}Rqb_==012RbG9T<(7vuFScQx(siZCR37mL1~`eF|KPKCg@6&m$I|`Wf6p
zSGCJK)|*CTHChED+F=d3_hn5Q-<5yPxQqk;ie^m8+UI?D9l@Vo?dlz+0$86UYWwv~
zc7`q>35t*8%6VRa<%Tw;N4rF0b=3g>HUQ1XAiZFLaM%Oz;VuAlFI#Uk7C`GjHpDf_
sZt`C;NRh1n6KI-bE>`<bG#WgTFr20ZTb_|v0nnG4lD1;)%eN8#2U^3?i2wiq
diff --git a/t/test9200b.png b/t/test9200b.png
new file mode 100644
index 0000000000000000000000000000000000000000..ac22ccbd3ee9f03a3b38249ac8efdbe96b5da2cd
GIT binary patch
literal 275
zc%17D@N?(olHy`uVBq!ia0vp^9zZP3!VDyJZ(h*_aRPioToo7?5)xuJtY5{@z;N#D
z@dFGDFJ3(R{{7qk|No7uYm$J<7)yfuf*Bm1-ADs*lDyqr7&=&GL8fsQctjR6FmMZl
zFeAgPITAoY_7YEDSN3bH%%X-S`j4JZ016d)x;TbtoKN<6ufXCZA)&>gl@*-uLV<^+
zZOfu-7cOu}w0W9H3$HwJqlx472Q4Ervph31wm>lpQB&rr2^-hlWNOq5Vkv20<q=-Z
z@v30LY2AXTcBx4_L=O5$-0^JfxTAF7fm=Y}A_nHk3XTg7IPfqqTq@aCrp)Sh2xvKj
Mr>mdKI;Vst05+voj{pDw
--
1.4.2
^ 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