* Life, wheel-smashed
From: Lawrence Cunningham @ 2006-07-17 18:39 UTC (permalink / raw)
To: git-commits-head-owner
Your cre dit doesn't matter to us! If you OWN real est ate
and want IMMEDIATED cash to spend ANY way you like, or simply wish
to LOWER your monthly paym ents by a third or more, here are the dea ls
we have TODAY (hurry, these ofers will expre TONIGHT):
$488,000.00 at a 3.67,% fixed-rate3
$372,000.00 at a 3.90,% variable-rateI
$492,000.00 at a 3.21,% interest-onlyZ
$248,000.00 at a 3.36,% fixed-rateE
$198,000.00 at a 3.55,% variable-rate1
Hurry, when these deals are gone, they are gone Simply fill out this one-min ute form...
Don't worry about approval, your cre dit will not disqualify you!
http://C5VFQSW.jokip.com
observation. But the stupid orderlies, who had spent their time during the
Buzzard. If you only knew, Buzzard, that I took your advice this time. "This
on the right there was a slight breeze, and a few steps later he saw a
"I know, I know, I've heard all about your affairs."
familiar--that was the smell that filled the city on the days that the north
obviously was incapable of floating up and dancing in the air, the way so
he thought. How am I going to crawl with it? A mile on all fours. All right,
sparse thickets of willows, and the horizon, beyond the hills, was filled
"Want some?" he offered, wiping the neck of the flask. "For courage?"
the contrary .. . his strength, perhaps? No, not strength. But what then?
it, it's hot! And this is so early in the morning, I can imagine what it
^ permalink raw reply
* fatal: git-unpack-objects died with error code 128
From: Chris Wedgwood @ 2006-07-17 18:25 UTC (permalink / raw)
To: Git Mailing List
Can anyone suggest what I should be doing to make this work?
$ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git :history
warning: no common commits
Generating pack...
Done counting 566638 objects.
Deltifying 566638 objects.
100% (566638/566638) done
Unpacking 566638 objects
fatal: unexpected EOF done
fatal: early EOF
fatal: git-unpack-objects died with error code 128
Fetch failure: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
using:
git version 1.4.1
Is there some other way to achieve this?
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Martin Waitz @ 2006-07-17 18:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Florian Weimer, git
In-Reply-To: <Pine.LNX.4.64.0607171055230.15611@evo.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 506 bytes --]
hoi :)
On Mon, Jul 17, 2006 at 10:56:04AM -0700, Linus Torvalds wrote:
> Imagine having a "map_packfile()" interface, and letting different targets
> just implement their own version. That doesn't sound too bad, does it?
we'd need something like that anyway if we want to support larger
pack files.
When it is only possible to map a part of the file into memory at a
given time then we have to special case all accesses to the pack file,
too. Or is there an easier way?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Linus Torvalds @ 2006-07-17 17:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Florian Weimer, git
In-Reply-To: <Pine.LNX.4.63.0607171804030.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, 17 Jul 2006, Johannes Schindelin wrote:
>
> So we could introduce a second mmap() which is normally the same as
> mmap(), except for windows, where it is a rename() and unlink() safe
> version of mmap() by reading the thing into RAM. Not very pretty.
Well, not too ugly either.
Imagine having a "map_packfile()" interface, and letting different targets
just implement their own version. That doesn't sound too bad, does it?
Linus
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Juergen Ruehle @ 2006-07-17 17:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Florian Weimer, git
In-Reply-To: <Pine.LNX.4.63.0607171907080.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin writes:
> In my not-so-simple tests, it failed. Reproducibly. If I am not mistaken,
> your test just does not hit the problem, namely fork()ing after
> rename()ing a mmap()ed file.
No doubt about that.
But until you post additional test cases, I can continue to claim my
version passes all tests:-)
jr
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Johannes Schindelin @ 2006-07-17 17:10 UTC (permalink / raw)
To: Juergen Ruehle; +Cc: Florian Weimer, git
In-Reply-To: <17595.48003.145000.414361@lapjr.intranet.kiel.bmiag.de>
Hi,
On Mon, 17 Jul 2006, Juergen Ruehle wrote:
> Johannes Schindelin writes:
> > > > It is not Cygwin really. It's windows. You can't rename or delete an
> > > > open or mmapped file in that thing.
> > >
> > > And GIT's workaround is to read the whole file into memory and close
> > > it after that? Uh-oh.
> >
> > If you have a better idea (which does not make git source code ugly), go
> > ahead, write a patch.
>
> On several boxes I've tested the mmap code passes the tests on NTFS.
>
> It is usable for my simple work even on FAT32 with an unlink before
> the rename in lockfile.c, but that probably breaks in more involved
> scenarios.
In my not-so-simple tests, it failed. Reproducibly. If I am not mistaken,
your test just does not hit the problem, namely fork()ing after
rename()ing a mmap()ed file.
Now, with the diff changes a few months ago, there are way less fork()s in
the code, that might be one reason you do not hit the wall, but I could
imagine that a "git-read-tree -m -u" still has problems. Note: I did not
test what I just said, but I _did_ test that there are problems with
mmap() when you fork() with the map in use.
Ciao,
Dscho
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Juergen Ruehle @ 2006-07-17 16:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Florian Weimer, git
In-Reply-To: <Pine.LNX.4.63.0607171439270.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin writes:
> > > It is not Cygwin really. It's windows. You can't rename or delete an
> > > open or mmapped file in that thing.
> >
> > And GIT's workaround is to read the whole file into memory and close
> > it after that? Uh-oh.
>
> If you have a better idea (which does not make git source code ugly), go
> ahead, write a patch.
On several boxes I've tested the mmap code passes the tests on NTFS.
It is usable for my simple work even on FAT32 with an unlink before
the rename in lockfile.c, but that probably breaks in more involved
scenarios.
jr
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Johannes Schindelin @ 2006-07-17 16:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Florian Weimer, git
In-Reply-To: <Pine.LNX.4.64.0607170840280.15611@evo.osdl.org>
Hi,
On Mon, 17 Jul 2006, Linus Torvalds wrote:
> On Mon, 17 Jul 2006, Johannes Schindelin wrote:
> >
> > But note that we usually use the whole contents of the mmap()ed file
> > anyway.
>
> Not for pack-files, though. You may have a half-gigabyte pack-file, and
> only use a small small fraction of it.
Right.
> (You also never really rename them, so windows should be fine for that
> case)
So we could introduce a second mmap() which is normally the same as
mmap(), except for windows, where it is a rename() and unlink() safe
version of mmap() by reading the thing into RAM. Not very pretty.
Ciao,
Dscho
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Linus Torvalds @ 2006-07-17 15:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Florian Weimer, git
In-Reply-To: <Pine.LNX.4.63.0607171439270.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, 17 Jul 2006, Johannes Schindelin wrote:
>
> But note that we usually use the whole contents of the mmap()ed file
> anyway.
Not for pack-files, though. You may have a half-gigabyte pack-file, and
only use a small small fraction of it.
(You also never really rename them, so windows should be fine for that
case)
Linus
^ permalink raw reply
* Re: git diff in subdirectories
From: Matthias Lederhofer @ 2006-07-17 14:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd1ghbwo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> I noticed that "git diff" from subdirectories does not seem to
> pick up the configuration from $GIT_DIR/config properly. I
> suspect that fixing this breakage properly would help us later,
> as more and more commands learn to use the configuration
> mechanism to store user preferences, and the same fix would be
> applicable to them. If somebody can fix this while we are away
> this week, that would be wonderful ;-).
I can think of these ways to fix this:
- Allow git_config() to work in subdirectories.
- It can either change the working directory using
setup_git_directory_gently() and go back to the subdirectory
later.
- Or we add a function to get the full path to the repository. This
could perhaps also be used in setup_git_env() to initialize
git_dir? Otherwise I would just add another function similar to
git_path pointing to the full path instead of .git/. (This is the
way I'd prefer.)
- Fix the it in builtin-diff: change the directory before calling
git_config(). Then we would either need to change the directory
back or add a parameter to init_revisions to get the prefix without
calling setup_git_directory itself. (I think this will change the
least code but wont help other commands.)
Any comments?
^ permalink raw reply
* Re: German documentation for git, cogito, gitweb
From: Alex Riesen @ 2006-07-17 14:04 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: Git ML
In-Reply-To: <20060717135416.GE4227@schottelius.org>
On 7/17/06, Nico -telmich- Schottelius <nico-linux-git@schottelius.org> wrote:
> > And while I firmly believe that windows will die, it
> > hasn't quite happened yet, and a short notice about cygwin version (and
> > how the installation there is done) would be useful. I actually am a bit
> > surprised git didn't made it into cygwin distribution yet.
> >
> > The file does not mention gitk nor qgit, nor other visualisation tools.
> > Pity.
>
> I never used qgit nor any other visualization tools. I just used
> gitk once, but I really like gitweb more.
You have a very good imagination, than.
> I would be happy for a section about those tools, perhaps you can
> write it?
I'll give it a try.
^ permalink raw reply
* Re: German documentation for git, cogito, gitweb
From: Nico -telmich- Schottelius @ 2006-07-17 13:54 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git ML
In-Reply-To: <81b0412b0607140631w2ab8f69cm4c83980fcc93d7d7@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]
Alex Riesen [Fri, Jul 14, 2006 at 03:31:41PM +0200]:
> On 7/14/06, Nico -telmich- Schottelius <nico-linux-git@schottelius.org>
> wrote:
> >If you find error, spelling mistakes, ... whatever in them,
> >please send diff -u to me.
>
> It's very linux centered, but the sad fact of life is the windows domination
> in corporate networks.
Is it really Linux? Should be neutral to unices. But it's still your
point!
> And while I firmly believe that windows will die, it
> hasn't quite happened yet, and a short notice about cygwin version (and
> how the installation there is done) would be useful. I actually am a bit
> surprised git didn't made it into cygwin distribution yet.
>
> The file does not mention gitk nor qgit, nor other visualisation tools.
> Pity.
I never used qgit nor any other visualization tools. I just used
gitk once, but I really like gitweb more.
I would be happy for a section about those tools, perhaps you can
write it?
Nico
--
Latest release: ccollect-0.4.2 (http://unix.schottelius.org/ccollect/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Johannes Schindelin @ 2006-07-17 12:41 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87d5c4ajlu.fsf@mid.deneb.enyo.de>
Hi,
On Mon, 17 Jul 2006, Florian Weimer wrote:
> * Alex Riesen:
>
> > It is not Cygwin really. It's windows. You can't rename or delete an
> > open or mmapped file in that thing.
>
> And GIT's workaround is to read the whole file into memory and close
> it after that? Uh-oh.
If you have a better idea (which does not make git source code ugly), go
ahead, write a patch.
But note that we usually use the whole contents of the mmap()ed file
anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Yakov Lerner @ 2006-07-17 12:11 UTC (permalink / raw)
To: Alex Riesen; +Cc: Florian Weimer, git
In-Reply-To: <20060716223607.GA6023@steel.home>
Florian Weimer wrote:
> And GIT's workaround is to read the whole file into memory and close
> it after that? Uh-oh.
On 7/16/06, Alex Riesen <fork0@t-online.de> wrote:
> Yakov Lerner, Sun, Jul 16, 2006 17:03:49 +0200:
> > Cygwin has mmap. But cygwin's mmap() not good enough for git.
> > What happens is that git does rename() when target file has active mmap().
> > In cygwin, this makes rename() to fail. This is what makes cygwin's
> > mmap unusable for git. (BTW for read-only git access, mmap() will work
> > on cygwin, for what I saw. But attempts to modify index will break).
>
> It is not Cygwin really. It's windows. You can't rename or delete an
> open or mmapped file in that thing.
We have right to expect cygwin to do some effort to emulate the unix
mmap() semantics on top of different semantics of windows memory-mapped files.
Why doesn't cygwin do some effort to detect active mmap()s on the file
before rename and do something like (1) unmap (2) rename the target to temp name
(3) remap. (4) take care of temp file cleanup ? Probably too messy even if
possible. Is it reasonable to expect git to do this mess ?
It probably belongs to the generic cygwin layer anyway.
I did try another kind of workaround, in which I unmapped the target file
before rename. But it didn't work in all situations and was too intrusive
to the git-apply logic. Didn't work.
Regarding the existing workaround (NO_MMAP), well, cygwin is not exactly a
speed champion in many areas. I didn't really notice speed loss with
NO_MMAP, maybe because cygwin loses time here and there anyway ?
Yakov
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-07-17 8:29 UTC (permalink / raw)
To: git
Quite a bit of stuff has been merged, and I have tagged the tip
of the master as v1.4.2-rc1, before heading for Ottawa.
Notable changes in the "master" branch includes:
- Merge-base has been improved thanks to a test script by
ALASCM.
- A handful gitweb enhancements and fixes by Alp Toker and
Luben Tuikov.
- git-svn is now out of "contrib/" status.
- Many documentation updates.
- Fixed a performance bug in git-show-branch, which affected
git-merge.
- Fixed a nonsense output from git-fmt-merge-msg when pulling
HEAD from a remote repository, spotted by Linus.
- "git-log --merge" helps the archeology during a conflicted
merge, per request by Linus.
- git-grep boolean expression to allow --and, --or, and --not
is now in "master".
- A few updates to git-daemon by Matthias Lederhofer.
- A handful portability fixes by Pavel Roskin and Shawn Pearce.
- Ref-log updates by Shawn Pearce.
* The 'next' branch, in addition, has these.
- "checkout -f" and "reset --hard" fixes, when the new tree
should have file "foo" and the old tree and/or working tree
has directory there. Earlier we failed to instantiate file
"foo", and did not report an error. Testing is appreciated.
- git-apply fixes that was started by a test script by Eric
Wong. Testing is appreciated on this stuff.
- Perly git by Pasky with help from others.
- Optional autoconf by Jakub Narebski.
- A WIP of merge-recursive by Johannes and Alex Riesen.
- A usability enhancement of format-patch for imap-send users by
Josh Triplett
- A new loose object format support by Linus.
- An update to diff to make --name-only, --name-status,
--check and -s mutually exclusive by Timo Hirvonen.
* The 'pu' branch has an experimental "read-tree --rename" to
teach renames to git-merge-resolve, but currently it fails a
few of its own tests.
I noticed that "git diff" from subdirectories does not seem to
pick up the configuration from $GIT_DIR/config properly. I
suspect that fixing this breakage properly would help us later,
as more and more commands learn to use the configuration
mechanism to store user preferences, and the same fix would be
applicable to them. If somebody can fix this while we are away
this week, that would be wonderful ;-).
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Florian Weimer @ 2006-07-17 5:25 UTC (permalink / raw)
To: git
In-Reply-To: <20060716223607.GA6023@steel.home>
* Alex Riesen:
> It is not Cygwin really. It's windows. You can't rename or delete an
> open or mmapped file in that thing.
And GIT's workaround is to read the whole file into memory and close
it after that? Uh-oh.
^ permalink raw reply
* Re: [RFH/RFC] typechange tests for git apply (currently failing)
From: Junio C Hamano @ 2006-07-17 6:21 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <1153046320538-git-send-email-normalperson@yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> I've found that git apply is incapable of handling patches
> involving object type changes to the same path.
It's more of directory vs file conflicts -- and we do not track
directories. Some are pure bugs and relatively simple to fix
(and important), some others I am not sure if they are worth
dealing with.
> +test_expect_success 'file renamed from foo to foo/baz' '
> + git checkout -f initial &&
> + git diff-tree -M -p HEAD foo-baz-renamed-from-foo > patch &&
> + git apply --index < patch
> + '
If you look at where it fails closely you would notice this
first fails during git-checkout (without failing, I should
add). Try adding "git diff" immediately after "git checkout".
A fix for read-tree is in this message to fix this, but this has
only been very lightly tested, so please check it thoroughly.
After that is cleared, this and the next one uncover a few bugs
in "git apply".
> +test_expect_success 'file renamed from foo/baz to foo' '
> + git checkout -f foo-baz-renamed-from-foo &&
> + git diff-tree -M -p HEAD initial > patch &&
> + git apply --index < patch
> + '
> +test_debug 'cat patch'
one-way merge used in "git checkout -f" does not remove existing
directory when checking out a file. "git reset --hard" used to
be more careful but recent rewrite made them more or less
equivalent, and now has the same problem. This patch to read-tree
should fix it.
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index 6df5d7c..122b6f1 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -507,7 +507,7 @@ static int merged_entry(struct cache_ent
}
merge->ce_flags &= ~htons(CE_STAGEMASK);
- add_cache_entry(merge, ADD_CACHE_OK_TO_ADD);
+ add_cache_entry(merge, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE);
return 1;
}
@@ -518,7 +518,7 @@ static int deleted_entry(struct cache_en
else
verify_absent(ce->name, "removed");
ce->ce_mode = 0;
- add_cache_entry(ce, ADD_CACHE_OK_TO_ADD);
+ add_cache_entry(ce, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE);
invalidate_ce_path(ce);
return 1;
}
Then apply, when applying to create a file where a directory
lies, or vice versa, was not careful and did not remove
conflicting one. This patch makes the first few tests to work,
but it is not enough.
Currently, builtin-apply.c::write_out_one_result() says "remove
the old, write the new" for each "struct patch" (which
corresponds to "diff --git" line in your patch file). I think
the loop write_out_results() should be modified to first remove
what we are going to remove in all patches, and then create what
we are going to create.
What causes the fourth test to fail is that you have foo/baz in
the working tree and the index, and the patch creates file foo
and removes file foo/baz. The current loop to deal with one
patch at a time means we try to create file "foo" first, which
would not work without removing directory "foo" first.
diff --git a/builtin-apply.c b/builtin-apply.c
index c903146..9727442 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1732,9 +1732,14 @@ static int check_patch(struct patch *pat
if (check_index && cache_name_pos(new_name, strlen(new_name)) >= 0)
return error("%s: already exists in index", new_name);
if (!cached) {
- if (!lstat(new_name, &st))
- return error("%s: already exists in working directory", new_name);
- if (errno != ENOENT)
+ struct stat nst;
+ if (!lstat(new_name, &nst)) {
+ if (S_ISDIR(nst.st_mode))
+ ; /* ok */
+ else
+ return error("%s: already exists in working directory", new_name);
+ }
+ else if ((errno != ENOENT) && (errno != ENOTDIR))
return error("%s: %s", new_name, strerror(errno));
}
if (!patch->new_mode) {
@@ -2011,6 +2016,16 @@ static void create_one_file(char *path,
}
if (errno == EEXIST) {
+ /* We may be trying to create a file where a directory
+ * used to be.
+ */
+ struct stat st;
+ errno = 0;
+ if (!lstat(path, &st) && S_ISDIR(st.st_mode) && !rmdir(path))
+ errno = EEXIST;
+ }
+
+ if (errno == EEXIST) {
unsigned int nr = getpid();
for (;;) {
^ permalink raw reply related
* Re: git-repack not removing files from $GIT_DIR/objects/[00-ff]
From: Jeff King @ 2006-07-17 3:26 UTC (permalink / raw)
To: Post, Mark K; +Cc: git
In-Reply-To: <5A14AF34CFF8AD44A44891F7C9FF410507E43005@usahm236.amer.corp.eds.com>
On Sun, Jul 16, 2006 at 08:44:52PM -0400, Post, Mark K wrote:
> I'm having a problem that just started occurring with git-repack not
> removing the files from $GIT_DIR/objects/*, and therefore not removing
> the directories, since they're not empty. The command I'm using (as the
> git user) is this:
> GIT_DIR=/home/git/pub/scm/linux-2.6.git git-repack -a -d -l
git-prune-packed (which, contrary to what Shawn said, is run by
git-repack -d) will only remove objects which are redundant because of
their presence in packs. It will not remove objects which are not
reachable (which is normal if you have, for example, done a rebase in
this repository). Check out git-prune and git-fsck-objects.
-Peff
^ permalink raw reply
* RE: git-repack not removing files from $GIT_DIR/objects/[00-ff]
From: Post, Mark K @ 2006-07-17 2:48 UTC (permalink / raw)
To: spearce; +Cc: git
In-Reply-To: <20060717015149.GB27389@spearce.org>
That doesn't generate any error messages, but it also doesn't clean up
the files in the object directory.
Mark Post
-----Original Message-----
From: spearce@spearce.org [mailto:spearce@spearce.org]
Sent: Sunday, July 16, 2006 9:52 PM
To: Post, Mark K
Cc: git@vger.kernel.org
Subject: Re: git-repack not removing files from $GIT_DIR/objects/[00-ff]
So try:
GIT_DIR=/home/git/pub/scm/linux-2.6.git git-prune-packed
On a bare repository you should always set the GIT_DIR environment
variable to the directory of the repository before running the
command.
"Post, Mark K" <mark.post@eds.com> wrote:
> Thanks for the suggestion, but it didn't help. One reason is that
this
> is a bare repository. When I ran the command, it aborted with "fatal:
> Not a git repository." Most likely because bare repositories don't
have
> a .git directory in them.
>
>
> Mark Post
>
> -----Original Message-----
> From: spearce@spearce.org [mailto:spearce@spearce.org]
> Sent: Sunday, July 16, 2006 9:22 PM
> To: Post, Mark K
> Cc: git@vger.kernel.org
> Subject: Re: git-repack not removing files from
$GIT_DIR/objects/[00-ff]
>
> "Post, Mark K" <mark.post@eds.com> wrote:
> > I'm having a problem that just started occurring with git-repack not
> > removing the files from $GIT_DIR/objects/*, and therefore not
removing
> > the directories, since they're not empty. The command I'm using (as
> the
> > git user) is this:
> > GIT_DIR=/home/git/pub/scm/linux-2.6.git git-repack -a -d -l
> >
> > This used to work, but then suddenly stopped working. I ran an
strace
> > -f -F with this same command, and I don't see any attempt being made
> to
> > unlink the files in $GIT_DIR/objects/*/, but I do see the rmdir
> commands
> > failing because the directories are not empty. All of the files in
> > those directories are owned by git:git.
>
> Try running `git-prune-packed` after git-repack. git-repack doesn't
> delete the loose objects.
>
> I don't remember git-repack ever doing it either.
--
Shawn.
^ permalink raw reply
* Fresh stuff Online Casiino. GGo and Play It
From: Caroline @ 2006-07-17 1:15 UTC (permalink / raw)
To: git
Hi
Onlinne Casino with 85+ games. Play It Now! http://uveltord.com/d1/check/
A cat has nine lives. Lots of people confuse bad management with destiny
^ permalink raw reply
* Re: git-repack not removing files from $GIT_DIR/objects/[00-ff]
From: Shawn Pearce @ 2006-07-17 1:51 UTC (permalink / raw)
To: Post, Mark K; +Cc: git
In-Reply-To: <5A14AF34CFF8AD44A44891F7C9FF410507E43006@usahm236.amer.corp.eds.com>
So try:
GIT_DIR=/home/git/pub/scm/linux-2.6.git git-prune-packed
On a bare repository you should always set the GIT_DIR environment
variable to the directory of the repository before running the
command.
"Post, Mark K" <mark.post@eds.com> wrote:
> Thanks for the suggestion, but it didn't help. One reason is that this
> is a bare repository. When I ran the command, it aborted with "fatal:
> Not a git repository." Most likely because bare repositories don't have
> a .git directory in them.
>
>
> Mark Post
>
> -----Original Message-----
> From: spearce@spearce.org [mailto:spearce@spearce.org]
> Sent: Sunday, July 16, 2006 9:22 PM
> To: Post, Mark K
> Cc: git@vger.kernel.org
> Subject: Re: git-repack not removing files from $GIT_DIR/objects/[00-ff]
>
> "Post, Mark K" <mark.post@eds.com> wrote:
> > I'm having a problem that just started occurring with git-repack not
> > removing the files from $GIT_DIR/objects/*, and therefore not removing
> > the directories, since they're not empty. The command I'm using (as
> the
> > git user) is this:
> > GIT_DIR=/home/git/pub/scm/linux-2.6.git git-repack -a -d -l
> >
> > This used to work, but then suddenly stopped working. I ran an strace
> > -f -F with this same command, and I don't see any attempt being made
> to
> > unlink the files in $GIT_DIR/objects/*/, but I do see the rmdir
> commands
> > failing because the directories are not empty. All of the files in
> > those directories are owned by git:git.
>
> Try running `git-prune-packed` after git-repack. git-repack doesn't
> delete the loose objects.
>
> I don't remember git-repack ever doing it either.
--
Shawn.
^ permalink raw reply
* RE: git-repack not removing files from $GIT_DIR/objects/[00-ff]
From: Post, Mark K @ 2006-07-17 1:47 UTC (permalink / raw)
To: spearce; +Cc: git
In-Reply-To: <20060717012154.GA27389@spearce.org>
Thanks for the suggestion, but it didn't help. One reason is that this
is a bare repository. When I ran the command, it aborted with "fatal:
Not a git repository." Most likely because bare repositories don't have
a .git directory in them.
Mark Post
-----Original Message-----
From: spearce@spearce.org [mailto:spearce@spearce.org]
Sent: Sunday, July 16, 2006 9:22 PM
To: Post, Mark K
Cc: git@vger.kernel.org
Subject: Re: git-repack not removing files from $GIT_DIR/objects/[00-ff]
"Post, Mark K" <mark.post@eds.com> wrote:
> I'm having a problem that just started occurring with git-repack not
> removing the files from $GIT_DIR/objects/*, and therefore not removing
> the directories, since they're not empty. The command I'm using (as
the
> git user) is this:
> GIT_DIR=/home/git/pub/scm/linux-2.6.git git-repack -a -d -l
>
> This used to work, but then suddenly stopped working. I ran an strace
> -f -F with this same command, and I don't see any attempt being made
to
> unlink the files in $GIT_DIR/objects/*/, but I do see the rmdir
commands
> failing because the directories are not empty. All of the files in
> those directories are owned by git:git.
Try running `git-prune-packed` after git-repack. git-repack doesn't
delete the loose objects.
I don't remember git-repack ever doing it either.
--
Shawn.
^ permalink raw reply
* Re: git-repack not removing files from $GIT_DIR/objects/[00-ff]
From: Shawn Pearce @ 2006-07-17 1:21 UTC (permalink / raw)
To: Post, Mark K; +Cc: git
In-Reply-To: <5A14AF34CFF8AD44A44891F7C9FF410507E43005@usahm236.amer.corp.eds.com>
"Post, Mark K" <mark.post@eds.com> wrote:
> I'm having a problem that just started occurring with git-repack not
> removing the files from $GIT_DIR/objects/*, and therefore not removing
> the directories, since they're not empty. The command I'm using (as the
> git user) is this:
> GIT_DIR=/home/git/pub/scm/linux-2.6.git git-repack -a -d -l
>
> This used to work, but then suddenly stopped working. I ran an strace
> -f -F with this same command, and I don't see any attempt being made to
> unlink the files in $GIT_DIR/objects/*/, but I do see the rmdir commands
> failing because the directories are not empty. All of the files in
> those directories are owned by git:git.
Try running `git-prune-packed` after git-repack. git-repack doesn't
delete the loose objects.
I don't remember git-repack ever doing it either.
--
Shawn.
^ permalink raw reply
* git-repack not removing files from $GIT_DIR/objects/[00-ff]
From: Post, Mark K @ 2006-07-17 0:44 UTC (permalink / raw)
To: git
I'm having a problem that just started occurring with git-repack not
removing the files from $GIT_DIR/objects/*, and therefore not removing
the directories, since they're not empty. The command I'm using (as the
git user) is this:
GIT_DIR=/home/git/pub/scm/linux-2.6.git git-repack -a -d -l
This used to work, but then suddenly stopped working. I ran an strace
-f -F with this same command, and I don't see any attempt being made to
unlink the files in $GIT_DIR/objects/*/, but I do see the rmdir commands
failing because the directories are not empty. All of the files in
those directories are owned by git:git.
I tried upgrading to git 1.4.1, but the same thing happens. The gzipped
strace output is almost 5MB in size, certainly not appropriate to attach
here. I can make it available from the system's web server if anyone
wants to look at it.
Please let me know if there's any other information needed.
Mark Post
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Alex Riesen @ 2006-07-16 22:36 UTC (permalink / raw)
To: Yakov Lerner; +Cc: Florian Weimer, git
In-Reply-To: <f36b08ee0607160803s27dac6a6k476e3dd7742346fc@mail.gmail.com>
Yakov Lerner, Sun, Jul 16, 2006 17:03:49 +0200:
> Cygwin has mmap. But cygwin's mmap() not good enough for git.
> What happens is that git does rename() when target file has active mmap().
> In cygwin, this makes rename() to fail. This is what makes cygwin's
> mmap unusable for git. (BTW for read-only git access, mmap() will work
> on cygwin, for what I saw. But attempts to modify index will break).
It is not Cygwin really. It's windows. You can't rename or delete an
open or mmapped file in that thing.
^ 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