Re: [PATCH 2/2] Documentation: convert SubmittingPatches to AsciiDoc
On Tue, Oct 31, 2017 at 6:21 PM, Johannes Schindelin wrote: > Hi Paolo, > > On Mon, 30 Oct 2017, Paolo Ciarrocchi wrote: > >> On Mon, Oct 30, 2017 at 1:35 PM, Johannes Schindelin >> wrote: >> > >> > 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 >> :-) > > 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
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
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
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
On Tue, Nov 18, 2014 at 1:25 AM, David Turner 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
On Fri, May 16, 2014 at 10:41 AM, Jeff King 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?
On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras wrote: > > Paolo Ciarrocchi wrote: > > On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty > > wrote: > > > > 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
On Mon, Jun 10, 2013 at 11:47 PM, Felipe Contreras 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
