Hello,
Seem to be a bug.
OSX 10.10.3 git 2.3.6 HFS+ case-sensitive
How to reproduce :
Step 1 : git clone https://github.com/begeric/FastParsers.git
Step 2 : cd FastParsers/
Step 3 : git filter-branch --env-filter 'if [ 0 = 1 ]; then echo 0; fi' -- --all
Result on OSX :
Rewrite
read_gitfile_gently will allocate a buffer to fit the entire file that
should be read. Add a sanity check of the file size before opening to
avoid allocating a potentially huge amount of memory if we come across
a large file that someone happened to name .git. The limit is set to
a sufficiently
The tests are run in dry-run mode to avoid having to restore the test
directories for each timed iteration. Using dry-run is an acceptable
compromise since we are mostly interested in the initial computation
of what to clean and not so much in the cleaning it self.
Signed-off-by: Erik Elfström
Signed-off-by: Erik Elfström erik.elfst...@gmail.com
---
t/t7300-clean.sh | 128 +++
1 file changed, 128 insertions(+)
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index 99be5d9..11f3a6d 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
read_gitfile will die on most error cases. This makes it unsuitable
for speculative calls. Extract the core logic and provide a gentle
version that returns NULL on failure.
The first usecase of the new gentle version will be to probe for
submodules during git clean.
Helped-by: Junio C Hamano
git clean uses resolve_gitlink_ref() to check for the presence of
nested git repositories, but it has the drawback of creating a
ref_cache entry for every directory that should potentially be
cleaned. The linear search through the ref_cache list causes a massive
performance hit for large number of
Changes in v5:
* Added defines for read_gitfile_gently error codes.
This was a silly mistake, sorry about that.
Erik Elfström (5):
setup: add gentle version of read_gitfile
setup: sanity check file size in read_gitfile_gently
t7300: add tests to document behavior of clean and nested git
A typicall setup under Windows:
core.eol is CRLF and a file is marked as text in .gitattributes.
After 4d4813a5 git blame no longer works as expected,
every line is annotated as Not Committed Yet,
even though the working directory is clean.
commit 4d4813a5 removed the conversion in blame.c for
On 24/04/15 15:36, FusionX86 wrote:
I get an error if I misspell part of the path. For example, if I type
//depot/maain instead of //depot/main I will get the no such files
message you indicated. BUT using incorrect case like //depot/main
instead of //depot/Main doesn't return any error, but
brian m. carlson sand...@crustytoothpaste.net writes:
While I was adding tests, I noticed that we had a broken test due to the
use of single quotes within a test, which resulted in the test always
being skipped.
Good eyes. While fixing the test is necessary, we should also be
able to improve
Hi,
I'm using git with a submodule containing a (large) binary toolchain where I
updated the version from GCC-4.7 to 4.8. When I added 4.8 I deleted 4.7 and
now want to add 4.7 back to the HEAD. As shown in the tree objects below, the
4.7 bits are still in the repository (as expected), but
On 04/23/2015 01:24 AM, brian m. carlson wrote:
This is a conversion of parts of refs.c to use struct object_id.
refs.c, and the for_each_ref series of functions explicitly, is the
source for many instances of object IDs in the codebase. Therefore, it
makes sense to convert this series of
On Sun, Apr 26, 2015 at 8:02 AM, Torsten Bögershausen tbo...@web.de wrote:
A typicall setup under Windows:
s/typicall/typical/
core.eol is CRLF and a file is marked as text in .gitattributes.
After 4d4813a5 git blame no longer works as expected,
every line is annotated as Not Committed Yet,
The git_connect function has code to handle plink and tortoiseplink
specially, as they require different command line arguments from
OpenSSH (-P instead of -p for ports; tortoiseplink additionally requires
-batch). However, the match was done by checking for plink anywhere
in the string, which
This series improves detection of plink (the putty utility).
While I was adding tests, I noticed that we had a broken test due to the
use of single quotes within a test, which resulted in the test always
being skipped. Therefore, nobody noticed that the test was actually
broken.
brian m.
One of the tests in t5601 used single quotes to delimit an argument
containing spaces. However, this caused test_expect_success to be
passed three arguments instead of two, which in turn caused the test
name to be treated as a prerequisite instead of a test name. As there
was no prerequisite
The code path used in git_connect pushed the majority of the SSH
connection code into an else block, even though the if block returns.
Simplify the code by eliminating the else block, as it is unneeded.
Signed-off-by: Jeff King p...@peff.net
Signed-off-by: brian m. carlson
If we'll run 'git add -e path' on a path which has no
difference with the current index, empty editor will open. This
patch prevents this behaviour and checks that patch is not empty
before an editor with patch will be opened.
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
On Sun, Apr 26, 2015 at 1:03 PM, Alexander Kuleshov
kuleshovm...@gmail.com wrote:
If we'll run 'git add -e path' on a path which has no
difference with the current index, empty editor will open. This
patch prevents this behaviour and checks that patch is not empty
before an editor with patch
On Sat, Apr 25, 2015 at 06:03:22PM +0200, Torsten Bögershausen wrote:
(I'm not sute if the commit message describes the problem deep enough
for readers which are not familar with all the details of the original
report):
A feature implemented for Windows may break things for e.g. Linux users)
On Sun, Apr 26, 2015 at 5:41 PM, Brad Litterell b...@evidence.com wrote:
Is it possible git is not computing the delta correctly?
Or does git only look at the top-level commit objects to figure out what to
include in the push packfile?
We walk the commit graph backwards to discover the common
Torsten Bögershausen tbo...@web.de writes:
Although the intention of 4d4813a5 is good, it breaks
the usual EOL-handling for Windows.
Until we have a better solution, we suggest to revert it.
That makes it sound like you are proposing to rob Peter to pay Paul,
but that is not how we do things
Hello,
thank you Torsten for the patch [I'm the reporter, but could not do
it myself]
-test_expect_success 'blaming files with CRLF newlines' '
+test_expect_failure 'blaming files with CRLF newlines in repo,
core.autoclrf=input' '
Shouldn't the old test be rather removed?
It deals with an
23 matches
Mail list logo
