On Thu, Feb 25, 2016 at 5:31 PM, Ævar Arnfjörð Bjarmason
wrote:
> On Wed, Feb 24, 2016 at 11:09 PM, Christian Couder
> wrote:
>
> [Resent because I was accidentally in GMail's HTML mode and the ML rejected
> it]
>
>> If there was a config option called maybe "rebase.taskset" or
>> "rebase.setcpu
On Thu, Feb 25, 2016 at 10:42 AM, Duy Nguyen wrote:
> On Thu, Feb 25, 2016 at 7:50 AM, Duy Nguyen wrote:
>> On Thu, Feb 25, 2016 at 5:09 AM, Christian Couder
>> wrote:
>>> Another possibility would be to libify the "git apply" functionality
>>> and then to use the libified "git apply" in run_app
On Fri, Feb 26, 2016 at 7:45 AM, Johannes Schindelin
wrote:
> Hi Matthieu,
>
> On Thu, 25 Feb 2016, Matthieu Moy wrote:
>
>> Ævar Arnfjörð Bjarmason writes:
>>
>> > At the risk of derailing this thread, a thing that would make rebase
>> > even faster I think would be to change it so that instead
Hi Matthieu,
On Thu, 25 Feb 2016, Matthieu Moy wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > At the risk of derailing this thread, a thing that would make rebase
> > even faster I think would be to change it so that instead of applying
> > a patch at a time to the working tree the whole operat
Ævar Arnfjörð Bjarmason writes:
> At the risk of derailing this thread, a thing that would make rebase
> even faster I think would be to change it so that instead of applying
> a patch at a time to the working tree the whole operation takes place
> on temporary trees & commits and then we'll even
On Wed, Feb 24, 2016 at 11:09 PM, Christian Couder
wrote:
[Resent because I was accidentally in GMail's HTML mode and the ML rejected it]
> If there was a config option called maybe "rebase.taskset" or
> "rebase.setcpuaffinity" that could be set to ask the OS for all the
> rebase child processes
On Thu, Feb 25, 2016 at 7:50 AM, Duy Nguyen wrote:
> On Thu, Feb 25, 2016 at 5:09 AM, Christian Couder
> wrote:
>> Another possibility would be to libify the "git apply" functionality
>> and then to use the libified "git apply" in run_apply() instead of
>> launching a separate "git apply" process
Duy Nguyen writes:
> On Thu, Feb 25, 2016 at 5:09 AM, Christian Couder
> wrote:
>> Another possibility would be to libify the "git apply" functionality
>> and then to use the libified "git apply" in run_apply() instead of
>> launching a separate "git apply" process. One benefit from this is
>> t
On Thu, Feb 25, 2016 at 10:02 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Thu, Feb 25, 2016 at 5:09 AM, Christian Couder
>> wrote:
>>> Another possibility would be to libify the "git apply" functionality
>>> and then to use the libified "git apply" in run_apply() instead of
>>> launch
On Thu, Feb 25, 2016 at 5:09 AM, Christian Couder
wrote:
> Another possibility would be to libify the "git apply" functionality
> and then to use the libified "git apply" in run_apply() instead of
> launching a separate "git apply" process. One benefit from this is
> that we could probably get rid
On Wed, Feb 24, 2016 at 4:15 PM, Jacob Keller wrote:
> On Wed, Feb 24, 2016 at 2:09 PM, Christian Couder
> wrote:
>> Hi,
>> Another possibility would be to libify the "git apply" functionality
>> and then to use the libified "git apply" in run_apply() instead of
>> launching a separate "git apply
On Wed, Feb 24, 2016 at 2:09 PM, Christian Couder
wrote:
> Hi,
> Another possibility would be to libify the "git apply" functionality
> and then to use the libified "git apply" in run_apply() instead of
> launching a separate "git apply" process. One benefit from this is
> that we could probably g
Hi,
Using GIT_TRACE_PERFORMANCE it looks like a lot of time in a regular
rebase is spent in run_apply() in builtin/am.c. This function first
sets up a 'struct child_process cp' to launch "git apply" on a patch
and then uses run_command(&cp) to actually launch the "git apply".
Then this function ca
13 matches
Mail list logo
