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
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
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
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:
> 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
)
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
Jeff King wrote:
> On Thu, Aug 04, 2016 at 03:43:01AM +, Eric Wong wrote:
>
> > +PAGER_ENV_CQ = "$(subst ",\",$(subst \,\\,$(PAGER_ENV)))"
> > +PAGER_ENV_CQ_SQ = $(subst ','\'',$(PAGER_ENV_CQ))
> > +BASIC_CFLAGS += -DPAGER_ENV
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
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
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
(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
Jeff King wrote:
> On Fri, Aug 05, 2016 at 08:02:31AM +, 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
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:26:30AM +, 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
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 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
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
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
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
> >>> 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
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,
>
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
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. */
> > > +
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
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
Josh Triplett wrote:
> On Tue, Aug 09, 2016 at 06:28:00PM +, 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
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 ../../..
Jeff King wrote:
> On Tue, Aug 09, 2016 at 11:47:31PM +, 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.
> >
> >
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 Thu, Dec 15, 2016 at 02:57:18PM +0100, Chiel ten Brinke wrote:
>
> > Btw, the link in the README
> > http://news.gmane.org/gmane.comp.version-control.git/ is dead.
>
> Yes, the status of gmane was up in the air for a while, but I think we
> can give it up as dead now (at le
Stephen & Linda Smith wrote:
> I had been told to reference (i.e. footnote) a gmane URL. With that service
> no longer being being online, what is the preferred method footnoting?
What the others said about Message-IDs and public-inbox :)
If you only have old URLs pointing to gmane and no NNTP
6cc6a4870dd84
("Disallow '\' in ref names") from May 2009.
Reported-by: Michael Fladischer
Message-ID:
Signed-off-by: Eric Wong
---
The following changes since commit a274e0a036ea886a31f8b216564ab1b4a3142f6c:
Sync with maint-2.10 (2016-12-05 11:25:47 -0800)
are a
Eduardo Habkost wrote:
> git-am has options to enable --message-id and --3way by default,
> but no option to enable --signoff by default. Add a "am.signoff"
> config option.
I'm not sure this is a good idea. IANAL, but a sign-off
has some sort of legal meaning for this project (DCO)
and that wou
larsxschnei...@gmail.com wrote:
> +++ b/t/t0021/rot13-filter.pl
> +$DELAY{'test-delay1.r'} = 1;
> +$DELAY{'test-delay3.r'} = 3;
>
> open my $debug, ">>", "rot13-filter.log" or die "cannot open log file: $!";
>
> @@ -166,6 +176,15 @@ while (1) {
> packet_txt_write("status=abort");
Pat Pannuto wrote:
> You may still want the 1/2 patch in this series, just to make things
> internally consistent with "-w" vs "use warnings;" inside git's perl
> scripts.
No, that is a step back. "-w" affects the entire process, so it
spots more potential problems. The "warnings" pragma is sco
Johannes Schindelin wrote:
> I guess I do not understand, still, what the difference is between using
> -w and adding `use warnings` *very early* in the script... Could you give
> an example where it makes a difference?
"use warnings" won't leak across files/modules. In the following
example, on
Junio C Hamano wrote:
> Eric Wong writes:
> > Pat Pannuto wrote:
> >> You may still want the 1/2 patch in this series, just to make things
> >> internally consistent with "-w" vs "use warnings;" inside git's perl
> >> scripts.
>
Junio C Hamano wrote:
> Eric Wong writes:
> > Junio C Hamano wrote:
> >> Eric Wong writes:
> >> > Pat Pannuto wrote:
> >> >> You may still want the 1/2 patch in this series, just to make things
> >> >> internally consistent wi
Jeff King wrote:
> Just as a devil's advocate, why do we care about warnings in third-party
> modules? Or more specifically, why do _users_ who are running Git care
> about them? We cannot fix them in Git. A user may report the error to
> the module author, but the module author may not be respons
Junio C Hamano wrote:
> Santiago Torres writes:
>
> <>???
>
> Eric, I've noticed that this message
>
>
> http://public-inbox.org/git/20170118182831.pkhqu2np3bh2puei@LykOS.localdomain/
>
> and all messages from Santiago appear empty when they come via
> public-inbox.org; the reason I suspec
Eric Wong wrote:
> Junio C Hamano wrote:
> >
> >
> > http://public-inbox.org/git/20170118182831.pkhqu2np3bh2puei@LykOS.localdomain/
>
> Eeep! This looks like a regression I introduced when working
> around Richard Hansen's S/MIME mails the other wee
Linus Torvalds wrote:
> On Tue, Jan 24, 2017 at 4:21 PM, Stefan Beller wrote:
> >
> > +Do not PGP sign your patch. Most likely, your maintainer or other
> > +people on the list would not have your PGP key and would not bother
> > +obtaining it anyway.
>
> I think even that could be further simpl
Johannes Schindelin wrote:
> Back in the olden days, when all objects were loose and rubber boots were
> made out of wood, it made sense to try to share (immutable) objects
> between repositories.
>
> Ever since the arrival of pack files, it is but an anachronism.
>
> Let's move the script to th
Jeff King wrote:
> On Thu, Jan 26, 2017 at 12:13:44AM +, brian m. carlson wrote:
> > +
> > + def process(parent, target, attrs)
> > +if parent.document.basebackend? 'html'
> > + prefix = parent.document.attr('git-relative-html-prefix')
> > + %(#{target}(#{attrs[1
> Eric Wong writes:
> > You can use '\' to continue long lines with any Ruby version:
> >
> > "" \
> > "#{target}" \
> > "#{attrs[1]}" \
> > ""
Junio C Hamano wrote:
> + &qu
I noticed both of these are are missing from my archives
(which rejects messages unless they come from vger):
https://public-inbox.org/git/20170125234101.n2pzrp77df4zy...@genre.crustytoothpaste.net/#r
I only have them because I was Cc:-ed.
gmane doesn't seem to have them, either:
nntp://news
Jeff King wrote:
> With the caveat that I know very little about web hosting, $230/mo
> sounds like an awful lot for what is essentially a static web site.
Yes, that's a lot.
Fwiw, that covers a year of low-end VPS hosting for the main
public-inbox.org/git machine + mail host
(~1GB git objects +
--add-author-from and --use-log-author are for "git svn dcommit",
not "git svn (init|clone)"
Signed-off-by: Eric Wong
---
contrib/completion/git-completion.bash | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Though, I now wonder if allowing those switches
Johannes Schindelin wrote:
> For details, see:
> http://public-inbox.org/git/11340844841342-git-send-email-mailing-lists@rawuncut.elitemail.org/
> (this is also an example where public-inbox' thread detection went utterly
> wrong, including way too many mails in the "thread")
Thanks, it shoul
Jeff King wrote:
> On Mon, Feb 06, 2017 at 08:48:20PM +, Eric Wong wrote:
>
> > I haven't hit insurmountable performance problems, even on
> > low-end hardware; especially since I started storing blob ids in
> > Xapian itself, avoiding the expensive tree loo
Paul Wise wrote:
> Hi all,
>
> I had an idea that might be interesting to git folks:
>
> light-weight pull requests:
>
> Anonymous and ssh/http-identified users should be able to push just
> using git, within the refs/pull/ namespace, to any non-existent branch
> name or to a branch they create
Jeff King wrote:
> I agree we should continue to serve HTTPS. The usual solution for our
> use case is to stick a CDN like Cloudflare in front of GitHub Pages (and
> I think we'd want to do that anyway for performance).
>
> I haven't done it, but there are various guides. Here's the one from
> Cl
David Turner wrote:
> + echo fleem> .git/gc.log &&
A minor nit:
echo fleem >.git/gc.log &&
Otherwise, it's good to know there's attention paid to this
issue. I've been ignoring cron mails from my mirrors for too
long :x Thanks.
When parsing an mbox, it is possible to get existing In-Reply-To
and References headers blindly appended into the headers of
message we generate. This is probably the wrong thing to do
and we should prioritize what was given in the command-line,
cover letter, and previously-sent messages.
One ex
Junio C Hamano wrote:
> Eric Wong writes:
> > When parsing an mbox, it is possible to get existing In-Reply-To
> > and References headers blindly appended into the headers of
> > message we generate. This is probably the wrong thing to do
> > and we should prior
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 GMane.
>
> I wasn't aware of
Olaf Hering wrote:
> On Tue, Feb 14, Olaf Hering wrote:
>
> > How would I debug it?
>
> One line is supposed to be longer than 998 chars, but something along
> the way truncated it and corrupted the patch.
998 sounds like the SMTP limit.
Perhaps git format-patch should emit binary diffs in tha
Junio: ping?
https://public-inbox.org/git/20161223014202.GA8327@starla/raw
Thanks.
Ian Kelling wrote:
> I've got patches in various projects, and I don't have time to keep up
> with the mailing list, but I'd like to help out with maintenance of that
> code, or the functions/files it touches. People don't cc me. I figure I
> could filter the list, test patches submitted, commits
Junio C Hamano wrote:
> Jeremy Huddleston Sequoia writes:
>
> > CC: Josh Triplett
> > CC: Junio C Hamano
>
> Please don't do this in your log message. These belong to your
> e-mail headers, not here.
Fwiw, I prefer having these trailers. It makes it easier to
maintain the Cc: list through
Stefan Beller wrote:
> On Wed, Oct 12, 2016 at 7:45 AM, Mathieu Arnold wrote:
>
> > I discovered git worktree earlier this week, and I found it a great
> > asset to be able to have more than one branch of my worktree accessible
> > at the same time...
> >
> > Anyway, back to my problem, the way
Duy Nguyen wrote:
> On Thu, Oct 13, 2016 at 8:52 AM, Eric Wong wrote:
> > +sub svn_dir {
> > + my $git_dir = scalar @_ ? $_[0] : $ENV{GIT_DIR};
> > + my $common = $ENV{GIT_COMMON_DIR} || "$git_dir/commondir";
> > + $git_dir .= &
n the git repository at:
git://bogomips.org/git-svn.git svn-wt
for you to fetch changes up to 112423eb905cf28c9445781a7647ba590d597ab3:
git-svn: "git worktree" awareness (2016-10-14 01:36:12 +)
----
Eric Wong (2)
thieu Arnold
Signed-off-by: Eric Wong
---
git-svn.perl | 9 +
perl/Git/SVN.pm | 24 +++-
perl/Git/SVN/Migration.pm | 37 ++---
3 files changed, 42 insertions(+), 28 deletions(-)
diff --git a/git-svn.perl b/git-sv
eb and our other Perl
scripts, too.
Signed-off-by: Eric Wong
---
git-svn.perl| 4 ++--
perl/Git.pm | 16 +++-
perl/Git/SVN/Editor.pm | 12 +---
perl/Git/SVN/Fetcher.pm | 15 +--
4 files changed, 27 insertions(+), 20 deletions(-)
diff -
K Richard Pixley wrote:
> error: git-svn died of signal 11
>
> This seems awfully early and blatant for a core dump. What can I do to
> get this running?
Can you show us a backtrace? Thanks.
> Initially discovered on git-2.7.4, (ubuntu-16.04), but also reproduced
> on freshly built top of tre
K Richard Pixley wrote:
> On 10/19/16 13:41 , Eric Wong wrote:
> >K Richard Pixley wrote:
> >>error: git-svn died of signal 11
> >>
> >>This seems awfully early and blatant for a core dump. What can I do to
> >>get this running?
> >Can you sh
larsxschnei...@gmail.com wrote:
> +++ b/read-cache.c
> @@ -156,7 +156,11 @@ void fill_stat_cache_info(struct cache_entry *ce, struct
> stat *st)
> static int ce_compare_data(const struct cache_entry *ce, struct stat *st)
> {
> int match = -1;
> - int fd = open(ce->name, O_RDONLY);
> +
Johannes Schindelin wrote:
> +++ b/perl/Git/SVN.pm
> @@ -1658,6 +1658,11 @@ sub tie_for_persistent_memoization {
> if ($memo_backend > 0) {
> tie %$hash => 'Git::SVN::Memoize::YAML', "$path.yaml";
> } else {
> + # first verify that any existing file can actual
Junio C Hamano wrote:
> @@ -156,7 +156,14 @@ void fill_stat_cache_info(struct cache_entry *ce, struct
> stat *st)
> static int ce_compare_data(const struct cache_entry *ce, struct stat *st)
> {
> int match = -1;
> - int fd = open(ce->name, O_RDONLY);
> + static int cloexec = O_CLO
Tao Peng wrote:
> Hi there,
>
> I met a bug of the "git svn show-externals” command. If a subdirectory item
> has a svn:externals property, and the format of the property is “URL first,
> then the local path”, running "git svn show-externals” command at the root
> level will result in an unus
Eric Wong wrote:
> +Cc Jakub since gitweb could probably take advantage of get_record
> from the first patch, too. I'm not completely sure about the API
> for this, though.
Jakub: ping?
+Cc: Junio, too. I'm hoping to have this in 2.11.
> The followin
Johannes Schindelin wrote:
> I know you are a fan of testing things thoroughly in the test suite, but I
> have to say that it is getting out of hand, in particular due to our
> over-use of shell script idioms (which really only run fast on Linux, not
> a good idea for a portable software).
How mu
Junio C Hamano wrote:
> Just peeking from the sideline, but the your squash looks like an
> improvement to me.
Thanks.
> Hopefully the final version after your interaction with Dscho can
> come to me via another "pull this now"?
Not sure if I'll be online the next few days,
but I've preeptively
Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Linus Torvalds writes:
> >
> >> On Thu, Oct 27, 2016 at 4:36 PM, Junio C Hamano wrote:
> >>>
> >>> Would the best endgame shape for this function be to open with
> >>> O_NOATIME (and retry without), and then add CLOEXEC with fcntl(2)
> >>> b
Lars Schneider wrote:
> Hi,
>
> Git always performs a clean/smudge filter on files in sequential order.
> Sometimes a filter operation can take a noticeable amount of time.
> This blocks the entire Git process.
I have the same problem in many places which aren't git :>
> I would like to give a
Lars Schneider wrote:
> > On 15 Nov 2016, at 02:03, Eric Wong wrote:
>
> > Anyways, I'll plan on doing something similar (in Perl) with the
> > synchronous parts of public-inbox which relies on "cat-file --batch"
> > at some point... (my rotational
Juergen Kosel wrote:
> Therefore I believe, that it would be the best solution to store the
> settings of --add-author-from, --use-log-author and maybe
> --authors-prog in the .git/config file.
Actually, "svn.authorsProg" is already documented as a config
option for --authors-prog.
It's been a w
Juergen Kosel wrote:
> Am 05.12.2016 um 23:54 schrieb Eric Wong:
> > So, can you confirm that svn.addAuthorFrom and svn.useLogAuthor
> > config keys work and can be documented?
>
> yes, I can confirm, that adding this configuration keys works with git
> 2.1.4 work.
&
Blindly checking a path component for falsiness is unwise, as
"0" is false to Perl, but a valid pathname component for SVN
(or any filesystem).
Found via random code reading.
Signed-off-by: Eric Wong
---
Junio: this bugfix should go to "maint".
Will push along with a
: document useLogAuthor and addAuthorFrom config keys (2016-12-12
11:09:29 +)
Eric Wong (2):
git-svn: allow "0" in SVN path components
git-svn: document useLogAuthor and addAuthorFrom config keys
Documen
Junio C Hamano wrote:
> Thanks; basing these two on top of "Start post 2.11 cycle" that is
> on 'master' would mean that this won't merge to 'maint' for 2.11.x,
> though. I hope you wouldn't mind if I rebased them on top of
> 'maint' before merging?
Nope, wouldn't mind at all.
I was wondering i
First, bad news:
There's been some hardware problems the past week or so and a
few minutes of scattered downtime and high latency as a result.
Hopefully no lost messages, as SMTP should retry.
Getting things migrated to different hardware in a few
minutes, so maybe the new hardware will have fewe
Lars Schneider wrote:
> OK. I am not that experienced with shell scripting and therefore it
> is hard for me to distinguish between the different shell features.
> Do you know/can you recommend the most basic shell to test/work
> with? A quick Google search told me that "dash" from Ubuntu seems
>
Christian Couder wrote:
> Signed-off-by: Christian Couder
Thanks Christian,
Signed-off-by: Eric Wong
...And pushed to my svn/bad-ref branch for Junio.
(I don't think I'll have other git-svn-related changes
immediately pending)
The following changes
Jeff King wrote:
> On Wed, May 11, 2016 at 04:35:46PM -0700, Junio C Hamano wrote:
> > +++ b/builtin/am.c
> > @@ -761,9 +761,11 @@ static int split_mail_conv(mail_conv_fn fn, struct
> > am_state *state,
> > mail = mkpath("%s/%0*d", state->dir, state->prec, i + 1);
> >
> >
Hin-Tak Leung wrote:
> I tried bin-wrappers/ from current git HEAD.
>
> $ git describe
> v2.8.2-396-g5fe494c
Which SVN version? `git svn --version`
> bin-wrappers/git svn clone https://ironpython.svn.codeplex.com/svn
> ironpython-old-codeplex
>
> always fails at this rev:
>
> M
Lars Schneider wrote:
> Hi,
>
> t9801 and t9803 seem to be broken on next. A quick bisect indicates that
> d9545c7
> "fast-import: implement unpack limit" might be the reason. (@gmane/292562).
>
> Did anyone look into that already?
Just took a look (no p4, so couldn't run tests) and I guess i
Jeff King wrote:
> + git diff --exit-code refs/remotes/origin/$i
> refs/remotes/origin/$j ||
> + return 1
80 columns; but I guess Junio picked it up, already.
Otherwise the rest of the series looks good. Thanks.
--
To unsubscribe from this list: s
Hin-Tak Leung wrote:
> I suppose I could keep fetching to see if I can get past that rev one day :-(.
Maybe try and see if you can create a mirror using svnsync
and go from there? Or see if you can get a closer machine to
test this on.
It could also be a bug in your particular version of svn, t
Lars Schneider wrote:
> I am no expert in "fast-import". Does anyone have a few hints how to
> proceed?
I don't know fast-import or the C internals of git well at all,
either. But capturing the exact input to fast-import (using
tee) would be useful for non-p4 users to debug the problem
and would
Eric Sunshine wrote:
> On Mon, May 16, 2016 at 11:22 PM, Stefan Beller wrote:
> > When using automated tools to find memory leaks, it is hard to distinguish
> > between actual leaks and intentional non-cleanups at the end of the program,
> > such that the actual leaks hide in the noise.
>
> Cons
Stefan Beller wrote:
> Eric Wong writes:
> > I haven't checked for git, but I suspect we get speedups by not
> > calling free(). I've never needed to profile git, but free() at
> > exit has been a measurable bottleneck in other projects I've
> > worked
larsxschnei...@gmail.com wrote:
> Enable t9113 and 9126 by defining the SVNSERVER_PORT. Since both tests
> open the same port during execution, they cannot run in parallel. Add
> a ".seq.sh" suffix to the test files and teach "prove" to run them
> sequentially.
Interesting, I guess I forgot the pr
Lars Schneider wrote:
> > On 19 May 2016, at 19:11, Junio C Hamano wrote:
> > Eric Wong writes:
> >
> >> Anyways, how about making the tests run on separate ports and
> >> not worry about serializing them at all?
> >
> > Yeah, that does sound
Tom Russello wrote:
> This new option takes an email message file, parses it, fills the "To",
> "Subject" and "Cc" fields appropriately and quote the message.
> This option involves the `--compose` mode to edit the cover letter quoting the
> given email.
Cool! There should probably be some help
Junio C Hamano wrote:
> Lars Schneider writes:
> >> On 19 May 2016, at 19:11, Junio C Hamano wrote:
> >> Eric Wong writes:
> >>
> >>> Anyways, how about making the tests run on separate ports and
> >>> not worry about serializing the
Samuel GROOT wrote:
> On 05/23/2016 09:55 PM, Eric Wong wrote:
> >Cool! There should probably be some help text to encourage
> >trimming down the quoted text to only relevant portions.
>
> What kind of help text would you want to see?
>
> Maybe something like this:
tions.
Signed-off-by: Eric Wong
---
daemon.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/daemon.c b/daemon.c
index 8d45c33..46dddac 100644
--- a/daemon.c
+++ b/daemon.c
@@ -669,6 +669,15 @@ static void hostinfo_clear(struct hostinfo *hi)
strbuf_release(&hi-
101 - 200 of 955 matches
Mail list logo
