Duy Nguyen writes:
> On Fri, Aug 9, 2013 at 11:29 PM, Andres Perera wrote:
>> On Thu, Aug 8, 2013 at 6:35 AM, Nguyễn Thái Ngọc Duy
>> wrote:
>>> + uintmax_t pid;
>>
>> pid_t is always an signed type, therefore unintmax_t does not make
>> sense as a catch all value
>
> I only catch real p
On Fri, Aug 9, 2013 at 11:29 PM, Andres Perera wrote:
> On Thu, Aug 8, 2013 at 6:35 AM, Nguyễn Thái Ngọc Duy
> wrote:
>> + uintmax_t pid;
>
> pid_t is always an signed type, therefore unintmax_t does not make
> sense as a catch all value
I only catch real process id. In practice we don't
Andres Perera writes:
>> +/* return NULL on success, else hostname running the gc */
>> +static const char *lock_repo_for_gc(int force, pid_t* ret_pid)
>> +{
>> + static struct lock_file lock;
>> + static char locking_host[128];
>> + char my_host[128];
>> + struct strbuf s
On Thu, Aug 8, 2013 at 6:35 AM, Nguyễn Thái Ngọc Duy wrote:
> This may happen when `git gc --auto` is run automatically, then the
> user, to avoid wait time, switches to a new terminal, keeps working
> and `git gc --auto` is started again because the first gc instance has
> not clean up the reposi
Duy Nguyen writes:
> On Fri, Aug 9, 2013 at 1:12 AM, Junio C Hamano wrote:
>> When we see a recent lockfile created by a "gc" running elsewhere,
>> we do not set "should_exit". Is that a good thing? I am wondering
>> if the last two lines should be:
>>
>> - !strcmp(locking_host, my_host)
On Fri, Aug 9, 2013 at 1:12 AM, Junio C Hamano wrote:
> When we see a recent lockfile created by a "gc" running elsewhere,
> we do not set "should_exit". Is that a good thing? I am wondering
> if the last two lines should be:
>
> - !strcmp(locking_host, my_host) &&
> - !kill(pid, 0);
Nguyễn Thái Ngọc Duy writes:
> diff --git a/builtin/gc.c b/builtin/gc.c
> index 6be6c8d..99682f0 100644
> --- a/builtin/gc.c
> +++ b/builtin/gc.c
> @@ -167,11 +167,69 @@ static int need_to_gc(void)
> + ...
> + fd = hold_lock_file_for_update(&lock, git_path("gc.pid"),
> +
This may happen when `git gc --auto` is run automatically, then the
user, to avoid wait time, switches to a new terminal, keeps working
and `git gc --auto` is started again because the first gc instance has
not clean up the repository.
This patch tries to avoid multiple gc running, especially in -
8 matches
Mail list logo
