On 2015-04-04 02.24, David Turner wrote:
> On Fri, 2015-04-03 at 15:01 -0700, Junio C Hamano wrote:
>> David Turner 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 over that li
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
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
---
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
--- a/po/de.po
+++ b/po/de.po
@@
On 30/03/15 04:03, Junio C Hamano wrote:
Vitor Antunes 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 simple tests to check that
source is "file2".
Signed-off
From: "Holloway, Blair"
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:
//depot/file.png#1 - add default change (binary
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 cr
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: L
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 file
On Fri, Apr 03, 2015 at 03:15:14PM -0700, Kyle J. McKay wrote:
> When the input is UTF-8 and Perl is operating on bytes instead of
> characters, a diff that changes one multibyte character to another
> that shares an initial byte sequence will result in a broken diff
> display as the common byte s
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 misr
On Fri, Apr 3, 2015 at 10:24 AM, Jeff King 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 on String::
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:
D
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
Karthik Nayak 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);
> + if (oi-
Luke Diamand writes:
> On 30/03/15 04:03, Junio C Hamano wrote:
>> Vitor Antunes 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 simple tests to check
On 04/05/2015 01:04 AM, Junio C Hamano wrote:
Karthik Nayak 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_sha
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
Koosha Khajehmoogahi writes:
> From: Junio C Hamano
>
> [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 it needs to explain why other P
"brian m. carlson" 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 all want to switch an
On Sat, Apr 04, 2015 at 01:06:43PM -0700, Junio C Hamano wrote:
> "brian m. carlson" 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,
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
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
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 --p
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 2>&1
real0m6.840s
user0m6.404s
sys 0m0.440s
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 i
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
ove
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 t
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 rev-p
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 "e
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 patte
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 doe
33 matches
Mail list logo
