From: Jeff King p...@peff.net
I have an 11 GB repository. It passes git-fsck (though with a number
of dangling objects). But when I run git-gc on it, the file
refs/heads/master disappears.
That's the expected behavior. Gc runs git pack-refs, which puts an
entry into packed-refs and
I have an unpleasant bug in git-gc:
Git version: 1.8.3.1
Running on: Fedora 19 Gnu/Linux
I have an 11 GB repository. It passes git-fsck (though with a number
of dangling objects). But when I run git-gc on it, the file
refs/heads/master disappears. Since HEAD points to refs/heads/master,
[Previously sent to the git-users mailing list, but it probably should
be addressed here.]
A number of commands invoke git gc --auto to clean up the repository
when there might be a lot of dangling objects and/or there might be
far too many unpacked files. The manual pages say:
git gc:
From: David Lang da...@lang.hm
well, as others noted, the problem is actually caused by doing the diffs, and
that is something that is a very common thing to do with source code.
To some degree, my attitude comes from When I Was A Boy, when you got
16k for both your bytecode and your data,
From: Duy Nguyen pclo...@gmail.com
I don't know how many commands are hit by this. If you have time and
gdb, please put a break point in die_builtin() function and send
backtraces for those that fail. You could speed up the process by
creating a smaller file and set the environment variable
From: Junio C Hamano gits...@pobox.com
You need to have enough memory (virtual is fine if you have enough
time) to do fsck. Some part of index-pack could be refactored into
a common helper function that could be called from fsck, but I think
it would be a lot of work.
How much memory is
From: David Lang da...@lang.hm
Git was designed to track source code, there are warts that show up
in the implementation when you use individual files 4GB
I'd expect that if you want to deal with files over 100k, you should
assume that it doesn't all fit in memory.
Dale
--
To unsubscribe
I've discovered a problem using Git. It's not clear to me what the
correct behavior should be, but it seems to me that Git is failing
in an undesirable way.
The problem arises when trying to handle a very large file. For
example:
$ git --version
git version 1.8.3.1
$ mkdir $$
$
From: Jeff King p...@peff.net
One of the problems I ran into recently is that
corrupt data can cause it to make a large allocation
One thing I notice is that in unpack_compressed_entry() in
sha1_file.c, there is a mallocz of size bytes. It appears that
size is the size of the object that is
I have a large repository (17 GiB of disk used), although no single
file in the repository is over 1 GiB. (I have pack.packSizeLimit set
to 1g.) I don't know how many files are in the repository, but it
shouldn't exceed several tens of commits each containing several tens
of thousands of files.
The pattern I use is to have this:
/repository/.git
with core.worktree = /working
/working/...
then
cd /repository
git add /working/x/y
git ...
The point I'm trying to make is that it appears that all of the Git
commands
From: Junio C Hamano gits...@pobox.com
... it's not clear why GIT_WORK_TREE exists, ...
The configuration item came _way_ later than the environment, and we
need to keep users and scripts from old world working, that is why.
OK, that explains a great deal. IIRC, I first became aware that
From: Junio C Hamano gits...@pobox.com
Side note: without GIT_WORK_TREE environment (or
core.worktree), there is no way to tell where the top level
is, so you were limited to always be at the top level of
your working tree if you used GIT_DIR to refer to a
From: Junio C Hamano gits...@pobox.com
Now, when you say the cwd contains the .git directory, do you mean
cd /repositories
git add ../working/trees/proj-wt1/file
updates file in the /repositories/proj.git/index? Or do you mean
this?
The pattern I use is to have this:
From: Junio C Hamano gits...@pobox.com
It was unclear to me which part of our documentation needs updating
and how, and that was (and still is) what I was primarily interested
in finding out.
It seems to me that what is missing is a description of the
circumstances under which Git can be
From: Junio C Hamano gits...@pobox.com
wor...@alum.mit.edu (Dale R. Worley) writes:
In general, Git commands on a repository with a detached worktree can
be executed by cd'ing into the directory containing the .git
directory, ...
Eh? News to me; it might happened to have appeared
In Git, one can set up a repository with a detached worktree, where
the .git directory is not a subdirectory of the top directory of the
work tree.
In general, Git commands on a repository with a detached worktree can
be executed by cd'ing into the directory containing the .git
directory, and
I'm working on using git filter-branch to remove the history of a
large file from my repository so as to reduce the size of the
repository. This pattern of use is effective for me:
1. $ git filter-branch --index-filter 'git rm --cached --ignore-unmatch
core.4563' HEAD
2. edit .git/packed-refs
From: Matthieu Moy matthieu@grenoble-inp.fr
const char *git_pager(int stdout_is_tty)
{
const char *pager;
if (!stdout_is_tty)
return NULL;
pager = getenv(GIT_PAGER);
if (!pager) {
I've noticed that Git by default puts long output through less as a
pager. I don't like that, but this is not the time to change
established behavior. But while tracking that down, I noticed that
the paging behavior is controlled by at least 5 things:
the -p/--paginate/--no-pager options
So I set out to verify in the code that the order of priority of pager
specification is
GIT_PAGER core.pager PAGER default
I discovered that there is also a pager.command configuration
variable.
I was expecting the code to be simple, uniform (with regard to the 5
sources), and reasonably
From: Junio C Hamano gits...@pobox.com
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index b1630ba..33fbd8c 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -28,11 +28,15 @@ two blob objects, or changes between two files on disk.
From: Junio C Hamano gits...@pobox.com
I've noticed that Git by default puts long output through less as a
pager. I don't like that, but this is not the time to change
established behavior. But while tracking that down, I noticed that
the paging behavior is controlled by at least 5
I've noticed that Git by default puts long output through less as a
pager. I don't like that, but this is not the time to change
established behavior. But while tracking that down, I noticed that
the paging behavior is controlled by at least 5 things:
the -p/--paginate/--no-pager options
the
From: Junio C Hamano gits...@pobox.com
I suspect that it may be a good idea to split the section altogether
to reduce confusion like what triggered this thread, e.g.
'git diff' [--options] [--] [path...]::
This form is to view the changes you made relative to
Clarify documentation for git-diff: State that when not inside a
repository, --no-index is implied (and thus two arguments are
mandatory).
Clarify error message from diff-no-index to inform user that CWD is
not inside a repository and thus two arguments are mandatory.
Signed-off-by: Dale Worley
Clarify documentation for git-diff: State that when not inside a
repository, --no-index is implied (and thus two arguments are
mandatory).
Clarify error message from diff-no-index to inform user that CWD is
not inside a repository and thus two arguments are mandatory.
Signed-off-by: Dale Worley
Commit a2cb86 (git_mkstemps: correctly test return value of open(),
12 Jul 2013) fixes a bug regarding testing the return of an open()
call for success/failure. Add a testsuite test for that fix. The
test exercises a situation where that open() is known to return 0.
Signed-off-by: Dale Worley
---
This is a first draft of a patch that clarifies a number of points
about how patches should be formatted that have tripped me up. I have
re-filled a few of the paragraphs, which makes it hard to see from the
diff what I've changed. This listing shows the changed words between
{ ... }:
From: Junio C Hamano gits...@pobox.com
Thanks. I thought I've already queued
Message-ID: 7vfvuokpr0@alter.siamese.dyndns.org
aka
http://article.gmane.org/gmane.comp.version-control.git/231680
which tests
git commit --allow-empty -m message -
My mistake... I've been so
git commit --allow-empty -m message -
Though as of [fb56570] Sync with maint to grab trivial doc fixes,
that test doesn't fail for me if I revert to
fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode);
if (fd 0)
return fd;
I haven't
From: John Keeping j...@keeping.me.uk
git-format-patch(1) says:
By default, the subject of a single patch is [PATCH] followed
by the concatenation of lines from the commit message up to the
first blank line (see the DISCUSSION section of git-commit(1)).
I think
Commit 52749 fixes a bug regarding testing the return of an open()
call for success/failure. Improve the testsuite test for that fix by
removing the helper program 'test-close-fd-0' and replacing it with
the shell redirection '-'. (The redirection is Posix, so it should
be portable.)
From: Duy Nguyen pclo...@gmail.com
With the above change, the test suite runs with zero failures, so it
doesn't affect any common Git usage.
It means the test suite is incomplete. As you can see, the commit
introducing this change does not come with a test case to catch people
changing
From: Duy Nguyen pclo...@gmail.com
Can someone give me advice on what this code *should* do?
It does as the function name says: given cwd, a prefix (i.e. a
relative path with no .. components) and a path relative to
cwd+prefix, convert 'path' to something relative to cwd. In the
simplest
I've run into a problem (with Git 1.8.3.3) where I cannot add a
symbolic link (as such) to the repository *if* its path is given
absolutely; instead Git adds the file the symbolic link points to.
(If I give the path relatively, Git does what I expect, that is, adds
the symbolic link.)
I've
I'm working on writing a patch, but I'm running into a problem. The
patch itself is from this commit:
$ git log -1
commit 07a25537909dd277426818a39d9bc4235e755383
Author: Dale Worley wor...@ariadne.com
Date: Thu Jul 18 18:43:12 2013 -0400
open() returns -1 on failure,
I've been looking into writing a proper test for this patch. My first
attempt tests the symptom that was seen initially, that git commit
fails if fd 0 is closed.
One problem is how to arrange for fd 0 to be closed. I could use the
bash redirection -, but I think you want to be more portable
From: Junio C Hamano gits...@pobox.com
That's just a plain-vanilla part of POSIX shell behaviour, no?
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_05
Close standard input is so weird I never thought it was Posix. In
that case, we can eliminate the C
From: Junio C Hamano gits...@pobox.com
+test_expect_success 'git_mkstemps_mode does not fail if fd 0 is not open' '
+ git init
+ echo Test. test-file
+ git add test-file
+ git commit -m Message. -
+'
+
Yup. I wonder how it would fail without the fix, though ;-)
Eh,
(The original problem and the discussion that ensued is on the
git-users mailing list:
https://groups.google.com/forum/#!topic/git-users/lNQ7Cn35EqA)
git commit (and probably other operations) fail if standard input
(fd 0) is closed when git starts. A simple test case follows. (The
execution is
Here's a slightly simpler test case for adding a symbolic link. This
test exploits the fact that on my system, /bin/awk is a symbolic link
to gawk. As you can see, the behavior of Git differs if the link's
path is given to git add as an absolute path or a relative path.
Here is the test script:
I'm having a problem with git add in version 1.7.7.6.
The situation is that I have a repository that is contained in a
second-level directory, a sub-sub-directory of /. The core.worktree
of the repository is /, so the working directory is the entire file
tree. I want this repository to track
Describe how 'add' sets the submodule's logical name, which is used in
the configuration entry names.
Clarify that 'init' only sets up the configuration entries for
submodules that have already been added elsewhere. Describe that
path arguments limit the submodules that are configured.
From e87227498ef3d50dc20584c24c53071cce63c555 Mon Sep 17 00:00:00 2001
From: Dale Worley wor...@ariadne.com
Date: Tue, 7 May 2013 13:39:46 -0400
Subject: [PATCH] CodingGuidelines: make it clear which files in
Documentation/ are the sources
Signed-off-by: Dale R. Worley wor...@ariadne.com
While learning about making a documentation patch, I noticed that
Documentation/CodingGuideles isn't as clear as it could be regarding
how to edit the documentation. In particular, it says Most (if not
all) of the documentation pages are written in AsciiDoc - and
processed into HTML output and
Several people have made similar mistakes in beliving that git
submodule init can be used for adding submodules to a working
directory, whereas git submodule add is the command that should be
used. That *is* documented at the top of the manual page for git
submodule, but my error was enhanced by
From: Thomas Rast tr...@student.ethz.ch
wor...@alum.mit.edu (Dale R. Worley) writes:
[...snip...]
Isn't that just a very long-winded way of restating what Junio said
earlier:
It was suggested to make it apply the first-parent diff and record
the result, I think. If that were
This is how I see what rebase should do:
The simple case for rebase starts from
P---Q---R---S master
\
A---B---C topic
Then git checkout topic ; git rebase master will change it to
P---Q---R---S master
(git version 1.7.7.6)
I've been learning how to use Git. While exploring git rebase, I've
discovered that if the branch being rebased contains an evil merge,
that is, a merge which contains changes that are in addition to the
changes in any of the parent commits, the rebase operation will
From: Matthieu Moy matthieu@grenoble-inp.fr
In any case, I can't reproduce with 1.8.1.2.526.gf51a757: I don't get
undless output. On the other hand, I get a slightly misformatted output:
* commit a393ed598e9fb11436f85bd58f1a38c82f2cadb7 (from
I have found a situation where git log produces (apparently)
endless output. Presumably this is a bug. Following is a (Linux)
script that reliably reproduces the error for me (on Fedora 16):
--
set -ve
# Print the git version.
git --version
# Create respository.
rm -rf .git
git init
52 matches
Mail list logo
