Lars Schneider wrote:
> > On 06 Sep 2016, at 13:38, Johannes Schindelin
> > wrote:
> > On Mon, 5 Sep 2016, Eric Wong wrote:
> >> larsxschnei...@gmail.com wrote:
> >>> -int git_open_noatime(const char *name)
> >>> +int git_open_noatime_c
Lars Schneider wrote:
> > On 06 Sep 2016, at 23:06, Eric Wong wrote:
> > larsxschnei...@gmail.com wrote:
> >> static int ce_compare_data(const struct cache_entry *ce, struct stat *st)
> >> {
> >>int match = -1;
> >> - int fd = open(ce-
Josh Triplett wrote:
> On Tue, Aug 16, 2016 at 09:27:04PM +0000, Eric Wong wrote:
> > As for other projects, I'm not aware of anybody else using it,
> > yet. I have some small projects using it, but most of those are
> > one-off throwaways and I'm not comfortable
larsxschnei...@gmail.com wrote:
> static int ce_compare_data(const struct cache_entry *ce, struct stat *st)
> {
> int match = -1;
> - int fd = open(ce->name, O_RDONLY);
> + int fd = open(ce->name, O_RDONLY | O_CLOEXEC);
>
> if (fd >= 0) {
> unsigned char sha1[2
larsxschnei...@gmail.com wrote:
> All processes that the Git main process spawns inherit the open file
> descriptors of the main process. These leaked file descriptors can
> cause problems.
> -int git_open_noatime(const char *name)
> +int git_open_noatime_cloexec(const char *name)
> {
> - st
Jakub Narębski wrote:
> W dniu 26.08.2016 o 08:15, Eric Wong pisze:
>
> > Not directly-related to the survey questions, but can you ensure
> > it's accessible to folks without JavaScript/graphics, and
> > perhaps also ensure it is on a host that is Tor-friendly?
&
Not directly-related to the survey questions, but can you ensure
it's accessible to folks without JavaScript/graphics, and
perhaps also ensure it is on a host that is Tor-friendly?
Graphics setups often require non-Free firmware or drivers for
acceptable performance; and there are also visually-im
Jeff King wrote:
> On Wed, Aug 24, 2016 at 06:49:38PM +0000, 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
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: git fetch https://github.com/
Johannes Schindelin wrote:
> Hi Arif,
>
> 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 applying them
> > > to
Alfred Perlstein wrote:
> I hadn't anticipated there be to translation between svn props and
> .gitattributes, it sounds a bit messy but possible, that said, is it
> not possible to commit .gitattribute files to the svn repo? Even in
> FreeBSD land such small token files are permitted.
I'm not s
Adding Alfred to the Cc:, more below...
Lucian Smith wrote:
> I'm attempting to use the git-svn bridge, and am having problems with
> line endings on Windows.
>
> The setup is that we have a git repository on github, and I've checked
> out a branch on my Windows machine using Tortoise svn. I ma
Jeff King wrote:
> We keep an LRU list of entries for when we need to drop
> something from an over-full cache. The list is implemented
> as a circular doubly-linked list, which is exactly what
> list.h provides. We can save a few lines by using the list.h
> macros and functions. More importantly,
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 the mail list-approach wor
Johannes Schindelin wrote:
> As Eric Wong pointed out, we need to be careful to handle the case where
> the Linux headers used to compile Git support O_CLOEXEC but the Linux
> kernel used to run Git does not: it returns an EINVAL.
> +++ b/git-compat-util.h
> @@ -667,6 +667,10 @@
Pranit Bauva wrote:
> On Sun, Aug 21, 2016 at 8:49 PM, wrote:
> > I am learning how to use git. I would like to know:
> >
> > How can I correct a typo in the message I gave to an old "git commit"? I see
> > that the typo occurs in exactly two files in .git:
> >
> > .git/logs/refs/heads/master
>
Nikolaus Rath wrote:
> What's the easiest way to find the most recent revision (of any file in
> the repository, including those that have been deleted in the current
> HEAD) that contains a given string?
I normally do something like:
git log -r --raw -p -SSTRING
git log -r --raw
Jakub Narębski wrote:
> Other version control systems
>
> 20. What other version control systems (SCM) do you use beside Git?
>(multiple choice, with other)
>
> Explanation: "using" version control system here means using
> it to actively contribute (propose changes or accept proposals)
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.
> >
>
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the
Brian Henderson wrote:
> On Wed, Aug 10, 2016 at 08:56:35AM +0000, Eric Wong wrote:
> > "local" is not a portable construct. It's common for
> > Debian/Ubuntu systems to use dash as /bin/sh instead of bash;
> > (dash is faster, and mostly sticks to POSIX)
Brian Henderson wrote:
> On Fri, Aug 19, 2016 at 11:10:55AM -0700, Junio C Hamano wrote:
> >
> > > +# vim: set noet
> >
> > We tend to avoid cluttering the source with editor specific insns
> > like this.
>
> oops.
>
> Anyone have any suggestions for project level vim settings?
vim defaults w
Junio C Hamano wrote:
> Our codepaths themselves generally do not care about O_CLOEXEC, so
> giving a racy emulation of it is not worth the effort, making the
> later half of the above an overkill.
OK.
> Perhaps the three lines to
> define O_CLOEXEC to 0 on older UNIX might be sufficient.
I'd b
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 around it, holy cow!) it is really
Johannes Schindelin wrote:
> +++ b/compat/mingw.h
> @@ -67,6 +67,10 @@ typedef int pid_t;
> #define F_SETFD 2
> #define FD_CLOEXEC 0x1
>
> +#if !defined O_CLOEXEC && defined O_NOINHERIT
> +#define O_CLOEXECO_NOINHERIT
> +#endif
> +++ b/tempfile.c
> @@ -120,7 +120,7 @@ int create_tempfile
Philip Oakley wrote:
> Would including a 'help' link on the main pages be possible? Maybe to the
> www-design page or whatever, just to make the users aware of the wider
> resourses, and a few key ways of entering search queries (such as the
> "gmane:123456" which gets that msg, while "gmane/12345
Josh Triplett wrote:
> On Tue, Aug 16, 2016 at 09:30:27AM +0000, 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 m...@public-inbox.o
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 sh
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
Jakub Narębski wrote:
> It's a great pity that https://public-inbox.org/ is just
> directory index, not a true home page.
+Cc m...@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
Philip Oakley wrote:
> From: "Eric Wong"
> >Philip Oakley wrote:
> >>From: "Christian Couder"
> >>>You can also reply to this email.
> >>
> >>I see you mention in passing (weel in the small headings near the bottom)
> &g
Philip Oakley wrote:
> From: "Christian Couder"
> >You can also reply to this email.
>
> I see you mention in passing (weel in the small headings near the bottom)
> that gmane web interface has gone away. It may be worth noting a few of the
> alternatives, and in particular Eric's newly updated
Philip Oakley wrote:
> From: "Eric Wong"
> >
> >Yes, I was somewhat careful to check for proper mboxes from gmane;
> >I just missed entire ranges :x
> >
>
> There were a number of messages that were listed by gmane as being in the
> various Git for
Eric Wong wrote:
> Thanks, should all be imported.
Oops, missed one which was missing X-Mailing-List (causing
it to not get imported) and had "X-No-Archive: yes" set;
which meant I couldn't get it from gmane this year.
Hmm... XNAY defeats the point of public-inbox (and pro
Jeff King wrote:
> I collected the message-ids from my archive. Interestingly, I had a
> dozen or so that did not have message-ids at all. I think most of them
> are from patches that put the "From " line in the body, like this one:
>
> http://public-inbox.org/git/20070311033833.gb10...@spearce
Jeff King wrote:
> On Fri, Aug 12, 2016 at 10:42:55PM +0000, Eric Wong wrote:
> > Junio C Hamano wrote:
> > > is still available. An alternative
> > >
> > > nntp://news.public-inbox.org/inbox.comp.version-control.git
> > >
> > > w
Junio C Hamano wrote:
> For those who prefer to read it over NNTP:
>
> nntp://news.gmane.org/gmane.comp.version-control.git
>
> is still available. An alternative
>
> nntp://news.public-inbox.org/inbox.comp.version-control.git
>
> will become usable once it catches up with old m
Junio C Hamano wrote:
> Eric Wong writes:
>
> > There'll be over 5000K injected messages from 2006 I missed from
> > the initial import :x
> >
> > I noticed this while adding gmane: mapping support to the
> > search engine:
> > https://publ
Philip Oakley wrote:
> The raw download works. My home ISP is currently blocking your email for
> some reason, though I do see it at my work - my iee.org alias is via my
> professional body which duplicates the email when it relays it.
Hmm, do other emails from other users get blocked?
I wonder i
This mainly affects the folks following the top-level
Atom feed at https://public-inbox.org/git/new.atom
or over NNTP.
There'll be over 5000K injected messages from 2006 I missed from
the initial import :x
I noticed this while adding gmane: mapping support to the
search engine:
https://publ
Philip Oakley wrote:
> Is there an accessible mapping from the old gmane message numbers to one of
> the remaining email list servers for the git list?
Yes, I just posted about this after posting an initial mapping
a few weeks ago:
https://public-inbox.org/git/20160811002819.GA8311@starla/T/#u
U
Josh Triplett wrote:
> On August 9, 2016 11:37:31 PM HST, Richard Ipsum
> wrote:
>
> >Maybe there's a better solution to this problem than git-candidate
> >then,
> >maybe we can just invent some wonderful new subcommand that fetches
> >a mailing list archive into a git repo, for those that want
Eric Wong wrote:
> Duy Nguyen wrote:
> > I read this and thought "temporarily" but apparently it's not [1]. A
> > lot of our links in the mail archive are gmane's :(
> >
> > [1] https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/
>
>
Jeff King wrote:
> On Tue, Aug 09, 2016 at 11:47:31PM +0000, Eric Wong wrote:
>
> > Avoid waking up the readers for unnecessary context switches for
> > each line of header data being written, as all the headers are
> > written in short succession.
> >
> >
Brian Henderson wrote:
Hi Brian,
A few minor portability/style nits below, but contrib/ probably
(still?) has laxer rules than the rest of git...
I think we still require Signed-off-by lines in contrib,
though...
> +++ b/contrib/diff-highlight/t/Makefile
> @@ -0,0 +1,19 @@
> +-include ../../..
Josh Triplett wrote:
> On Tue, Aug 09, 2016 at 06:28:00PM +0000, Eric Wong wrote:
> > Some of these problems I hope public-inbox (or something like
> > it) can fix and turn the tide towards email, again.
>
> This really seems like the dichotomy that drives people towards ce
xpect HTTP servers want to minimize syscall and
TCP/IP framing overhead by trying to send all of its response
headers in a single syscall or even combining the headers and
first chunk of the body with MSG_MORE or writev.
Verified by strace-ing response parsing on the CGI side.
Signed-off-by: Eric
Michael Haggerty wrote:
> On 08/04/2016 05:58 PM, Johannes Schindelin wrote:
> > [...]
> > Even requiring every contributor to register with GitHub would be too much
> > of a limitation, I would wager.
> > [...]
> * Discussion of pull requests can be done either
> * via the website (super easy
Johannes Schindelin wrote:
> On Fri, 5 Aug 2016, Junio C Hamano wrote:
> > Jeff Hostetler writes:
> > > }
> > > - else
> > > + else {
> > > d->index_status = DIFF_STATUS_ADDED;
> > > + /* Leave {mode,oid}_head zero for adds. */
> > > +
Jeff King wrote:
> Thanks. That's definitely an improvement. I still think the styling
> could go further, but I don't expect you to do it. It's something I may
> look into, but I should probably try to clear out my backlog of
> "to-review" patches before I go off spending time on it. :)
Heh, and
Junio C Hamano wrote:
> Somebody mentioned "configuring it is hard--why does the user have
> to know SMTP subtleties", and that may be a valid complaint against
> the primary part of send-email. The solution for that is not to
> discard it with bathwater, but make it just as easy as other MSAs,
>
> >>> larsxschnei...@gmail.com wrote:
> >>>> +static int apply_protocol_filter(const char *path, const char *src,
> >>>> size_t len,
Lars Schneider wrote:
> > On 05 Aug 2016, at 20:55, Eric Wong wrote:
> > Perhaps using xsize_t in git-c
Stefan Beller wrote:
> On Fri, Aug 5, 2016 at 1:20 AM, Johannes Schindelin
> wrote:
> > Yet another option would be to have a tool that integrates with the Git
> > repository of the Git mailing list represented by public-inbox.
>
> So my first reaction to that would be: you could push you patche
Lars Schneider wrote:
> > On 27 Jul 2016, at 11:41, Eric Wong wrote:
> > larsxschnei...@gmail.com wrote:
> >> +static int apply_protocol_filter(const char *path, const char *src,
> >> size_t len,
> >> + int fd, st
Johannes Schindelin wrote:
> On Thu, 4 Aug 2016, Stefan Beller wrote:
> > git send-email/format-patch recently learned to include a base commit
>
> You may have noticed that my mail-patch-series.sh-generated code
> submissions contain that base commit. But they still do not contain the
> SHA-1s o
Jeff King wrote:
> On Fri, Aug 05, 2016 at 05:28:05AM -0400, Jeff King wrote:
> > I do find it visually a little harder to navigate through threads,
> > because there's not much styling there, and the messages seem to run
> > into one another. I don't know if a border around the divs or something
Jeff King wrote:
> On Fri, Aug 05, 2016 at 05:28:05AM -0400, Jeff King wrote:
>
> > On Sun, Jul 10, 2016 at 12:48:13AM +0000, Eric Wong wrote:
> >
> > > Very much a work-in-progress, but NNTP and HTTP/HTTPS sorta work
> > > based on stuff that is on
Jeff King wrote:
> On Fri, Aug 05, 2016 at 08:26:30AM +0000, Eric Wong wrote:
>
> > > I'm not sure which mallocs you mean. I allocate one struct per node,
> > > which seems like a requirement for a linked list. If you mean holding an
> > > extra list str
Johannes Schindelin wrote:
Agreed on all above points :>
> On Thu, 4 Aug 2016, Eric Wong wrote:
> > Of course, centralized systems are unacceptable to me;
> > and with that I'll never claim any network service I run
> > will be reliable :)
>
> Hehehe. I g
Jeff King wrote:
> On Fri, Aug 05, 2016 at 08:02:31AM +0000, Eric Wong wrote:
>
> > > I just introduced another doubly-linked list in [1]. It adds some MRU
> > > features on top of the list, but it could in theory be built on top of a
> > > generic doubly-linked
(Fixed Nico's address)
Jeff King wrote:
> On Thu, Aug 04, 2016 at 11:34:35PM +0000, Eric Wong wrote:
> > Junio C Hamano wrote:
> > > [Graduated to "master"]
> >
> > > * ew/http-walker (2016-07-18) 4 commits
> > > (merged
Junio C Hamano wrote:
> [Graduated to "master"]
> * ew/http-walker (2016-07-18) 4 commits
> (merged to 'next' on 2016-07-18 at a430a97)
> + list: avoid incompatibility with *BSD sys/queue.h
> (merged to 'next' on 2016-07-13 at 8585c03)
> + http-walker: reduce O(n) ops with doubly-linked lis
Stefan Beller wrote:
> On Thu, Aug 4, 2016 at 8:58 AM, Johannes Schindelin
> wrote:
> > I guess I have no really good idea yet, either, how to retain the ease of
> > access of sending mails to the list, yet somehow keep a strong tie with
> > the original data stored in Git.
>
> Does it have to b
less(1)
Originally-from:
https://public-inbox.org/git/xmqq61piw4yf@gitster.dls.corp.google.com/
Helped-by: Junio C Hamano
Helped-by: Jeff King
Signed-off-by: Eric Wong
---
v4 changes: (diff @ <20160804113410.GA13908@starla>)
- reworded commit messages and took ownership as sug
Jeff King wrote:
> On Thu, Aug 04, 2016 at 03:43:01AM +0000, Eric Wong wrote:
>
> > +PAGER_ENV_CQ = "$(subst ",\",$(subst \,\\,$(PAGER_ENV)))"
> > +PAGER_ENV_CQ_SQ = $(subst ','\'',$(PAGER_ENV_CQ))
> > +BASIC_CFLAGS += -DPAGER_ENV
)
Originally-from:
https://public-inbox.org/git/xmqq61piw4yf@gitster.dls.corp.google.com/
Signed-off-by: Eric Wong
---
v3 changes (from v2, d3aed319c9abac006060bc81e865c93ff8363066)
- Squashed git-sh-setup quoting fix from Junio
- set MORE=FRX on FreeBSD to match LESS
- simplify
Junio C Hamano wrote:
> All bugs are from my original, I think. Here is a proposed squash.
Thanks, I'll take the git-sh-setup changes.
I actually just rewrote setup_pager_env using split_cmdline and
eliminated all the scary (to me) pointer arithmetic and avoided
strbuf, too.
Unfortunately, my
Jeff King wrote:
> I don't recall offhand whether git-svn does line-wrapping or any other
> commit-message munging.
Definitely no line-wrapping. Munging is minimal:
it respects i18n.commitencoding, adds a trailing newline,
and "git-svn-id:" line.
--
To unsubscribe from this list: send the line "
Junio C Hamano wrote:
> Eric Wong writes:
> > Allowing PAGER_ENV to be set at build-time allows us to move
> > pager-specific knowledge out of our build. Currently, this
> > allows us to set a better default for FreeBSD where more(1)
> > is the same binary
Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > It would be a serious bug if hashmap_entry_init() played games with
> > references, given its signature (that this function does not have any
> > access to the hashmap structure, only to the entry itself):
> >
> > void hashmap_entry_i
Changes from v1:
* dropped stringify macro in favor for quoting in Makefile
(diff below)
I'm not sure I like this change, and might be inclined to
go in the opposite direction of using the stringify macro
more widely to simplify the Makefile; but that is a separate
topic.
* dropped 2/2,
to
override the build-time environment in the next commit.
Originally-from:
https://public-inbox.org/git/xmqq61piw4yf@gitster.dls.corp.google.com/
Signed-off-by: Eric Wong
---
Makefile | 20 +++-
config.mak.uname | 1 +
git-sh-setup.sh | 8 +---
pager.c
Josh Triplett wrote:
> On Mon, Aug 01, 2016 at 07:55:54AM +0000, Eric Wong wrote:
> > Christian Couder wrote:
> > > On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum
> > > wrote:
> > > > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
>
Christian Couder wrote:
> On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum
> wrote:
> > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> > [snip]
> >>
> >> I'd welcome any feedback, whether on the interface and workflow, the
> >> internals and collaboration, ideas on presenting dif
"brian m. carlson" wrote:
> On Mon, Aug 01, 2016 at 01:05:56AM +0000, Eric Wong wrote:
> > + while (*cp && *cp == ' ')
> > + cp++;
>
> So it looks like this function splits on spaces but doesn't provide any
> e
:51:42 +)
Eric Wong (1):
pager: implement core.pagerEnv in config
Junio C Hamano (1):
pager: move pager-specific setup into the build
Documentation/config.txt | 7 +++
Makefile | 19
This allows overriding the build-time PAGER_ENV variable
at run-time.
Inspired by part 1 of an idea from Kyle J. McKay at:
https://public-inbox.org/git/62db6def-8b39-4481-ba06-245bf4523...@gmail.com/
Signed-off-by: Eric Wong
---
Documentation/config.txt | 7 +++
pager.c
to
override the build-time environment in the next commit.
Originally-from:
https://public-inbox.org/git/xmqq61piw4yf@gitster.dls.corp.google.com/
Signed-off-by: Eric Wong
---
Makefile | 19 +--
config.mak.uname | 1 +
git-sh-setup.sh | 8 +---
pager.c
Eric Wong wrote:
> Nguyễn Thái Ngọc Duy wrote:
> > +test_expect_success FREEBSD 'Work around lazy mtime update' '
> > + ls -ld . >/dev/null
> > +'
>
> stat . >/dev/null
If there's some older FreeBSD w/o stat(1); "test -x .
look further in FreeBSD source code, this
> flag is now called IN_LAZYMOD. I can see it's effective in ext2 and
> ufs. zfs is questionable.
>
> [1] 660e6408e6df99a20dacb070c5e7f9739efdf96d
> [2] git://github.com/freebsd/freebsd.git
> [3] https://bugs.freebsd.org/bugzill
Junio C Hamano wrote:
> Subject: [PATCH] t9100: portability fix
>
> Do not say "export VAR=VAL"; "VAR=VAL && export VAR" is always more
> portable.
Oops, sorry I should've caught that :x
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.
Duy Nguyen wrote:
> I read this and thought "temporarily" but apparently it's not [1]. A
> lot of our links in the mail archive are gmane's :(
>
> [1] https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/
I may not have time to integrate this extensibly into the public-inbox
search engine to
Eric Wong wrote:
> Code is AGPL-3.0+: git clone https://public-inbox.org/
>
>
> Additional mirrors or forks (perhaps different UIs) are very welcome,
Btw, it's possible to do quote highlighting with user-side CSS:
https://public-inbox.org/meta/20160709-user-side-css-example@1
Duy Nguyen wrote:
> On Thu, Jul 28, 2016 at 11:11 AM, Lars Schneider
> wrote:
> > Hi,
> >
> > gmane is down
At least the following should work in case public-inbox fails:
https://mid.mail-archive.com/%s
https://marc.info/?i=%s
public-inbox falls back to them on missing MIDs,
al
larsxschnei...@gmail.com wrote:
> +static off_t multi_packet_read(struct strbuf *sb, const int fd, const size_t
> size)
I'm no expert in C, but this might be const-correctness taken
too far. I think basing this on the read(2) prototype is less
surprising:
static ssize_t multi_packet_read(int
Lars Schneider wrote:
> On 26 Jul 2016, at 00:50, Junio C Hamano wrote:
> >
> > * ew/git-svn-http-tests (2016-07-25) 2 commits
> > - git svn: migrate tests to use lib-httpd
> > - t/t91*: do not say how to avoid the tests
> >
> > Reuse the lib-httpd test infrastructure when testing the subversio
Junio C Hamano wrote:
> Eric Wong writes:
> > Junio C Hamano wrote:
> >> Duy Nguyen writes:
> >> > On Mon, Jul 25, 2016 at 6:56 PM, Junio C Hamano
> >> > wrote:
> >> >> On Mon, Jul 25, 2016 at 9:21 AM, Nguyễn Thái Ngọc Duy
> >
Junio C Hamano wrote:
> Eric Wong writes:
>
> >> Also, doesn't it break "git rebase" (non-interactive), or anything
> >> that internally runs format-patch to individual files and then runs
> >> am on each of them, anything that knows that each out
Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > On Mon, Jul 25, 2016 at 6:56 PM, Junio C Hamano wrote:
> >> On Mon, Jul 25, 2016 at 9:21 AM, Nguyễn Thái Ngọc Duy
> >> wrote:
> >>> It looks the the symlink /usr/bin/perl (to /usr/local/bin/perl) has
> >>> been removed at least on FreeBSD 10.3.
Junio C Hamano wrote:
> Junio C Hamano writes:
> > Eric Wong writes:
> >
> >> Users have mistakenly copied "From " lines into commit messages
> >> in the past, and will certainly make the same mistakes in the
> >> future. Since not everyo
Lars Schneider wrote:
> On 23 Jul 2016, at 10:14, Eric Wong wrote:
> > larsxschnei...@gmail.com wrote:
> >> +static struct cmd2process *start_protocol_filter(const char *cmd)
> >> +{
> >> + int ret = 1;
> >> + struct cmd2process *entry = NULL;
Jakub Narębski wrote:
> W dniu 2016-07-11 o 22:51, Eric Wong pisze:
>
> > TL;DR: dumb HTTP clone from a certain badly-packed repo goes from
> > ~2 hours to ~30 min memory usage drops from 2G to 360M
> >
> >
> > I hadn't packed the public repo at https:/
Junio C Hamano wrote:
> As a tool to produce mbox file, quoting like this in format-patch
> output may make sense, I would think, but shouldn't send-email undo
> this when sending individual patches?
Yes, that sounds like a good idea. Thanks.
Will followup in a day or two.
--
To unsubscribe from
We will be reusing is_from_line for quoting format-patch output
in the next commit.
Suggested-by: Johannes Schindelin
Signed-off-by: Eric Wong
---
builtin/mailsplit.c | 32 +---
mailinfo.c | 31 +++
mailinfo.h | 1 +
3
ref: https://public-inbox.org/git/20160606230248.ga15...@dcvr.yhbt.net/T/#u
Signed-off-by: Eric Wong
---
pretty.c| 16 +---
t/t4014-format-patch.sh | 14 ++
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/pretty.c b/pretty.c
index 9fa42c2.
ges up to 4f769f1799db11f135948bf517f2d8d864fa778f:
format-patch: escape "From " lines recognized by mailsplit (2016-07-23
21:38:40 +)
----
Eric Wong (2):
mailinfo: extract is_from_line from mailsplit
format-patch: escape "
larsxschnei...@gmail.com wrote:
> Please note that the protocol filters do not support stream processing
> with this implemenatation because the filter needs to know the length of
> the result in advance. A protocol version 2 could address this in a
> future patch.
Would it be prudent to reuse pkt
Jakub Narębski wrote:
> W dniu 2016-07-22 o 17:49, larsxschnei...@gmail.com pisze:
> > +use strict;
> > +use warnings;
> > +use autodie;
>
> autodie?
"set -e" for Perl (man autodie)
It's been a part of Perl for ages, but I've never used it
myself, either; I suppose it's fine for tests...
> > +
: migrate tests to use lib-httpd (2016-07-23 03:31:21 +)
Eric Wong (1):
git svn: migrate tests to use lib-httpd
Michael J Gruber (1):
t/t91*: do not say how to avoid the tests
t/lib-git-svn.sh
2.2 and 2.4 on Debian 7.x (wheezy) and
8.x (jessie), respectively.
Cc: Clemens Buchacher
Cc: Michael J Gruber
Signed-off-by: Eric Wong
---
t/lib-git-svn.sh | 91 +--
t/lib-httpd.sh| 8 ++-
t/lib-httpd
301 - 400 of 840 matches
Mail list logo
