Re: [PATCH 2/2] Documentation: convert SubmittingPatches to AsciiDoc

[Paolo Ciarrocchi]

On Tue, Oct 31, 2017 at 6:21 PM, Johannes Schindelin
<johannes.schinde...@gmx.de> wrote:
> Hi Paolo,
>
> On Mon, 30 Oct 2017, Paolo Ciarrocchi wrote:
>
>> On Mon, Oct 30, 2017 at 1:35 PM, Johannes Schindelin
>> <johannes.schinde...@gmx.de> wrote:
>> >
>> > On Mon, 30 Oct 2017, Junio C Hamano wrote:
>> >
>> >> "brian m. carlson" <sand...@crustytoothpaste.net> writes:
>> >>
>> >> Thanks.  I personally prefer the plain-text original, but I do
>> >> understand the need to have a version with ids that you can tell
>> >> others to visit in their browsers.  Assuming that this goes in the
>> >> right direction, here are a few comments.
>> >
>> > If you want to go into the direction of the web, AsciiDoc is actually the
>> > wrong choice IMO, and Markdown would be the right choice. Basically
>> > everybody on the web is either supporting Markdown or being asked by users
>> > to do so.
>> >
>> > Assuming that *that* is something we want to pursue, I would also suggest
>> > to move the man pages away from AsciiDoc to Markdown (using e.g.
>> > [ronn](https://rtomayko.github.io/ronn/ronn.1.html)).
>>
>> Nitpick, the right URL is: https://rtomayko.github.io/ronn/ronn.1.html
>> You put an extra ')' at the end and therefore I've got a scaring 404 error 
>> :-)
>
> The first closing parenthesis closes the link associated with the label
> `ronn`, the second closing parenthesis closes the remark I started in the
> previous line (beginning with the word "using").


You are right. I've got confused by the fact that gmail fails to
properly handle that link.
Sorry for the noise.

Regards,
-- 
Paolo

Re: [PATCH 2/2] Documentation: convert SubmittingPatches to AsciiDoc

[Paolo Ciarrocchi]

On Mon, Oct 30, 2017 at 1:35 PM, Johannes Schindelin
 wrote:
> Hi,
>
> On Mon, 30 Oct 2017, Junio C Hamano wrote:
>
>> "brian m. carlson"  writes:
>>
>> Thanks.  I personally prefer the plain-text original, but I do
>> understand the need to have a version with ids that you can tell
>> others to visit in their browsers.  Assuming that this goes in the
>> right direction, here are a few comments.
>
> If you want to go into the direction of the web, AsciiDoc is actually the
> wrong choice IMO, and Markdown would be the right choice. Basically
> everybody on the web is either supporting Markdown or being asked by users
> to do so.
>
> Assuming that *that* is something we want to pursue, I would also suggest
> to move the man pages away from AsciiDoc to Markdown (using e.g.
> [ronn](https://rtomayko.github.io/ronn/ronn.1.html)).

Nitpick, the right URL is: https://rtomayko.github.io/ronn/ronn.1.html
You put an extra ')' at the end and therefore I've got a scaring 404 error :-)

Ciao,
-- 
Paolo

Re: [PATCH 0/5] Use watchman to reduce index refresh time

[Paolo Ciarrocchi]

On Tue, Nov 3, 2015 at 10:21 AM, Duy Nguyen  wrote:
>> It was from last year. I may have measured it but because I didn't
>> save it in the commit message, it was lost anyway. Installing watchman
>> and measuring with webkit.git soon..
>
> Test repo: webkit.git with 104665 tracked files, 5615 untracked,
> 3517 dirs. Best numbers out of a few tries. This is best case
> scenario. Normal usage could have worse numbers.
>
> There is something strange about the "-uno" measurements. I don't
> think watchman+untracked cache can beat -uno..  Maybe I did something
> wrong.
>
> 0m0.383s   index v2
> 0m0.351s   index v4
> 0m0.352s   v2 split-index
> 0m0.309s   v2 split index-helper
> 0m0.159s   v2 split helper untracked-cache
> 0m0.123s   v2 split helper "status -uno"
> 0m0.098s   v2 split helper untracked watchman
> 0m0.071s   v2 split helper watchman "status -uno"
>
> Note, the watchman series needs
> s/free_watchman_shm/release_watchman_shm/ (I didn't do a good job
> of testing after rebase). And there's a small bug in index-helper
> --detach code writing incorrect PID..


Impressive improvements!

Ciao,
Paolo

-- 
Paolo
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] Use watchman to reduce index refresh time

[Paolo Ciarrocchi]

On Sun, Nov 1, 2015 at 2:55 PM, Nguyễn Thái Ngọc Duy  wrote:

Hi Duy,

> This series builds on top of the index-helper series I just sent and
> uses watchman to keep track of file changes in order to avoid lstat()
> at refresh time. The series can also be found at [1]
>
> When I started this work, watchman did not support Windows yet. It
> does now, even if still experimental [2]. So Windows people, please
> try it out if you have time.
>
> To put all pieces so far together, we have split-index to reduce index
> write time, untracked cache to reduce I/O as well as computation for
> .gitignore, index-helper for index read time and this series for
> lstat() at refresh time. The remaining piece is killing lstat() from
> untracked cache, but right now it's just some idea and incomplete
> code.

Did you manage to measure the speedup introduced by this series?

Ciao,
-- 
Paolo
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] On watchman support

[Paolo Ciarrocchi]

On Tue, Nov 18, 2014 at 1:25 AM, David Turner dtur...@twopensource.com wrote:

 My patches are not the world's most beautiful, but they do work.

Out of curiosity: do you run the patches at twitter?

Thanks.

-- Paolo


-- 
Paolo
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] remote-helpers: point at their upstream repositories

[Paolo Ciarrocchi]

On Fri, May 16, 2014 at 10:41 AM, Jeff King p...@peff.net wrote:
 But that being said, this is Felipe's code. While we have a legal right
 to distribute it in v2.0, if he would really prefer it out for v2.0, I
 would respect that.

My understanding is that Felipe would prefer to keep it _in_ the git.git
repository and eventually get it included in the core.

Regards,
-- 
Paolo
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Should git-remote-hg/bzr be part of the core?

[Paolo Ciarrocchi]

On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:

 Paolo Ciarrocchi wrote:
  On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty 
  mhag...@alum.mit.eduwrote:
 

  While I agree with you the this project is managed in a bit conservative
  way

 Only a bit? I don't think I've been involed in a more conservative open
 source project.

  you should really improve how you communicate with other developers,
  it's such a pity your contributions are some times not included in
  git.git just because of your attitude.

 But that's a theory. You don't *know* that they would have been included
 had I used a different attitude.

Well, you could at least try to act and communicate differently.

 In fact, people have contacted me privately saying similar things, and
 I'll give you the same challenge I gave them. If you think a different
 attitude would get my patches in, how about *you* write the commit
 messages and the discussions for one of my stuck patch series. I'll send
 the mails as if I had written the content.

No, sorry but I'm NOT interested in lying to git community.

Ciao,
-- 
Paolo
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [IGNORE] Implement 'git rebase' in ruby

[Paolo Ciarrocchi]

On Mon, Jun 10, 2013 at 11:47 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:

 This is not my first patch that gets rejected, but it's the first one
 that gets rejected by Junio without even looking at it. What is
 anybody supposed to think about that?

My very humble opinion: submit again the series without including in
the cover letter This patch will not be applied
and then handle the feedbacks.

In short, everybody should simply approach again your work with a fresh mind.

regards,
--
Paolo
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html