Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Arif Khokar wrote: > On 02/13/2017 09:37 AM, Johannes Schindelin wrote: > >I actually had expected *you* to put in a little bit of an effort, too. In > >fact, I was very disappointed that you did not even look into porting that > >script to use public-inbox instead of

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On 02/13/2017 11:41 PM, Junio C Hamano wrote: Arif Khokar writes: One concern I have regarding this idea is whether or not SMTP servers typically replace a Message-Id header set by the client. The clients are supposed to give Message-IDs, but because some clients

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Arif Khokar writes: > One concern I have regarding this idea is whether or not SMTP servers > typically replace a Message-Id header set by the client. The clients are supposed to give Message-IDs, but because some clients fail to do so, SMTP server implementations are

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On 02/13/2017 10:56 PM, Arif Khokar wrote: I wasn't aware of that expectation. My idea was to use NNTP as a way to facilitate the development of a new git utility that would serve as the inverse of git-send-email (sort of like the relationship between git format-patch and git am), rather than

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On 02/13/2017 02:21 PM, Junio C Hamano wrote: Arif Khokar writes: ... I still think it would be better to be able to list the message-id values in the header or body of the cover letter message of a patch series (preferably the former) in order to facilitate

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Arif Khokar writes: > ... I > still think it would be better to be able to list the message-id > values in the header or body of the cover letter message of a patch > series (preferably the former) in order to facilitate downloading the > patches via NNTP from gmane or

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Hi Arif, On Mon, 13 Feb 2017, Arif Khokar wrote: > On 02/10/2017 11:10 AM, Johannes Schindelin wrote: > > > > On Wed, 24 Aug 2016, Johannes Schindelin wrote: > > > > I recently adapted an old script I had to apply an entire patch > > > series given the GMane link to its cover letter: > > > > >

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On 02/10/2017 11:10 AM, Johannes Schindelin wrote: Hi Arif, On Wed, 24 Aug 2016, Johannes Schindelin wrote: I recently adapted an old script I had to apply an entire patch series given the GMane link to its cover letter:

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Hi Arif, On Wed, 24 Aug 2016, Johannes Schindelin wrote: > On Tue, 23 Aug 2016, Arif Khokar wrote: > > > On 08/20/2016 03:57 PM, Jakub Narębski wrote: > > > > > But perhaps the problem is current lack of tooling in the opposite > > > direction, namely getting patches from mailing list and

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Hi Kuba, On Sun, 28 Aug 2016, Jakub Narębski wrote: > W dniu 25.08.2016 o 15:21, Johannes Schindelin pisze: > > On Mon, 22 Aug 2016, Jakub Narębski wrote: > >> W dniu 22.08.2016 o 15:18, Johannes Schindelin pisze: > >> > >>> So unfortunately this thread has devolved. Which is sad. Because all >

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Hi Kuba & Duy, On Sun, 28 Aug 2016, Jakub Narębski wrote: > W dniu 22.08.2016 o 15:15, Duy Nguyen pisze: > > On Mon, Aug 22, 2016 at 8:06 PM, Johannes Schindelin > > wrote: > >> > >> My point stands. We are way more uninviting to contributors than > >> necessary. And

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

