* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Nicolas Pitre @ 2008-11-19 14:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <49240F6D.3030203@viscovery.net>
On Wed, 19 Nov 2008, Johannes Sixt wrote:
> Nicolas Pitre schrieb:
> > On Wed, 19 Nov 2008, Johannes Sixt wrote:
> >
> >> Alex Riesen schrieb:
> >>> The opened packs seem to stay open forever.
> >> In my MinGW port I have the patch below that avoids that t5303 fails
> >> because of a pack file that remains open. (Open files cannot be replaced
> >> on Windows.) I had hoped that your patch would help, but it does not.
> >> Something else still keeps the pack file open. Can anything be done about
> >> that?
> >>
> >> -- Hannes
> >>
> >> From: Johannes Sixt <j6t@kdbg.org>
> >> Date: Mon, 17 Nov 2008 09:25:19 +0100
> >> Subject: [PATCH] t5303: Do not overwrite an existing pack
> >>
> ...
> > Acked-by: Nicolas Pitre <nico@cam.org>
>
> Thanks, but I should have mentioned that at this time this patch was just
> meant for exposition, not inclusion.
Well, I'd include it right away since it is fundamentally the right
thing to do.
> I'd prefer a solution to the problem that the pack file remains open. Do
> you have an idea where git-pack-objects keeps the pack file open, even
> with Alex's two patches applied?
That's not the issue.
The test is using pack-objects to overwrite a pack file, but to do so
pack-objects has to open and read from the pack file about to be
overwritten. This is just wrong even if it happens to work by luck on
Linux.
It is on purpose that the pack files are kept open. This is to minimize
the number of open() and mmap()/read() operations between successive
object reads. Those are not leaked file handles since they get closed
when new packs are opened and the number of concurrent opened packs
reaches a certain limit.
Nicolas
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Alex Riesen @ 2008-11-19 14:17 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Nicolas Pitre, Junio C Hamano, Git Mailing List
In-Reply-To: <49241AEF.1080808@viscovery.net>
2008/11/19 Johannes Sixt <j.sixt@viscovery.net>:
> Alex Riesen schrieb:
>> 2008/11/19 Nicolas Pitre <nico@cam.org>:
>>> On Wed, 19 Nov 2008, Johannes Sixt wrote:
>>>> The work-around is to write the repacked objects to a file of a different
>>>> name, and replace the original after git-pack-objects has terminated.
>>>>
>>>> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
>>> Acked-by: Nicolas Pitre <nico@cam.org>
>>
>> Are you sure? Will it work in a real repository? Were noone does
>> rename the previous pack files into packtmp-something?
>
> Oh, the patch only works around the failure in the test case. In a real
> repository there is usually no problem because the destination pack file
> does not exist.
>
> The unusual case is where you do this:
>
> $ git rev-list -10 HEAD | git pack-objects foobar
>
> twice in a row: In this case the second invocation fails on Windows
> because the destination pack file already exists *and* is open. But not
> even git-repack does this even if it is called twice. OTOH, the test case
> *does* exactly this.
>
Still bad...
BTW, the patch _does_ fix the "unusual case" for me. IOW, I plainly copied
your rev-list|pack-objects into command line. As expected, it fails for Junio's
master (after the second run) and works with the patch:
$ git rev-list -10 HEAD | ./git pack-objects .git/objects/pack/foobar
Counting objects: 10, done.
Compressing objects: 100% (9/9), done.
82864ec14cd06e6089543a1419762e4cd40f7988
Writing objects: 100% (10/10), done.
Total 10 (delta 1), reused 10 (delta 1)
$ git rev-list -10 HEAD | ./git pack-objects .git/objects/pack/foobar
Counting objects: 10, done.
Compressing objects: 100% (9/9), done.
fatal: unable to rename temporary pack file: Permission denied
$ git cherry-pick fix-fd-leak
Finished one cherry-pick.
[master]: created e629465: "Fix handle leak in builtin-pack-objects"
1 files changed, 1 insertions(+), 0 deletions(-)
$ git rev-list -10 HEAD | ./git pack-objects .git/objects/pack/foobar
Counting objects: 10, done.
Compressing objects: 100% (9/9), done.
0e43d919a2a8336fd740d8d9b8f9f78d49e855e5
Writing objects: 100% (10/10), done.
Total 10 (delta 1), reused 9 (delta 1)
$ git rev-list -10 HEAD | ./git pack-objects .git/objects/pack/foobar
Counting objects: 10, done.
Compressing objects: 100% (9/9), done.
0e43d919a2a8336fd740d8d9b8f9f78d49e855e5
Writing objects: 100% (10/10), done.
Total 10 (delta 1), reused 10 (delta 1)
$ git rev-list -10 HEAD | ./git pack-objects .git/objects/pack/foobar
Counting objects: 10, done.
Compressing objects: 100% (9/9), done.
0e43d919a2a8336fd740d8d9b8f9f78d49e855e5
Writing objects: 100% (10/10), done.
Total 10 (delta 1), reused 10 (delta 1)
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Johannes Sixt @ 2008-11-19 13:55 UTC (permalink / raw)
To: Alex Riesen; +Cc: Nicolas Pitre, Junio C Hamano, Git Mailing List
In-Reply-To: <81b0412b0811190534r4f71f981s53de415f79e56e25@mail.gmail.com>
Alex Riesen schrieb:
> 2008/11/19 Nicolas Pitre <nico@cam.org>:
>> On Wed, 19 Nov 2008, Johannes Sixt wrote:
>>> The work-around is to write the repacked objects to a file of a different
>>> name, and replace the original after git-pack-objects has terminated.
>>>
>>> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
>> Acked-by: Nicolas Pitre <nico@cam.org>
>
> Are you sure? Will it work in a real repository? Were noone does
> rename the previous pack files into packtmp-something?
Oh, the patch only works around the failure in the test case. In a real
repository there is usually no problem because the destination pack file
does not exist.
The unusual case is where you do this:
$ git rev-list -10 HEAD | git pack-objects foobar
twice in a row: In this case the second invocation fails on Windows
because the destination pack file already exists *and* is open. But not
even git-repack does this even if it is called twice. OTOH, the test case
*does* exactly this.
-- Hannes
^ permalink raw reply
* Re: How to make public repository GIT_DIR=my-git.git git-init Command not found.
From: Alex Riesen @ 2008-11-19 13:38 UTC (permalink / raw)
To: garyyang6; +Cc: git
In-Reply-To: <138223.4849.qm@web37905.mail.mud.yahoo.com>
2008/11/19 Gary Yang <garyyang6@yahoo.com>:
> Hi,
>
> I want to make a public repository. I followed the instructions in gitcore-tutorial.
> I typed "GIT_DIR=my-git.git git init" per instruction. But, I got command not found.
> I do not think this is the correct command. How should I do? I use C-Shell.
git --bare init
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Alex Riesen @ 2008-11-19 13:34 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Sixt, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811190753420.27509@xanadu.home>
2008/11/19 Nicolas Pitre <nico@cam.org>:
> On Wed, 19 Nov 2008, Johannes Sixt wrote:
>> The work-around is to write the repacked objects to a file of a different
>> name, and replace the original after git-pack-objects has terminated.
>>
>> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
>
> Acked-by: Nicolas Pitre <nico@cam.org>
>
Are you sure? Will it work in a real repository? Were noone does
rename the previous pack files into packtmp-something?
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Alex Riesen @ 2008-11-19 13:30 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811190740570.27509@xanadu.home>
2008/11/19 Nicolas Pitre <nico@cam.org>:
> On Wed, 19 Nov 2008, Alex Riesen wrote:
>
>> The opened packs seem to stay open forever.
>>
>> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
>> ---
>>
>> I'm very unsure about the solution, though: it is really horrible code
>> to debug...
>
> What is the actual problem? Pack windows are left open on purpose.
>
* expecting success: do_repack &&
git prune-packed -v &&
git verify-pack ${pack}.pack &&
git cat-file blob $blob_1 > /dev/null &&
git cat-file blob $blob_2 > /dev/null &&
git cat-file blob $blob_3 > /dev/null
Counting objects: 3, done.
error: unknown object type 0 at offset 2032 in
.git/objects/pack/pack-8d1e04fc992cfbdb3ab72cf7abbf08cce8b1900.pack
Compressing objects: 100% (2/2), done.
fatal: unable to rename temporary pack file
.git/objects/pack/tmp_pack_s9Gijm->.git/objects/pack/pack-b8d1e04fc992cfbdbab72cf7abbf08cce8b1900.pack:
Permission denied
* FAIL 10: ... and then a repack "clears" the corruption
do_repack &&
git prune-packed -v &&
git verify-pack ${pack}.pack &&
git cat-file blob $blob_1 > /dev/null &&
git cat-file blob $blob_2 > /dev/null &&
git cat-file blob $blob_3 > /dev/null
^ permalink raw reply
* Re: git and mtime
From: Jakub Narebski @ 2008-11-19 13:29 UTC (permalink / raw)
To: Roger Leigh; +Cc: git
In-Reply-To: <20081119113752.GA13611@ravenclaw.codelibre.net>
Roger Leigh <rleigh@codelibre.net> writes:
> Would it be possible for git to store the mtime of files in the tree?
>
> This would make it possible to do this type of work in git, since it's
> currently a bit random as to whether it works or not. This only
> started when I upgraded to an amd64 architecture from powerpc32,
> I guess it's maybe using high-resolution timestamps.
I don't think it would be done as in core change at all, or at least
soon.
You can use Metastore, or some custom clean/smudge gitattribute
filters with something like Metastore (or etckeeper) to store extra
metadata about files in your tree.
See http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git commit won't add an untracked file given on the command line
From: Junio C Hamano @ 2008-11-19 13:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mark Burton, git
In-Reply-To: <alpine.DEB.1.00.0811191226530.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 19 Nov 2008, Mark Burton wrote:
>
>> Having said that, I still like the concept of being able to add named
>> files without touching the index.
>
> That's just impossible. You cannot create a tree object, let alone a
> commit object, without touching the index (AKA staging area).
I do not think Mark really _means_ "not in the index".
The wish is more like "I want to let git know that I am interested in this
path, but I'm not ready to say what exact content I want for that path in
the next commit, not just yet".
I do not think that is an unreasonable wish. On the other hand, it is
unreasonable for anybody to insist that we satisfy the wish without
touching the index. The index is the most natural place to do that.
We have a half (probably a quarter) of what we need for that implemented
already, by the way.
^ permalink raw reply
* Re: [PATCH] Fix deletion of last character in levenshtein distance
From: Junio C Hamano @ 2008-11-19 13:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Samuel Tardieu, git
In-Reply-To: <alpine.DEB.1.00.0811191053250.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Okay, I understand now, _after_ having looked at the original
> levenshtein.c.
>
> IOW you could have made my task of reviewing your patch much easier.
>
> Anyway, here is my
>
> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> Thanks for the bugfix,
In other words, even the original author's head exploded without looking
at extra context lines around the patch.
It is a sure sign that the original implementation was too scantily
described, and that the fix was not explained well in the proposed commit
log message (i.e. in what corner cases the original was bad in what way,
and how the patch fixes it).
I shouldn't have to decipher the original and the fixed version with
pencil and paper when re-reviewing Dscho's Ack.
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Johannes Sixt @ 2008-11-19 13:06 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811190753420.27509@xanadu.home>
Nicolas Pitre schrieb:
> On Wed, 19 Nov 2008, Johannes Sixt wrote:
>
>> Alex Riesen schrieb:
>>> The opened packs seem to stay open forever.
>> In my MinGW port I have the patch below that avoids that t5303 fails
>> because of a pack file that remains open. (Open files cannot be replaced
>> on Windows.) I had hoped that your patch would help, but it does not.
>> Something else still keeps the pack file open. Can anything be done about
>> that?
>>
>> -- Hannes
>>
>> From: Johannes Sixt <j6t@kdbg.org>
>> Date: Mon, 17 Nov 2008 09:25:19 +0100
>> Subject: [PATCH] t5303: Do not overwrite an existing pack
>>
...
> Acked-by: Nicolas Pitre <nico@cam.org>
Thanks, but I should have mentioned that at this time this patch was just
meant for exposition, not inclusion. [It's just one of many, many patches
needed to make the test suite pass on MinGW.]
I'd prefer a solution to the problem that the pack file remains open. Do
you have an idea where git-pack-objects keeps the pack file open, even
with Alex's two patches applied?
-- Hannes
^ permalink raw reply
* Re: [PATCH 5/9] update-index: add --checkout/--no-checkout to update CE_NO_CHECKOUT bit
From: Jeff King @ 2008-11-19 13:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nguyễn Thái Ngọc Duy, git, Shawn O. Pearce
In-Reply-To: <7v4p24tq59.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 18, 2008 at 06:18:10PM -0800, Junio C Hamano wrote:
> Having said all that, I wouldn't suggest redoing the patch using >>
> redirection. But change from "touch 1 nondigit" to "touch nondigit 1"
> is a bit too subtle to my taste. Let's write it this way instead:
Yes, I also dislike the subtlety, but my "obvious" idea was something
like:
for i in 1 2 sub/1 sub/2; do
touch $i
done
which just seemed clunky. But:
> - touch 1 2 sub/1 sub/2 &&
> + touch ./1 ./2 sub/1 sub/2 &&
this is less clunky, and I have confirmed that it solves the problem. I
just wasn't clever enough to think of it in the first place. ;)
-Peff
^ permalink raw reply
* Re: git bisect do not work when good reversion is newer than bad reversion
From: Junio C Hamano @ 2008-11-19 13:00 UTC (permalink / raw)
To: Cai, Crane; +Cc: git
In-Reply-To: <6077B97E85E7374DAE87B42B5AA997970D0B12@sshaexmb1.amd.com>
"Cai, Crane" <Crane.Cai@amd.com> writes:
> Hi Junio,
>
> Sorry to disturb you. Here the requirement I met can not find answer
> from website. That's why I directly ask you.
>
> I need to use "git bisect" to find what patch can fix a problem.
> I found v2.6.25 has this problem.
> And v2.6.26 does NOT has this problem.
>
> Then I use bisect as this:
>
> #git bisect start
> #git bisect good v2.6.26
> #git bisect bad v2.6.25
>
> No reversion cut via these steps. Do you know whether git command can
> achieve this requirement or not?
You can use "git bisect" to find a single change that fixed the issue
(_provided if_ such a single change exists). There is a small mental
trick you need to exercise.
First, realize that bisect is about "it used to be like this, but later it
turned into that. Where did that single transition from this to that
happened"? Usually, "this" is "had this particular bug and was broken"
and "that" is "that bug was fixed and things work smoothly". In your
case, however, "this" is "broken" and "that" is "fixed". IOW, the
question you ask "bisect" is "it used to be broken but later it was fixed;
where did that exactly happen?".
The mental trick is to swap "good" and "bad" in order to adjust to your
use, because you are using bisect in a reverse way from the usual. Usual
case uses "good" mark "this" while "bad" is used to mark "that" in the
sentence "it used to be like this, but later it turned into that".
So what you would do is...
(1) First of all, write on a piece of paper:
good - the version _STILL_ has the bug.
bad - the version does not have the bug _ANYMORE_
(2) Start with "git bisect v2.6.25 v2.6.26";
(3) As you test each revision, look at the memo you made. Say
"good" if it still has the bug you are interested in; say
"bad" if it does not have the bug anymore..
cf. http://thread.gmane.org/gmane.comp.version-control.git/86063
By the way, I usually drop requests-for-help on the floor unless it is
CC'ed to the mailing list, because my time spent on writing the response
like this message will be wasted and wouldn't help the git community at
all. I simply do not have enough time to give unpaid support for
individuals. I am making exception this time only because I am waiting
for something and I happen to have nothing else to do while doing so.
Please send this kind of request-for-help to <git@vger.kernel.org>, the
main mailing list, to which anybody can send messages without subscribing.
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Nicolas Pitre @ 2008-11-19 12:55 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <4923FE58.3090503@viscovery.net>
On Wed, 19 Nov 2008, Johannes Sixt wrote:
> Alex Riesen schrieb:
> > The opened packs seem to stay open forever.
>
> In my MinGW port I have the patch below that avoids that t5303 fails
> because of a pack file that remains open. (Open files cannot be replaced
> on Windows.) I had hoped that your patch would help, but it does not.
> Something else still keeps the pack file open. Can anything be done about
> that?
>
> -- Hannes
>
> From: Johannes Sixt <j6t@kdbg.org>
> Date: Mon, 17 Nov 2008 09:25:19 +0100
> Subject: [PATCH] t5303: Do not overwrite an existing pack
>
> This test corrupts a pack file, then repacks the objects. The consequence
> is that the repacked pack file has the same name as the original file
> (that has been corrupted).
>
> During its operation, git-pack-objects opens the corrupted file and keeps
> it open at all times. On Windows, this is a problem because a file that is
> open in any process cannot be delete or replaced, but that is what we do
> in some of the test cases, and so they fail.
>
> The work-around is to write the repacked objects to a file of a different
> name, and replace the original after git-pack-objects has terminated.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Acked-by: Nicolas Pitre <nico@cam.org>
> ---
> t/t5303-pack-corruption-resilience.sh | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/t/t5303-pack-corruption-resilience.sh
> b/t/t5303-pack-corruption-resilience.sh
> index 5132d41..41c83e3 100755
> --- a/t/t5303-pack-corruption-resilience.sh
> +++ b/t/t5303-pack-corruption-resilience.sh
> @@ -43,8 +43,11 @@ create_new_pack() {
>
> do_repack() {
> pack=`printf "$blob_1\n$blob_2\n$blob_3\n" |
> - git pack-objects $@ .git/objects/pack/pack` &&
> - pack=".git/objects/pack/pack-${pack}"
> + git pack-objects $@ .git/objects/pack/packtmp` &&
> + packtmp=".git/objects/pack/packtmp-${pack}" &&
> + pack=".git/objects/pack/pack-${pack}" &&
> + mv "${packtmp}.pack" "${pack}.pack" &&
> + mv "${packtmp}.idx" "${pack}.idx"
> }
>
> do_corrupt_object() {
> --
> 1.6.0.4.1683.g35125
>
>
Nicolas
^ permalink raw reply
* Re: [PATCH] Fix handle leak in sha1_file/unpack_objects if there were damaged object data
From: Nicolas Pitre @ 2008-11-19 12:49 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <81b0412b0811190314k92a0acbn3ea820cce2a7a40b@mail.gmail.com>
On Wed, 19 Nov 2008, Alex Riesen wrote:
> In the case of bad packed object CRC, unuse_pack wasn't called after
> check_pack_crc which calls use_pack.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Acked-by: Nicolas Pitre <nico@cam.org>
> ---
> sha1_file.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
Nicolas
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Nicolas Pitre @ 2008-11-19 12:45 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <81b0412b0811190313p643c0cb4vad620ea942aeea93@mail.gmail.com>
On Wed, 19 Nov 2008, Alex Riesen wrote:
> The opened packs seem to stay open forever.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
>
> I'm very unsure about the solution, though: it is really horrible code
> to debug...
What is the actual problem? Pack windows are left open on purpose.
Nicolas
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Johannes Sixt @ 2008-11-19 12:26 UTC (permalink / raw)
To: Alex Riesen; +Cc: Nicolas Pitre, Junio C Hamano, Git Mailing List
In-Reply-To: <81b0412b0811190413s29644092y86d1c8840e10c28b@mail.gmail.com>
Alex Riesen schrieb:
> 2008/11/19 Johannes Sixt <j.sixt@viscovery.net>:
>> Alex Riesen schrieb:
>>> The opened packs seem to stay open forever.
>> In my MinGW port I have the patch below that avoids that t5303 fails
>> because of a pack file that remains open. (Open files cannot be replaced
>> on Windows.) I had hoped that your patch would help, but it does not.
>> Something else still keeps the pack file open. Can anything be done about
>> that?
>>
>
> Do this _and_ the other handle-leak-patch together help?
> (I think the second should)
No, that doesn't help, either. :-(
-- Hannes
^ permalink raw reply
* Re: git and mtime
From: Johannes Schindelin @ 2008-11-19 12:31 UTC (permalink / raw)
To: Roger Leigh; +Cc: git
In-Reply-To: <20081119113752.GA13611@ravenclaw.codelibre.net>
Hi,
On Wed, 19 Nov 2008, Roger Leigh wrote:
> Would it be possible for git to store the mtime of files in the tree?
No, since this would wreck people's workflows:
- compile in branch "master"
- switch to branch "topic"
- compile
- switch back to branch "master"
Now you _want_ files in "master" that were changed in "topic" to be
recompiled.
This is a quite common case.
However, nothing hinders you having your own ".gitmtimes" in the tree, and
a script people can use as a hook, which applies the mtimes to the files.
Ciao,
Dscho
^ permalink raw reply
* Re: git and mtime
From: Matthias Kestenholz @ 2008-11-19 12:22 UTC (permalink / raw)
To: Roger Leigh; +Cc: git
In-Reply-To: <20081119113752.GA13611@ravenclaw.codelibre.net>
Hi,
On 19.11.2008, at 12:37, Roger Leigh wrote:
> Hi folks,
>
> I'm using git to store some generated files, as well as their sources.
> (This is in the context of Debian package development, where entire
> upstream release tarballs are injected into an upstream branch, with
> Debian releases merging the upstream branch, and adding the Debian
> packaging files.)
>
> The upstream release tarballs contains files such as
> - yacc/lex code, and the corresponding generated sources
> - Docbook/XML code, and corresponding HTML/PDF documentation
>
> These are provided by upstream so that end users don't need these
> tools
> installed (particularly docbook, since the toolchain is so flaky on
> different systems). However, the fact that git isn't storing the
> mtime of the files confuses make, so it then tries to regenerate these
> (already up-to-date) files, and fails in the process since the tools
> aren't available.
>
> Would it be possible for git to store the mtime of files in the tree?
>
This subject comes up from time to time, but the answer always
stays the same: No. The trees are purely defined by their content, and
that's by design.
If you do not want to regenerate files that are already up-to-date,
you need multiple checkouts of the same repository.
Thanks,
Matthias
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Alex Riesen @ 2008-11-19 12:13 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Nicolas Pitre, Junio C Hamano, Git Mailing List
In-Reply-To: <4923FE58.3090503@viscovery.net>
2008/11/19 Johannes Sixt <j.sixt@viscovery.net>:
> Alex Riesen schrieb:
>> The opened packs seem to stay open forever.
>
> In my MinGW port I have the patch below that avoids that t5303 fails
> because of a pack file that remains open. (Open files cannot be replaced
> on Windows.) I had hoped that your patch would help, but it does not.
> Something else still keeps the pack file open. Can anything be done about
> that?
>
Do this _and_ the other handle-leak-patch together help?
(I think the second should)
> From: Johannes Sixt <j6t@kdbg.org>
> Date: Mon, 17 Nov 2008 09:25:19 +0100
BTW, you better report such things. Even though it is typical
for this platform brokenness, leaking open files is never good.
^ permalink raw reply
* git and mtime
From: Roger Leigh @ 2008-11-19 11:37 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1558 bytes --]
Hi folks,
I'm using git to store some generated files, as well as their sources.
(This is in the context of Debian package development, where entire
upstream release tarballs are injected into an upstream branch, with
Debian releases merging the upstream branch, and adding the Debian
packaging files.)
The upstream release tarballs contains files such as
- yacc/lex code, and the corresponding generated sources
- Docbook/XML code, and corresponding HTML/PDF documentation
These are provided by upstream so that end users don't need these tools
installed (particularly docbook, since the toolchain is so flaky on
different systems). However, the fact that git isn't storing the
mtime of the files confuses make, so it then tries to regenerate these
(already up-to-date) files, and fails in the process since the tools
aren't available.
Would it be possible for git to store the mtime of files in the tree?
This would make it possible to do this type of work in git, since it's
currently a bit random as to whether it works or not. This only
started when I upgraded to an amd64 architecture from powerpc32,
I guess it's maybe using high-resolution timestamps.
Thanks,
Roger
P.S. The repo I'm working on here is at
git://git.debian.org/git/collab-maint/gutenprint.git
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Johannes Sixt @ 2008-11-19 11:54 UTC (permalink / raw)
To: Alex Riesen; +Cc: Nicolas Pitre, Junio C Hamano, Git Mailing List
In-Reply-To: <81b0412b0811190313p643c0cb4vad620ea942aeea93@mail.gmail.com>
Alex Riesen schrieb:
> The opened packs seem to stay open forever.
In my MinGW port I have the patch below that avoids that t5303 fails
because of a pack file that remains open. (Open files cannot be replaced
on Windows.) I had hoped that your patch would help, but it does not.
Something else still keeps the pack file open. Can anything be done about
that?
-- Hannes
From: Johannes Sixt <j6t@kdbg.org>
Date: Mon, 17 Nov 2008 09:25:19 +0100
Subject: [PATCH] t5303: Do not overwrite an existing pack
This test corrupts a pack file, then repacks the objects. The consequence
is that the repacked pack file has the same name as the original file
(that has been corrupted).
During its operation, git-pack-objects opens the corrupted file and keeps
it open at all times. On Windows, this is a problem because a file that is
open in any process cannot be delete or replaced, but that is what we do
in some of the test cases, and so they fail.
The work-around is to write the repacked objects to a file of a different
name, and replace the original after git-pack-objects has terminated.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
t/t5303-pack-corruption-resilience.sh | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/t/t5303-pack-corruption-resilience.sh
b/t/t5303-pack-corruption-resilience.sh
index 5132d41..41c83e3 100755
--- a/t/t5303-pack-corruption-resilience.sh
+++ b/t/t5303-pack-corruption-resilience.sh
@@ -43,8 +43,11 @@ create_new_pack() {
do_repack() {
pack=`printf "$blob_1\n$blob_2\n$blob_3\n" |
- git pack-objects $@ .git/objects/pack/pack` &&
- pack=".git/objects/pack/pack-${pack}"
+ git pack-objects $@ .git/objects/pack/packtmp` &&
+ packtmp=".git/objects/pack/packtmp-${pack}" &&
+ pack=".git/objects/pack/pack-${pack}" &&
+ mv "${packtmp}.pack" "${pack}.pack" &&
+ mv "${packtmp}.idx" "${pack}.idx"
}
do_corrupt_object() {
--
1.6.0.4.1683.g35125
^ permalink raw reply related
* Re: [PATCH] Retain multiple -q/-v occurrences in git pull
From: Constantine Plotnikov @ 2008-11-19 11:46 UTC (permalink / raw)
To: Tuncer Ayaz; +Cc: git, gitster
In-Reply-To: <1226959770-4252-1-git-send-email-tuncer.ayaz@gmail.com>
On Tue, Nov 18, 2008 at 1:09 AM, Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:
> To support counting -q/-v options in git pull retain
> them by concatenating.
>
[rest of message cut]
By the way, there is yet another way to invoke git fetch. It is "git
remote update". Possibly it should support "-v" and "-q" options for
consistency as well.
Regards,
Constantine
^ permalink raw reply
* Re: Git commit won't add an untracked file given on the command line
From: Johannes Schindelin @ 2008-11-19 11:27 UTC (permalink / raw)
To: Mark Burton; +Cc: git
In-Reply-To: <20081119095452.3018d2de@crow>
Hi,
On Wed, 19 Nov 2008, Mark Burton wrote:
> Having said that, I still like the concept of being able to add named
> files without touching the index.
That's just impossible. You cannot create a tree object, let alone a
commit object, without touching the index (AKA staging area).
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Fix t4030-diff-textconv.sh
From: Alex Riesen @ 2008-11-19 11:14 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 215 bytes --]
Avoid passing cygwin pathnames to Perl. Some Perls have problems using them
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
t/t4030-diff-textconv.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-t4030-diff-textconv.sh.patch --]
[-- Type: text/x-diff; name=0001-Fix-t4030-diff-textconv.sh.patch, Size: 798 bytes --]
From e8562487da0336f0f16832e72264f98879e0394b Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Tue, 18 Nov 2008 11:39:46 +0100
Subject: [PATCH] Fix t4030-diff-textconv.sh
Avoid passing cygwin pathnames to Perl. Some Perls have problems using them
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
t/t4030-diff-textconv.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t4030-diff-textconv.sh b/t/t4030-diff-textconv.sh
index 03ba26a..0b76e7c 100755
--- a/t/t4030-diff-textconv.sh
+++ b/t/t4030-diff-textconv.sh
@@ -21,7 +21,7 @@ EOF
cat >hexdump <<'EOF'
#!/bin/sh
-perl -e '$/ = undef; $_ = <>; s/./ord($&)/ge; print $_' "$1"
+perl -e '$/ = undef; $_ = <>; s/./ord($&)/ge; print $_' < "$1"
EOF
chmod +x hexdump
--
1.6.0.4.644.gb619a
^ permalink raw reply related
* [PATCH] Fix handle leak in sha1_file/unpack_objects if there were damaged object data
From: Alex Riesen @ 2008-11-19 11:14 UTC (permalink / raw)
To: Nicolas Pitre, Junio C Hamano, Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 231 bytes --]
In the case of bad packed object CRC, unuse_pack wasn't called after
check_pack_crc which calls use_pack.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
sha1_file.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-Fix-handle-leak-in-sha1_file-unpack_objects-if-there.patch --]
[-- Type: text/x-diff; name=0002-Fix-handle-leak-in-sha1_file-unpack_objects-if-there.patch, Size: 846 bytes --]
From 3b4c13ddeebe4bc54a3f9ab9bd26909cc5e1eff3 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Wed, 19 Nov 2008 11:17:13 +0100
Subject: [PATCH] Fix handle leak in sha1_file/unpack_objects if there were damaged object data
In the case of bad packed object CRC, unuse_pack wasn't called after
check_pack_crc which calls use_pack.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
sha1_file.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 75a748a..0106e2c 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1749,6 +1749,7 @@ void *unpack_entry(struct packed_git *p, off_t obj_offset,
error("bad packed object CRC for %s",
sha1_to_hex(sha1));
mark_bad_packed_object(p, sha1);
+ unuse_pack(&w_curs);
return NULL;
}
}
--
1.6.0.4.644.gb619a
^ 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