Translate one message came from git.pot update in 6eebb35
(l10n: git.pot: v2.4.0 round 2 (1 update)).
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
po/de.po | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/po/de.po b/po/de.po
index 49f35fe..2feaec1 100644
---
On 2015-04-04 02.24, David Turner wrote:
On Fri, 2015-04-03 at 15:01 -0700, Junio C Hamano wrote:
David Turner dtur...@twopensource.com writes:
Why is it impossible to free struct lock_files? I understand that they
become part of a linked list, and that there's an atexit handler that
goes
On 2015-04-04 02.19, Reid Woodbury Jr. wrote:
Thanks for keeping me in the loop!
I have two thoughts on handling input:
As a coder I want to know exactly what's going on in my code. If I've given
erroneous input I'd like to know about it in the most useful and quickest
way, never
From: Holloway, Blair blair_hollo...@playstation.sony.com
If a Perforce server is configured to automatically set +l (exclusive lock) on
add of certain file types, git p4 submit will fail during getP4OpenedType, as
the regex doesn't expect the trailing '*exclusive*' from p4 opened:
The test for handling of failure when trying to move a file
that is locked by another client was not quite correct - it
failed early on because the target file in the move already
existed.
The test now fails because git-p4 does not properly detect
that p4 has rejected the move, and instead just
Test script t9816-git-p4-locked.sh test #4 tests for
adding a file that is locked by Perforce automatically.
This is currently not supported by git-p4 and so is
expected to fail.
However, a small typo meant it always failed, even with
a fixed git-p4. Fix the typo to resolve this.
Signed-off-by:
Updated patch series for fixing git-p4 filetype detection when one or more
files have been locked automatically by p4 (fix provided by Blair),
incorporating comments from Eric:
- squashes the actual fix and the test case change together
- fixes typo
Luke
Holloway, Blair (1):
git-p4: fix
On Fri, Apr 03, 2015 at 03:24:09PM -0700, Kyle J. McKay wrote:
I thought that meant we could also optimize out the map call entirely,
and just use the first split (with *) to end up with a list of $COLOR
chunks and single characters, but it does not seem to work. So maybe I
am misreading
On Fri, Apr 3, 2015 at 10:24 AM, Jeff King p...@peff.net wrote:
EungJun, does this version meet your needs?
-Peff
Yes, this patch is enough to meet my needs because it works well on
UTF-8, the only encoding I use. And this patch looks better than my
one because it is smaller, doesn't depend
As I've mentioned before, I have some repositories with rather large
numbers of refs. The worst one has ~13 million refs, for a 1.6GB
packed-refs file. So I was saddened by this:
$ time git.v2.0.0 rev-parse refs/heads/foo /dev/null 21
real0m6.840s
user0m6.404s
sys 0m0.440s
In t1430, we check whether deleting the branch ../../foo
will delete .git/foo. However, this is not that
interesting a test; the precious file .git/foo does not
look like a ref, so even if we did not notice the escape
from the refs/ hierarchy, we would fail for that reason
(i.e., if you turned
strbuf_getwholeline calls getc in a tight loop. On modern
libc implementations, the stdio code locks the handle for
every operation, which means we are paying a significant
overhead. We can get around this by locking the handle for
the whole loop and using the unlocked variant.
Running git
We have to call strbuf_grow anytime we are going to add data
to a strbuf. In most cases, it's a noop (since we grow the
buffer aggressively), and the cost of the function call and
size check is dwarfed by the actual buffer operation.
For a tight loop of single-character additions, though, this
strbuf_getwholeline calls fgetc in a tight loop. Using the
getc form, which can be implemented as a macro, should be
faster (and we do not care about it evaluating our argument
twice, as we just have a plain variable).
On my glibc system, running git rev-parse
refs/heads/does-not-exist on a file
POSIX.1-2001 specifies some functions for optimizing the
locking out of tight getc() loops. Not all systems are
POSIX, though, and even not all POSIX systems are required
to implement these functions. We can check for the
feature-test macro to see if they are available, and if not,
provide a noop
Usually refs are not allowed to contain a .. component.
However, since d0f810f (refs.c: allow listing and deleting
badly named refs, 2014-09-03), we relax these rules in some
cases in order to help users examine and get rid of
badly-named refs. However, we do still check that these refs
cannot
On Sat, Apr 04, 2015 at 09:11:10PM -0400, Jeff King wrote:
I also considered optimizing the term == '\n' case by using fgets, but
it gets rather complex (you have to pick a size, fgets into it, and then
keep going if you didn't get a newline). Also, fgets sucks, because you
have to call
On Sun, Apr 05, 2015 at 12:56:14AM -0400, Jeff King wrote:
The big downside is that our input strings are no longer NUL-clean
(reading foo\0bar\n would yield just foo. I doubt that matters in
the real world, but it does fail a few of the tests (e.g., t7008 tries
to read a list of patterns
On Sun, Apr 05, 2015 at 01:27:32AM -0400, Jeff King wrote:
On Sun, Apr 05, 2015 at 12:56:14AM -0400, Jeff King wrote:
The big downside is that our input strings are no longer NUL-clean
(reading foo\0bar\n would yield just foo. I doubt that matters in
the real world, but it does fail a
Hi,
I'm having a performance issue with git clean -qxfd (note, not using
-ff).
The performance issue shows up when trying to clean untracked
directories that themselves contain many sub directories. The
performance is highly non linear with the number of sub
directories. Some test numbers:
Dirs
On Fri, Apr 03, 2015 at 08:24:43PM -0400, David Turner wrote:
But I can see why git wouldn't want to depend on that behavior. C11 has
a way to do this safely, but AIUI, git doesn't want to move to C99 let
alone C11. So I guess this will just have to remain the way it is.
I would really like
Luke Diamand l...@diamand.org writes:
On 30/03/15 04:03, Junio C Hamano wrote:
Vitor Antunes vitor@gmail.com writes:
* Modify source file (file2) before copying the file.
* Check that only file2 is the source in the output of p4 filelog.
* Remove all case statements and replace them
Koosha Khajehmoogahi koo...@posteo.de writes:
From: Junio C Hamano gits...@pobox.com
[kk: wrote commit message]
Ehh, what exactly did you write ;-)?
I think the most important thing that needs to be explained by the
log message for this change is that the variable is honored only by
log and
On Sat, Apr 04, 2015 at 01:06:43PM -0700, Junio C Hamano wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
So it isn't as much of a we don't want to move to C99 as much as we
aren't yet willing to drop support for older versions of MSVC.
I do not particularly like that 'we' in
On Sat, Apr 04, 2015 at 10:39:47PM +0200, erik elfström wrote:
That looks like the same issue. The use is_git_directory approach
sounds good to me, is that the direction you would prefer? I can try
to cobble something together although I must warn you I have zero
previous experience with this
On Sat, Apr 04, 2015 at 08:32:45PM +0200, erik elfström wrote:
In my scenario get_ref_cache will be called 1+ times, each time
with a new path. The final few calls will need to search through and
compare 1+ entries before realizing that there is no existing
entry. This quickly ads up
On 04/05/2015 01:04 AM, Junio C Hamano wrote:
Karthik Nayak karthik@gmail.com writes:
@@ -2586,13 +2649,15 @@ int sha1_object_info_extended(const unsigned char
*sha1, struct object_info *oi,
*(oi-disk_sizep) = 0;
if (oi-delta_base_sha1)
That looks like the same issue. The use is_git_directory approach
sounds good to me, is that the direction you would prefer? I can try
to cobble something together although I must warn you I have zero
previous experience with this code base so a few iterations will
probably be needed.
/Erik
On
Karthik Nayak karthik@gmail.com writes:
@@ -2586,13 +2649,15 @@ int sha1_object_info_extended(const unsigned char
*sha1, struct object_info *oi,
*(oi-disk_sizep) = 0;
if (oi-delta_base_sha1)
hashclr(oi-delta_base_sha1);
+
brian m. carlson sand...@crustytoothpaste.net writes:
So it isn't as much of a we don't want to move to C99 as much as we
aren't yet willing to drop support for older versions of MSVC.
I do not particularly like that 'we' in that sentence, which would
give a false impression to people that we
Heyup, everybody.
Apologies if this turns out to be a duplicate. Gmane seems broken, so
I couldn't search the archive.
I'm using git version 2.4.0-rc1. The same behavior exists in 2.1.0.
With git-log it is possible to specify a custom pretty format that
outputs one line per commit:
git log
31 matches
Mail list logo
