All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Beller <stefanbeller@googlemail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
	pclouds@gmail.com, iveqy@iveqy.com, git@vger.kernel.org
Subject: Re: [PATCH 1/4] Build in git-repack
Date: Wed, 07 Aug 2013 18:45:50 +0200	[thread overview]
Message-ID: <520279BE.90704@googlemail.com> (raw)
In-Reply-To: <7v38qlec2w.fsf@alter.siamese.dyndns.org>

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

On 08/07/2013 05:48 PM, Junio C Hamano wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>>
>> seems overkill to me: why don't you just let cmd_repack call
>> update_server_info(0)?
> 
> My feeling exactly.  I would rather see a patch that does not touch
> pack-objects at all, and use run_command() interface to spawn it.
> Once we do have to pack, the necessary processing cycle will dwarf
> the fork/exec latency anyway, no?
> 

Thanks for clarification. That was my initial idea as well, 
to not touch the pack-objects logic. 

However Duy send that patch (basically as is, 
I just made it apply again), 
and I guessed that I'd get to results
faster with an already existing approach.

I will reconsider and try to remove the additional logic from 
pack-objects again (so it will not get touched) and move it to the
repack itself. It is just a way to understand, 'what needs to be done'.

Stefan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

  reply	other threads:[~2013-08-07 16:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-02 13:48 Rewriting git-repack.sh in C Stefan Beller
2013-08-02 14:10 ` Duy Nguyen
2013-08-02 16:36   ` Duy Nguyen
2013-08-03  6:33   ` Fredrik Gustafsson
2013-08-03 10:03     ` Duy Nguyen
2013-08-07 14:00       ` [PATCH 0/4] " Stefan Beller
2013-08-07 14:00         ` [PATCH 1/4] Build in git-repack Stefan Beller
2013-08-07 14:28           ` Matthieu Moy
2013-08-07 15:48             ` Junio C Hamano
2013-08-07 16:45               ` Stefan Beller [this message]
2013-08-08  2:44               ` Duy Nguyen
2013-08-07 14:00         ` [PATCH 2/4] backup_file dummy function Stefan Beller
2013-08-08  2:45           ` Duy Nguyen
2013-08-07 14:00         ` [PATCH 3/4] pack-objects: do not print usage when repacking Stefan Beller
2013-08-08  6:40           ` Antoine Pelisse
2013-08-07 14:00         ` [PATCH 4/4] repack: add unpack-unreachable Stefan Beller
2013-08-05 10:34 ` Rewriting git-repack.sh in C Matthieu Moy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=520279BE.90704@googlemail.com \
    --to=stefanbeller@googlemail.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=iveqy@iveqy.com \
    --cc=pclouds@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.