On Fri, Feb 21, 2014 at 06:47:47AM +0700, Nguyễn Thái Ngọc Duy wrote:
> This delta_stack array can grow to any length depending on the actual
> delta chain, but we forget to free it. Normally it does not matter
> because we use small_delta_stack[] from stack and small_delta_stack
> can hold 64-del
On Fri, Feb 21, 2014 at 06:35:06AM +0700, Duy Nguyen wrote:
> On the other hand, the size reduction is really nice (320MB vs 500MB).
> I don't know if we can do this, but does it make sense to apply
> --depth=250 for old commits only and shallow depth for recent commits?
>
> For old projects, comm
On Tue, Feb 18, 2014 at 8:40 AM, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> index 73e80ce..aec9fdb 100644
> --- a/strbuf.h
> +++ b/strbuf.h
> @@ -116,6 +116,10 @@ extern void strbuf_add(struct strbuf *, const void *,
> size_t);
> static inline void strbuf_addstr(s
2014-02-20 23:35 GMT+00:00 Duy Nguyen :
> does it make sense to apply
> --depth=250 for old commits only
Just wondering: would it be difficult to fix the problems that lead to
worse than linear slowdown with the --depth? (I.e. adaptive cache/hash
table size.) If the performance difference between
Junio C Hamano writes:
> Junio C Hamano writes:
>
> What is the right mental model the end-user needs to form when
> understanding these? Conditions on keys go on the left, and any
> other random conditions can come as a modifier after action
> e.g. add_if_same_value_is_not_at_the_end?
Having
On 19 February 2014 00:14, Junio C Hamano wrote:
[...]
> The patch was whitespace damaged, by the way. It was easy to hand
> tweak so there is no need to resend this particular patch, but if
> you are planning to send more patches, please check your MUA and
> tell it not to.
Suits me right for d
This delta_stack array can grow to any length depending on the actual
delta chain, but we forget to free it. Normally it does not matter
because we use small_delta_stack[] from stack and small_delta_stack
can hold 64-delta chains, more than standard --depth=50 in pack-objects.
Signed-off-by: Nguyễ
On Thu, Feb 20, 2014 at 1:59 AM, Junio C Hamano wrote:
> Philippe Vaucher writes:
>
>>> fwiw this is the thread that added --depth=250
>>>
>>> http://thread.gmane.org/gmane.comp.gcc.devel/94565/focus=94626
>>
>> This post is quite interesting:
>> http://article.gmane.org/gmane.comp.gcc.devel/9463
David Kastrup writes:
> David Kastrup writes:
>
>> Duy Nguyen writes:
>>
>> Something's _really_ fishy about that cache behavior. Note that the
>> _system_ time goes up considerably, not just user time. Since the
>> packs are zlib-packed, it's reasonable that more I/O time is also
>> associat
On Thu, Feb 20, 2014 at 1:03 PM, Jens Lehmann wrote:
> Sorry for the late reply, but here we go ...
>
> Am 10.02.2014 07:33, schrieb Gábor Lipták:
>> Hi Jens,
>>
>> So "git status" says:
>>
>> liptak@liptak-kubuntu:~/Projects/MAIN_MODULE/platform/SUBMODULE
>> [master]$ git status
>> # On branch ma
Sorry for the late reply, but here we go ...
Am 10.02.2014 07:33, schrieb Gábor Lipták:
> Hi Jens,
>
> So "git status" says:
>
> liptak@liptak-kubuntu:~/Projects/MAIN_MODULE/platform/SUBMODULE
> [master]$ git status
> # On branch master
> # Your branch is up-to-date with 'origin/master'.
> #
> #
Hello,
I'm playing around with git-notes and want to share some of my notes
with my co-workers. We have a central repository for our various topic
branches and want to track upstream inclusion in git-notes. So we have
to share our notes branch somehow.
The workflow I think makes sense here is (un
On Wed, Feb 19, 2014 at 09:19:24PM +0700, Duy Nguyen wrote:
> > We don't need to do any of that immediately. This is mostly just me
> > thinking aloud, to make sure we do not paint ourselves into a corner
> > compatibility-wise.
>
> Good thinking. If you plan to use the exact same sort syntax f-
Duy Nguyen writes:
>> But why is it OK to fail in the first place? If we couldn't link,
>> don't you want to fall back to the lock codepath? After all, the
>> "are we on the same device?" check is to cope with the case where
>> we cannot link and that alternate codepath is supposed to be
>> pre
Nguyễn Thái Ngọc Duy writes:
> @@ -2717,17 +2729,19 @@ static int copy_msg(char *buf, const char *msg)
> return cp - buf;
> }
>
> -int log_ref_setup(const char *refname, char *logfile, int bufsize)
> +int log_ref_setup(const char *refname, struct strbuf *sb_logfile)
> {
> int log
Junio C Hamano writes:
> Duy Nguyen writes:
>
>> On Thu, Feb 20, 2014 at 3:17 AM, Junio C Hamano wrote:
+ strbuf_setlen(sb, len);
+ strbuf_add(sb, s, strlen(s));
>>>
>>> I am not sure addstr_at() gives us a good abstraction, or at least
>>> the name conveys what it does well n
Max Horn writes:
> On 19.02.2014, at 22:41, Junio C Hamano wrote:
>
>> * fc/transport-helper-fixes (2013-12-09) 6 commits
>> - remote-bzr: support the new 'force' option
>> - test-hg.sh: tests are now expected to pass
>> - transport-helper: check for 'forced update' message
>> - transport-helper
Duy Nguyen writes:
> On Thu, Feb 20, 2014 at 3:17 AM, Junio C Hamano wrote:
>>> + strbuf_setlen(sb, len);
>>> + strbuf_add(sb, s, strlen(s));
>>
>> I am not sure addstr_at() gives us a good abstraction, or at least
>> the name conveys what it does well not to confuse readers.
>>
>> At fi
On 19.02.2014, at 22:41, Junio C Hamano wrote:
> * fc/transport-helper-fixes (2013-12-09) 6 commits
> - remote-bzr: support the new 'force' option
> - test-hg.sh: tests are now expected to pass
> - transport-helper: check for 'forced update' message
> - transport-helper: add 'force' to 'export'
Duy Nguyen writes:
> OK so your question was if there was a git_path() or mkpath() call
> earlier in update_refs_for_switch() and the result was expected to
> remain stable till the end of update_refs_for_switch(), then this
> conversion could ruin it, correct? I didn't think about that,...
Yeah
Michael Haggerty writes:
> I wonder whether we could give a way to specify a reference in an
> unambiguous, canonical fashion like I expected, for example by using a
> leading slash: "/refs/heads/mybranch". This could be a way for the user
> to ask for DWIMming to be turned off without having to
On Thu, 20 Feb 2014 12:06:17, Michael Haggerty wrote:
>On 02/19/2014 11:58 PM, Jan Engelhardt wrote:
>>
>> Looking at it from one more angle, `git fetch r --tags` and
>> `git push r --tags` is now no longer symmetric :(
>
>I'm glad you brought this up, because I didn't really think about
>whether
David Kastrup writes:
> Duy Nguyen writes:
>
>> I can think of two improvements we could make, either increase cache
>> size dynamically (within limits) or make it configurable. If we have N
>> entries in worktree (both trees and blobs) and depth M, then we might
>> need to cache N*M objects for
Duy Nguyen writes:
> I can think of two improvements we could make, either increase cache
> size dynamically (within limits) or make it configurable. If we have N
> entries in worktree (both trees and blobs) and depth M, then we might
> need to cache N*M objects for it to be effective. Christian,
Hello,
I started playing around with sharing git notes and so was happy to see
that git-notes learned about merging since I last tried.
My first try looked as follows (using git 1:1.9.0-1 from Debian):
$ git fetch $someremote refs/notes/commits
...
$ git notes merge FETCH
On Thu, Feb 20, 2014 at 5:08 AM, Eric Sunshine wrote:
>> +static dev_t get_device_or_die(const char *path)
>> +{
>> + struct stat buf;
>> + if (stat(path, &buf))
>> + die_errno("failed to stat '%s'", path);
>> + /* Ah Windows! Make different drives different "partit
On Thu, Feb 20, 2014 at 3:32 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
> (Only nitpicks during this round of review).
>
>> + if (get_device_or_die(path) != get_device_or_die(get_git_dir())) {
>> + strbuf_reset(&sb);
>> + strbuf_addf(&sb, "%s/locked",
Hi Semyon,
Am 18.02.2014 18:49, schrieb Semyon Perepelitsa:
> I noticed the option in the man-page but there is still no configuration
> option available. Did you forget to add it after all?
Nope, we just didn't implement it yet. ;-)
It's one of the topics on my submodule ToDo list:
https://
On Thu, Feb 20, 2014 at 3:17 AM, Junio C Hamano wrote:
>> + strbuf_setlen(sb, len);
>> + strbuf_add(sb, s, strlen(s));
>
> I am not sure addstr_at() gives us a good abstraction, or at least
> the name conveys what it does well not to confuse readers.
>
> At first after only seeing its name
On 02/19/2014 11:58 PM, Jan Engelhardt wrote:
> On Wednesday 2014-02-19 21:01, Junio C Hamano wrote:
>> Jan Engelhardt writes:
>>> The release notes for 1.9.0 read:
>>>
* The "--tags" option to "git fetch" no longer tells the command to
fetch _only_ the tags. It instead fetches tags _i
On Thursday 2014-02-20 00:40, Junio C Hamano wrote:
>On Wed, Feb 19, 2014 at 2:58 PM, Jan Engelhardt wrote:
> Looking at it from one more angle, `git fetch r --tags` and
>`git push r --tags` is now no longer symmetric :(
>
>
>I would have loved to hear such comments _during_ the discussion,
31 matches
Mail list logo
