* [TopGit PATCH] Check for help invocation before setup
From: martin f. krafft @ 2008-11-19 16:03 UTC (permalink / raw)
To: git; +Cc: martin f. krafft
In-Reply-To: <1227110623-4474-1-git-send-email-madduck@debian.org>
The user ought to be able to call `tg help` from anywhere in the
filesystem, not just Git repositories, so the help parsing has to happen
before the calls to git git binary.
Debian bug: #501982
Signed-off-by: martin f. krafft <madduck@debian.org>
---
tg.sh | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/tg.sh b/tg.sh
index 2961106..40c4ab7 100644
--- a/tg.sh
+++ b/tg.sh
@@ -235,6 +235,20 @@ do_help()
fi
}
+## Startup
+
+args_saved="$@"
+while [ -n "$1" ]; do
+ case "$1" in
+ help|--help|-h)
+ shift
+ do_help "$1"
+ exit 1;;
+ esac
+ shift
+done
+set -- $args_saved
+unset args_saved
## Initial setup
@@ -268,9 +282,6 @@ cmd="$1"
shift
case "$cmd" in
-help|--help|-h)
- do_help "$1"
- exit 1;;
--hooks-path)
# Internal command
echo "@hooksdir@";;
--
1.6.0.2
^ permalink raw reply related
* [TopGit PATCH] Check for cmddir earlier
From: martin f. krafft @ 2008-11-19 16:03 UTC (permalink / raw)
To: git; +Cc: martin f. krafft
In-Reply-To: <1227110623-4474-3-git-send-email-madduck@debian.org>
Without cmddir, tg is basically useless, even do_help() needs it, so
check it first and die hard if not found
Signed-off-by: martin f. krafft <madduck@debian.org>
---
tg.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tg.sh b/tg.sh
index ea22544..f3d1323 100644
--- a/tg.sh
+++ b/tg.sh
@@ -237,6 +237,9 @@ do_help()
## Startup
+[ -d "@cmddir@" ] ||
+ die "No command directory: '@cmddir@'"
+
args_saved="$@"
while [ -n "$1" ]; do
case "$1" in
@@ -263,9 +266,6 @@ tg="tg"
setup_ours
setup_hook "pre-commit"
-[ -d "@cmddir@" ] ||
- die "No command directory: '@cmddir@'"
-
## Dispatch
# We were sourced from another script for our utility functions;
--
1.6.0.2
^ permalink raw reply related
* [TopGit PATCH] Print help output when no command is given
From: martin f. krafft @ 2008-11-19 16:03 UTC (permalink / raw)
To: git; +Cc: martin f. krafft
In-Reply-To: <1227110623-4474-4-git-send-email-madduck@debian.org>
As much as I love your message (although you really ought not be
throwing around ducks!), this is more user-friendly.
Signed-off-by: martin f. krafft <madduck@debian.org>
---
tg.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tg.sh b/tg.sh
index f3d1323..e0d62e7 100644
--- a/tg.sh
+++ b/tg.sh
@@ -278,7 +278,7 @@ if [ "$1" = "-r" ]; then
fi
cmd="$1"
-[ -n "$cmd" ] || die "He took a duck in the face at two hundred and fifty knots"
+[ -n "$cmd" ] || { do_help; exit 1; }
shift
case "$cmd" in
--
1.6.0.2
^ permalink raw reply related
* [TopGit PATCH] Change tg help exit code to 0
From: martin f. krafft @ 2008-11-19 16:03 UTC (permalink / raw)
To: git; +Cc: martin f. krafft
In-Reply-To: <1227110623-4474-2-git-send-email-madduck@debian.org>
Printing --help is not an error, but a successful operation, if the help
output could be printed.
Signed-off-by: martin f. krafft <madduck@debian.org>
---
tg.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tg.sh b/tg.sh
index 40c4ab7..ea22544 100644
--- a/tg.sh
+++ b/tg.sh
@@ -243,7 +243,7 @@ while [ -n "$1" ]; do
help|--help|-h)
shift
do_help "$1"
- exit 1;;
+ exit 0;;
esac
shift
done
--
1.6.0.2
^ permalink raw reply related
* [TopGit] Improve help output
From: martin f. krafft @ 2008-11-19 16:03 UTC (permalink / raw)
To: git
The following patches improve the help output by TopGit. They are
not all related, but they conflict.
I would just push them to the master branch, but I don't want to
risk my chances of Petr getting angry with his new release
assistant...
^ permalink raw reply
* Re: "secret key not available". "unable to sign the tag".
From: Linus Torvalds @ 2008-11-19 15:42 UTC (permalink / raw)
To: Gary Yang; +Cc: Jeff King, Git Mailing List
In-Reply-To: <31942.12221.qm@web37902.mail.mud.yahoo.com>
On Tue, 18 Nov 2008, Gary Yang wrote:
>
> The gpg works. But, git tag dose not work. Any idea?
Does
git tag -u garyyang6@yahoo.com tag-name
work (ie when you use an explicitly given key to tag with)?
And if not, please do list the output of "gpg -K" if that doesn't work.
Linus
^ permalink raw reply
* Re: git and mtime
From: Matthieu Moy @ 2008-11-19 14:54 UTC (permalink / raw)
To: Arafangion; +Cc: Roger Leigh, git
In-Reply-To: <1227098252.11370.8.camel@therock.nsw.bigpond.net.au>
Arafangion <thestar@fussycoder.id.au> writes:
> You should probably fix your build script,
ccache should help:
http://ccache.samba.org/
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Johannes Sixt @ 2008-11-19 14:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811190940480.27509@xanadu.home>
Nicolas Pitre schrieb:
> On Wed, 19 Nov 2008, Johannes Sixt wrote:
>> 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.
>
> OK.... Well, despite my earlier assertion, I think the above should be a
> valid operation.
>
> I'm looking at it now. I'm therefore revoking my earlier ACK as well
> (better keep that test case alive).
Hold on a moment: When I tested the above sequence, I was fooled by a flaw
in mingw_rename() (it doesn't replace read-only files). With that fixed,
it works as expected in repeated invocations (note that foobar is outside
the .git/objects/pack directory).
If I use .git/objects/pack/foobar instead, then I get the failures on
Windows, and I won't argue that this should be "fixed". ;)
-- Hannes
^ permalink raw reply
* Re: git and mtime
From: Arafangion @ 2008-11-19 12:37 UTC (permalink / raw)
To: Roger Leigh; +Cc: git
In-Reply-To: <20081119113752.GA13611@ravenclaw.codelibre.net>
On Wed, 2008-11-19 at 11:37 +0000, Roger Leigh wrote:
<snip>
> 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.
Unless I'm mistaken, I was under the impression that the reason why git
doesn't, and shouldn't do this is _because_ it confuses make.
Suppose you've got two branches, and you check out the other branch,
resulting in changes in 3 files. Should git go and modify the mtime for
every single file, and remove any file that isn't part of the repo (Such
as generated object files)?
If it modifies the dates on every file, but doesn't remove the generated
object files, how does make handle that, as it'll likely generate some
of the object files, but not all of them.
If it doesn't, but touches the files that changed, and the dates are now
older than the corresponding object files, make would fail to recompile
the project properly!
The only way this could work is if you never switch branches, which is
quite limiting for git, and never check out an older revision, which is
quite limiting for the RCS systems in general.
You should probably fix your build script, or add a hook script that
sets the dates on the files in question manually, but the former
solution would be much better.
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Nicolas Pitre @ 2008-11-19 14:42 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <49241AEF.1080808@viscovery.net>
On Wed, 19 Nov 2008, Johannes Sixt wrote:
> 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.
OK.... Well, despite my earlier assertion, I think the above should be a
valid operation.
I'm looking at it now. I'm therefore revoking my earlier ACK as well
(better keep that test case alive).
Nicolas
^ permalink raw reply
* Re: Git commit won't add an untracked file given on the command line
From: Mark Burton @ 2008-11-19 14:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vd4grsveo.fsf@gitster.siamese.dyndns.org>
Hi,
> > 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.
Sorry, poor choice of words on my part - you have to remember my
viewpoint is one of user more than developer.
My wish was really just based on the advertised behaviour that
specifying a file on the command line would commit the contents of that
file while leaving the index intact. Whether the index was temporarily
used/altered during the execution of the commit didn't cross my mind.
Hey, it's not a big deal and with the accepted patch to the
documentation it need not take any more of anyone's time.
Cheers,
Mark
^ permalink raw reply
* 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
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