On 04/18/2015 05:30 AM, Eric Sunshine wrote:
On Wed, Apr 15, 2015 at 1:00 PM, Karthik Nayak wrote:
> Signed-off-by: Karthik Nayak
> ---
> diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh
> index ab36b1e..61fab78 100755
> --- a/t/t1006-cat-file.sh
> +++ b/t/t1006-cat-file.sh
> @@ -296,4 +
> If it's not a problem, I'd love to see timings for your case with just
> the first patch, and then with both.
Thanks for the swift response, much appreciated Jeff!
Here are the timings for the two patches:
Patch 1 on top of 33d4221c79
Elapsed System User
Min.
A path(spec) from git perspective consists of two parts, the prefix,
and the rest. The prefix covers the part of `pwd` after expanding ".."
components. The split is to support case-insensitive match in a sane
way (see 93d9353, especially the big comment block added in dir.c).
Normally the prefix i
On Wed, Apr 15, 2015 at 1:00 PM, Karthik Nayak wrote:
> Signed-off-by: Karthik Nayak
> ---
> diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh
> index ab36b1e..61fab78 100755
> --- a/t/t1006-cat-file.sh
> +++ b/t/t1006-cat-file.sh
> @@ -296,4 +308,21 @@ test_expect_success '%(deltabase) repo
On Fri, Apr 17, 2015 at 3:17 PM, Stefan Beller wrote:
> On Fri, Apr 17, 2015 at 3:12 PM, Junio C Hamano wrote:
>>
>> This is now pushed out and sitting at the tip of 'pu'. It seems to
>> break one of the tests in 1400 when merged to 'next', but I didn't
>> look it closely.
>>
>> Thanks.
>
> ok,
On Wed, Apr 15, 2015 at 12:59 PM, Karthik Nayak wrote:
> Update sha1_loose_object_info() to optionally allow it to read
> from a loose object file of unknown/bogus type; as the function
> usually returns the type of the object it read in the form of enum
> for known types, add an optional "typenam
Simply running "p4 changes" on a large branch can
result in a "too many rows scanned" error from the
Perforce server. It is better to use a sequence
of smaller calls to "p4 changes", using the "-m"
option to limit the size of each call.
Signed-off-by: Lex Spoon
Reviewed-by: Junio C Hamano
Review
Am 16.04.2015 um 20:39 schrieb Junio C Hamano:
> This is on top of the ".gitignore can start with UTF8 BOM" patch
> from Carlos.
>
> Second try; the first patch is new to clarify the logic in the
> codeflow after Carlos's patch, and the second one has been adjusted
> accordingly.
>
> Junio C Hama
Jeff King writes:
> The implementation is fairly straightforward. Whenever we do
> the linear search, we cache the interesting commit we find,
> and next time check it before doing another linear search.
> If that commit is removed from the list or becomes
> UNINTERESTING itself, then we fall bac
On Fri, Apr 17, 2015 at 3:12 PM, Junio C Hamano wrote:
>
> This is now pushed out and sitting at the tip of 'pu'. It seems to
> break one of the tests in 1400 when merged to 'next', but I didn't
> look it closely.
>
> Thanks.
ok, I'll look more closely.
--
To unsubscribe from this list: send the
Junio C Hamano writes:
> Stefan Beller writes:
>
>> * We keep the speed on small transactions
>> (no close and reopen of fds in small transactions)
>>
>> * No refactoring for refs included, only minimally invasive to the refs.c
>> code
>>
>> * applies on top of origin/sb/remove-fd-from-ref-l
When we are limiting a rev-list traversal due to
UNINTERESTING refs, we have to walk down the tips (both
interesting and uninteresting) to find where they intersect.
We keep a queue of commits to examine, pop commits off
the queue one by one, and potentially add their parents. The
size of the queu
Jeff King writes:
> I'd be surprised if it appreciably speeds things up, but I guess it is
> not too complicated to do.
>
>> +static struct {
>> +const char *str;
>> +int len;
>> +} object_type_name[] = {
>> +{ NULL, 0 }, /* OBJ_NONE = 0 */
>> +{ "commit", 6 }, /* OBJ_COMMIT
Jeff King writes:
> On Fri, Apr 17, 2015 at 09:21:31AM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > If there _is_ a performance implication to worry about here, I think it
>> > would be that we are doing an extra malloc/free.
>>
>> Thanks for reminding me; yes, that also worried
On Fri, Apr 17, 2015 at 01:54:27PM -0700, Junio C Hamano wrote:
> > Since the strings we are matching are literals, we could also record
> > their sizes in the object_type_strings array and check the length first
> > before even calling strncmp. I doubt this is a performance hot-spot,
> > though.
Johannes Schindelin writes:
> Hi Torsten,
>
> On 2015-04-17 17:44, Torsten Bögershausen wrote:
>> Without this patch, t0027 expects the native end-of-lines to be a single
>> line feed character. On Windows, however, we set it to a carriage return
>> character followed by a line feed character. Th
Jeff King writes:
> When commit fe8e3b7 refactored type_from_string to allow
> input that was not NUL-terminated, it switched to using
> strncmp instead of strcmp. But this means we check only the
> first "len" bytes of the strings, and ignore any remaining
> bytes in the object_type_string. We s
On Fri, Apr 17, 2015 at 09:21:31AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > If there _is_ a performance implication to worry about here, I think it
> > would be that we are doing an extra malloc/free.
>
> Thanks for reminding me; yes, that also worried me.
As an aside, I worried
On Fri, Apr 17, 2015 at 11:44 AM, Torsten Bögershausen wrote:
> Without this patch, t0027 expects the native end-of-lines to be a single
> line feed character. On Windows, however, we set it to a carriage return
> character followed by a line feed character. Thus, we have to modify
> t0027 to expe
Matthieu Moy writes:
> The old message did not mention the :regex:file form.
>
> To avoid overly long lines, split the message into two lines (in case
> item->string is long, it will be the only part truncated in a narrow
> terminal).
>
> Signed-off-by: Matthieu Moy
> ---
> line-log.c | 3 ++-
>
Jeff King writes:
> If there _is_ a performance implication to worry about here, I think it
> would be that we are doing an extra malloc/free.
Thanks for reminding me; yes, that also worried me.
> I'm not sure I
> understand why we are copying it at all. The original code copied from
> the hdr
karthik nayak writes:
> + type = type_from_string_gently(buf, len, 1);
> + if (oi->typename) {
> + strbuf_add(oi->typename, buf, len);
> + strbuf_addch(oi->typename, '\0');
add() has setlen() at the end so you do not have to NUL terminate it
yourself. Doi
On Fri, Apr 17, 2015 at 06:56:43PM +0200, Torsten Bögershausen wrote:
> On 04/17/2015 01:52 PM, Mike Hommey wrote:
> > +test_expect_success 'V: default case folding with ignorecase=true' '
> > + git config core.ignorecase true &&
> > + git fast-import > + git ls-tree refs/heads/V >actual &&
Hi Torsten,
On 2015-04-17 17:44, Torsten Bögershausen wrote:
> Without this patch, t0027 expects the native end-of-lines to be a single
> line feed character. On Windows, however, we set it to a carriage return
> character followed by a line feed character. Thus, we have to modify
> t0027 to expec
Hi Torsten,
On 2015-04-17 19:00, Torsten Bögershausen wrote:
> On 2015-04-17 17.44, Torsten Bögershausen wrote:
>> Without this patch, t0027 expects the native end-of-lines to be a single
>> line feed character. On Windows, however, we set it to a carriage return
>> character followed by a line fe
Torsten Bögershausen writes:
>> +--[no-]fold-case::
>> +When files/directories with the same name but a different case
>> +are detected, they are treated as the same (--fold-case) or as
>> +being different (--no-fold-case). The default is --fold-case
>> +when `core.ignorecase` is
Jeff King writes:
>> Option 1:
>> Plug the hole in my new is_git_repository function. A quick and dirty
>> fix that passes the above test would be:
>
> I think that makes sense. It would be nice if you could just call
> read_gitfile, but that function is very anxious to die on error. So the
> p
On Fri, Apr 17, 2015 at 08:15:40PM +0200, erik elfström wrote:
> > Doesn't this implementation get confused by modern submodule
> > checkouts and descend into and clean their working tree, though?
> > Module M with path P would have a directory P in the working tree of
> > the top-level project, a
Ossi Herrala writes:
> The name (not user) and email setting should be in config section
> "user" and not in "core" as documented in Documentation/config.txt.
>
> Signed-Off-By: Ossi Herrala
> Reviewed-by: Jeff King
Thanks ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" i
On Sat, Apr 18, 2015 at 12:15:28AM +0530, karthik nayak wrote:
> >But now we use type_from_string_gently, which can accept a length[1]. So
> >we could just count the bytes to the first space and pass the original
> >buffer along with that length, no?
>
> Yes, we could, that would eliminate "stru
Michael J Gruber writes:
>> Similarly I think it is not very consistent that one cannot combine any of
>> the above options with the "S" but instead have yet another option
>> called "pickaxe-regex" to toggle between "fixed-string" and
>> "extended-regexp" semantics for the argument passed to opt
On 04/17/2015 07:53 PM, Jeff King wrote:
On Wed, Apr 15, 2015 at 06:18:24PM -0400, Jeff King wrote:
>> This _might_ have some performance impact in that strbuf_addch()
>> involves strbuf_grow(*, 1), which does "does it overflow to
>> increment sb->len by one?"; I would say it should be unmeasu
Stefan Beller writes:
> * We keep the speed on small transactions
> (no close and reopen of fds in small transactions)
>
> * No refactoring for refs included, only minimally invasive to the refs.c code
>
> * applies on top of origin/sb/remove-fd-from-ref-lock replacing the last
> commit ther
On Wed, Apr 15, 2015 at 7:56 PM, Junio C Hamano wrote:
> Erik Elfström writes:
>
>> Before this change, clean used resolve_gitlink_ref to check for the
>> presence of nested git repositories. This had the drawback of creating
>> a ref_cache entry for every directory that should potentially be
>>
Jeff King writes:
> On Fri, Mar 27, 2015 at 12:00:05PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > It is possible that we may drop an object that is depended
>> > upon by another object in the alternate. For example,
>> > imagine two repositories, A and B, with A pointing to B a
Michael J Gruber writes:
>> Similarly I think it is not very consistent that one cannot combine any of
>> the above options with the "S" but instead have yet another option
>> called "pickaxe-regex" to toggle between "fixed-string" and
>> "extended-regexp" semantics for the argument passed to opt
On Fri, Apr 17, 2015 at 7:26 AM, Michael J Gruber
wrote:
>>
>> Similarly I think it is not very consistent that one cannot combine any of
>> the above options with the "S" but instead have yet another option
>> called "pickaxe-regex" to toggle between "fixed-string" and
>> "extended-regexp" semant
Dear friend,
Please do accept my apologies as I do not wish to invade into your
privacy, I had written an earlier mail to you but without response. My
name is Coffi Kelly, I am a lawyer by profession based in Lome-Togo. I
need your urgent assistance for the claiming of the sum of US$9.2
Million be
The name (not user) and email setting should be in config section
"user" and not in "core" as documented in Documentation/config.txt.
Signed-Off-By: Ossi Herrala
Reviewed-by: Jeff King
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.ke
The name (not user) and email setting should be in config section
"user" and not in "core" as documented in Documentation/config.txt.
---
builtin/config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index d32c532..bfd3016 100644
--- a
On 2015-04-17 17.44, Torsten Bögershausen wrote:
> Without this patch, t0027 expects the native end-of-lines to be a single
> line feed character. On Windows, however, we set it to a carriage return
> character followed by a line feed character. Thus, we have to modify
> t0027 to expect different w
On 04/17/2015 01:52 PM, Mike Hommey wrote:
> Currently, fast-import does case folding depending on `core.ignorecase`.
> `core.ignorecase` depends on the file system where the working tree is.
> However, different kind of imports require different kinds of semantics,
> and they usually aren't tie
Jeff King writes:
> If it's not a problem, I'd love to see timings for your case with just
> the first patch, and then with both.
Thanks for two quick progress patches.
> You may also be interested in:
>
> http://thread.gmane.org/gmane.comp.version-control.git/266370
>
> which addresses anoth
Without this patch, t0027 expects the native end-of-lines to be a single
line feed character. On Windows, however, we set it to a carriage return
character followed by a line feed character. Thus, we have to modify
t0027 to expect different warnings depending on the end-of-line markers.
Adjust the
Make more clear what the tests are doing:
commit_check_warn():
Commit files and checks for conversion warnings.
Old name: create_file_in_repo()
checkout_files():
Checkout files from the repo and check if they have
the appropriate line endings in the work space.
Old name: ch
When commit fe8e3b7 refactored type_from_string to allow
input that was not NUL-terminated, it switched to using
strncmp instead of strcmp. But this means we check only the
first "len" bytes of the strings, and ignore any remaining
bytes in the object_type_string. We should make sure that it
is als
On Fri, Apr 17, 2015 at 05:50:10PM +0300, Ossi Herrala wrote:
> The name (not user) and email setting should be in config section
> "user" and not in "core" as documented in Documentation/config.txt.
Well, those probably weren't helping any new users, then,
were they? :)
> diff --git a/builtin/
The name (not user) and email setting should be in config section
"user" and not in "core" as documented in Documentation/config.txt.
---
builtin/config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index d32c532..bfd3016 100644
--- a
Tim Friske venit, vidit, dixit 17.04.2015 12:00:
> Hi,
>
> I wonder why "git log -G" works with the "regexp-ignore-case"
> option but not with the other regexp-related options? Wouldn't it be
> useful to make the "G" option support the following options?
>
> * basic-regexp
> * extended-regex
Signed-off-by: Michael J Gruber
---
Documentation/rev-list-options.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index f620ee4..77ac439 100644
--- a/Documentation/rev-list-options.txt
+++ b/Docu
On Fri, Apr 17, 2015 at 05:30:22PM +1000, Stefan Saasen wrote:
> The merge is created in a temporary location that uses alternates. The
> temporary repository is on a local disk, the alternate object database
> on an NFS mount.
Is the alternate writeable? If we can't freshen the object, we fall b
On Wed, Apr 15, 2015 at 06:18:24PM -0400, Jeff King wrote:
> > This _might_ have some performance impact in that strbuf_addch()
> > involves strbuf_grow(*, 1), which does "does it overflow to
> > increment sb->len by one?"; I would say it should be unmeasurable
> > because the function is expected
On Fri, Mar 27, 2015 at 12:00:05PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > It is possible that we may drop an object that is depended
> > upon by another object in the alternate. For example,
> > imagine two repositories, A and B, with A pointing to B as
> > an alternate. Now imag
Thanks, all. I will update the patch as requested and resend a [PATCH
v3]. This time without the redundant headers. I will also make an
extra effort to make sure that the raw tabs do not get converted to
spaces this time. Oof, I am really out of practice at programming with
raw tabs, much less gett
Currently, fast-import does case folding depending on `core.ignorecase`.
`core.ignorecase` depends on the file system where the working tree is.
However, different kind of imports require different kinds of semantics,
and they usually aren't tied with the file system, but with the data being
import
On Thu, Apr 16, 2015 at 5:01 AM, Jeff King wrote:
> We spend a lot of time in strbuf_getwholeline in a tight
> loop reading characters from a stdio handle into a buffer.
> The libc getdelim() function can do this for us with less
> overhead. It's in POSIX.1-2008, and was a GNU extension
> before t
Hi,
I wonder why "git log -G" works with the "regexp-ignore-case"
option but not with the other regexp-related options? Wouldn't it be
useful to make the "G" option support the following options?
* basic-regexp
* extended-regexp
* fixed-strings
* perl-regexp
Similarly I think it is not
We became aware of slow merge times with the following setup:
The merge is created in a temporary location that uses alternates. The
temporary repository is on a local disk, the alternate object database
on an NFS mount.
After some investigation we believe that #33d4221 (present in git
2.2.0, abs
Hi Dave,
On 2015-04-16 19:06, Johannes Schindelin wrote:
> On 2015-04-16 18:31, David Miller wrote:
>> From: Jeff King
>> Date: Thu, 16 Apr 2015 12:26:21 -0400
>>
>>> Weird. In a nearby thread with the same problem, the first email that
>>> mentions git-owner in a cc header is yours[1]. It's in r
59 matches
Mail list logo
