Re: Draft of Git Rev News edition 18

On Tue, Aug 16, 2016 at 09:27:04PM +, Eric Wong wrote: > Josh Triplett wrote: > > On Tue, Aug 16, 2016 at 09:30:27AM +, Eric Wong wrote: > > > Jakub Narębski wrote: > > > > It's a great pity that https://public-inbox.org/ is just > > > > directory index, not a true home page. > > > > > >

Re: Draft of Git Rev News edition 18

Josh Triplett wrote: > On Tue, Aug 16, 2016 at 09:30:27AM +, Eric Wong wrote: > > Jakub Narębski wrote: > > > It's a great pity that https://public-inbox.org/ is just > > > directory index, not a true home page. > > > > +Cc meta@public-inbox.org > > > > I'm not sure one could do better whil

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

Eric Wong wrote: > Currently for web users, I suggest: > > curl $URL >tmpXXX > > # open tmp and tag+copy to patchesXXX using MUA of choice: > # (also seems to be what Jeff describes): > mutt -f tmpXXX > > git am patches I should add this is also a better m

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: > > curl >tmpXXX > > git am tmpXXX

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, skipping it may fee

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 at a time. Now >

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 series to reroll another series, I somehow

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

On Tue, Aug 16, 2016 at 10:10:42AM -0700, 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 series to reroll another serie

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

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 series to reroll another series, I somehow know and verify that earlier N patches have not changed, I detach th

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 tooling

Re: Draft of Git Rev News edition 18

On Tue, Aug 16, 2016 at 09:30:27AM +, Eric Wong wrote: > Jakub Narębski wrote: > > It's a great pity that https://public-inbox.org/ is just > > directory index, not a true home page. > > +Cc meta@public-inbox.org > > I'm not sure one could do better while staying true to the > minimalist nat

Re: Draft of Git Rev News edition 18

Jakub Narębski wrote: > It's a great pity that https://public-inbox.org/ is just > directory index, not a true home page. +Cc meta@public-inbox.org I'm not sure one could do better while staying true to the minimalist nature of plain-text email. In the spirit of decentralization, there may not

[PATCH 1/2] search: drop pointless range processors for Unix timestamp

The Unix timestamp isn't meaningful for users searching, we will start indexing the MMDD date stamp which may use StringValueRangeProcessor, instead. --- lib/PublicInbox/Search.pm | 10 -- 1 file changed, 10 deletions(-) diff --git a/lib/PublicInbox/Search.pm b/lib/PublicInbox/Search.

[PATCH 0/2] search: support YYYYMMDD search ranges

Not deployed to clear-net sites, yet, I'm reindexing the http://czquwvybam4bgbro.onion/git/ onion right now. Eric Wong (2): search: drop pointless range processors for Unix timestamp search: add MMDD search range via "d:" prefix lib/PublicInbox/Search.pm| 13 +++-- li

[PATCH 2/2] search: add YYYYMMDD search range via "d:" prefix

This is similar to mairix in that it uses a "d:" prefix; but only takes MMDD, for now. Using custom date/time parsers via Perl will be much more work: nntp://news.gmane.org/20151005222157.ge5...@survex.com Anyhow, this ought to be more human-friendly than searching by Unix timestamps

[PATCH] HACKING: minor updates and add to the website

Also, at least add one of the Tor mirrors (the rest will be discoverable through the mirrors themselves). --- Documentation/include.mk | 3 ++- HACKING | 19 +++ README | 5 + 3 files changed, 22 insertions(+), 5 deletions(-) diff --git a/D