W dniu 25.08.2016 o 14:58, Johannes Schindelin pisze: > On Mon, 22 Aug 2016, Eric Wong wrote: >> Johannes Schindelin wrote: >> >>> I just want developers who are already familiar with Git, and come up with >>> an improvement to Git itself, to be able to contribute it

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Hi Arif, On Thu, 25 Aug 2016, Arif Khokar wrote: > On 08/25/2016 09:01 AM, Johannes Schindelin wrote: > > > > On Thu, 25 Aug 2016, Arif Khokar wrote: > > >>> I considered recommending this as some way to improve the review > >>> process. The problem, of course, is that it is very easy to craft

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On 08/25/2016 09:01 AM, Johannes Schindelin wrote: > Hi Arif, > > On Thu, 25 Aug 2016, Arif Khokar wrote: >>> I considered recommending this as some way to improve the review process. >>> The problem, of course, is that it is very easy to craft an email with an >>> innocuous patch and then push

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Hi Kuba, On Mon, 22 Aug 2016, Jakub Narębski wrote: > W dniu 22.08.2016 o 15:18, Johannes Schindelin pisze: > > > So unfortunately this thread has devolved. Which is sad. Because all I > > wanted is to have a change in Git's submission process that would not > > exclude *so many* developers.

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Hi Eric, On Wed, 24 Aug 2016, Eric Wong wrote: > Johannes Schindelin wrote: > > > Now, with somebody like me who would lose a lot when destroying trust, > > it is highly unlikely. But it is possible that in between the hundreds > > of sincere contributors a bad

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On 08/24/2016 09:04 AM, Johannes Schindelin wrote: > Hi Philip, > > On Mon, 22 Aug 2016, Philip Oakley wrote: >> I do note that dscho's patches now have the extra footer (below the three >> dashes) e.g. >> >> Published-As: https://github.com/dscho/git/releases/tag/cat-file-filters-v1 >>

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On 08/24/2016 11:34 AM, Johannes Schindelin wrote: > Hi Arif, Hello Johannes, > On Tue, 23 Aug 2016, Arif Khokar wrote: > >> Given that public-inbox provides an NNTP interface, couldn't the ARTICLE >> NNTP command be used to easily retrieve the messages in a >> given patch series (at least

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Jeff King wrote: > On Wed, Aug 24, 2016 at 06:49:38PM +, Eric Wong wrote: > > > > Given that public-inbox provides an NNTP interface, couldn't the ARTICLE > > > > NNTP command be used to easily retrieve the messages in a > > > > given patch series (at least compared to POP or

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Johannes Schindelin wrote: > On Mon, 22 Aug 2016, Philip Oakley wrote: > > I do note that dscho's patches now have the extra footer (below the three > > dashes) e.g. > > > > Published-As: https://github.com/dscho/git/releases/tag/cat-file-filters-v1 > > Fetch-It-Via:

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On Wed, Aug 24, 2016 at 06:49:38PM +, Eric Wong wrote: > > > Given that public-inbox provides an NNTP interface, couldn't the ARTICLE > > > NNTP command be used to easily retrieve the messages in a > > > given patch series (at least compared to POP or IMAP). Perhaps > > > git-send-email

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Johannes Schindelin wrote: > On Fri, 19 Aug 2016, Eric Wong wrote: > > Johannes Schindelin wrote: > > > On Thu, 18 Aug 2016, Eric Wong wrote: > > > > Johannes Schindelin wrote: > > > > > > > > > Old dogs claim

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On Fri, Aug 19, 2016 at 09:55:54AM -0700, Stefan Beller wrote: > It was not my intend to start this discussion again with my initial email. > I rather wanted to point out how I make progress in doing my own > tooling. > > I mean if email works well for Junio (both as a maintainer as > well as a

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On Mon, Aug 22, 2016 at 8:06 PM, Johannes Schindelin wrote: > My point stands. We are way more uninviting to contributors than > necessary. And a huge part of the problem is that we require contributors > to send their patches inlined into whitespace-preserving mails.

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Hi Peff, On Fri, 19 Aug 2016, Jeff King wrote: > On Thu, Aug 18, 2016 at 02:42:34PM +0200, Johannes Schindelin wrote: > > > BTW I take this thread as yet another proof that people are unhappy > > with mail list-based review: if you have to build *that much* tooling > > around it (and Peff &

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

W dniu 19.08.2016 o 17:03, Jeff King pisze: [...] > There is nothing wrong with building tooling around your workflow. If we > had a GitHub-based workflow, I'd build tooling around that, too. One of > the things I _like_ about a mail-based workflow is how easy it is to > build that tooling, and

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Stefan Beller wrote: > Maybe we should invent a patch format that copes with broken whitespace? No redundant new formats, please. MIME attachments are already widely-supported and fine by me. But it's not my call for git. -- unsubscribe: meta+unsubscr...@public-inbox.org

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Johannes Schindelin wrote: > On Thu, 18 Aug 2016, Eric Wong wrote: > > Johannes Schindelin wrote: > > > > > Old dogs claim the mail list-approach works for them. Nope. Doesn't. > > > Else you would not have written all those custom scripts.

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

It was not my intend to start this discussion again with my initial email. I rather wanted to point out how I make progress in doing my own tooling. I mean if email works well for Junio (both as a maintainer as well as a contributor) and Jeff as a contributor, then I can adapt my workflow to

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Hi Eric, On Thu, 18 Aug 2016, Eric Wong wrote: > Johannes Schindelin wrote: > > > Old dogs claim the mail list-approach works for them. Nope. Doesn't. > > Else you would not have written all those custom scripts. > > git and cogito started as a bunch of custom

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On Thu, Aug 18, 2016 at 02:42:34PM +0200, Johannes Schindelin wrote: > BTW I take this thread as yet another proof that people are unhappy with > mail list-based review: if you have to build *that much* tooling around it > (and Peff & Junio certainly have a megaton of advanced and sophisticated >

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Eric Wong writes: > I see a choice of mail client as no different than a choice of > text editor. Neither my mail client or text editor is heavily > customized. The key feature I rely on from both tools is piping > data to external commands. FWIW, that applies to me exactly,

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Johannes Schindelin wrote: > BTW I take this thread as yet another proof that people are unhappy with > mail list-based review: if you have to build *that much* tooling around it > (and Peff & Junio certainly have a megaton of advanced and sophisticated > tooling

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Junio C Hamano wrote: > Stefan Beller writes: > > * Should the public-inbox offer another link to patches 1-n, without > > the cover letter? Or should it add instructions: > > > > If this is a patch series you can apply it locally as: > >

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Jeff King writes: > For my workflow, it is not about "initial skip", but rather just "skip > emails that don't have patches in them at all". OK. That is different from "the subject line says 0/N so let's skip". If we can safely determine that there is no patch in a message,

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Stefan Beller writes: > In your work flow, how do you respect the cover letter? > e.g. in 3787e3c16ced: > > Merge branch 'ew/http-backend-batch-headers' > > The http-backend (the server-side component of smart-http > transport) used to trickle the HTTP header one

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On Tue, Aug 16, 2016 at 10:10 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> So as a discussion starter: >> * Should git am skip a patch 00/XX automatically ? > > No. My preference is to add "--initial-skip=", though. > > When I receive a patch

Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

> BTW in light of the discussion we are having elsewhere I just need to > point out that it was *dramatically* faster for me to edit run-command.c, > find "hooks/" and adjust the code manually than it would have been to save > the diff and apply it. > > That's because I do not have advanced