Jeff King wrote:
> On Tue, May 17, 2016 at 10:07:16AM +0200, Lars Schneider wrote:
>
> > I think that is pretty much the problem. Here is what is happening:
> >
> > 1. git-p4 imports all changelists for the "main" branch
> >
> > 2. git-p4 starts to import a second branch and creates a fast-im
they are also invalidated.
Signed-off-by: Eric Wong
---
I started writing a standalone test case; but testing with
original failing cases would be greatly appreciated.
Still learning my way around the fast-import code...
Thanks.
fast-import.c | 31 +++-
t
Junio C Hamano wrote:
> This makes sense as a follow-up to e47a8583 (enable SO_KEEPALIVE for
> connected TCP sockets, 2011-12-06), I think.
Yes, a15d069a19867 for http, too; hat trick :>
Anyways, it might've helped Savannah when they had networking
problems:
http://mid.gmane.org/2016052421410
Jeff King wrote:
> On Wed, May 25, 2016 at 10:54:02PM +, Eric Wong wrote:
> > + for (h = 0; h < ARRAY_SIZE(object_table); h++) {
> > + struct object_entry *e;
> > +
> > + for (e = object_table[h]; e; e = e->next)
> > +
Samuel GROOT wrote:
> While working on the new option `quote-email`, we needed to parse an
> email file. Since the work is already done, but the parsing and data
> processing are in the same loop, we wanted to refactor the parser, to
> make the code more maintainable.
Thank you for doing this wor
Jeff King wrote:
> On Thu, May 26, 2016 at 08:02:36AM +, Eric Wong wrote:
>
> > > That's probably OK in practice, as I think the actual pack-write already
> > > does a linear walk of the object table to generate the pack index. So
> > > presumably nobody
Matthieu Moy wrote:
> Samuel GROOT writes:
>
> > Parsing and processing in send-email is done in the same loop.
> >
> > To make the code more maintainable, we create two subroutines:
> > - `parse_email` to separate header and body
> > - `parse_header` to retrieve data from header
>
> These rout
.0?), maybe mboxrd can become the
default mail format. IMHO, it should've been since 2005.
ref:
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/mail-mbox-formats.html
Eric Wong (3):
pretty: support "mboxrd" output format
mailsplit: support unescaping mboxrd
Combined with "git format-patch --pretty=mboxrd", this should
allow us to round-trip commit messages with embedded mbox
"From " lines without corruption.
Signed-off-by: Eric Wong
---
Documentation/git-am.txt | 3 ++-
builtin/am.c | 14 +++---
t/t4150-a
This will allow us to parse the output of --pretty=mboxrd
and the output of other mboxrd generators.
Signed-off-by: Eric Wong
---
Documentation/git-mailsplit.txt | 7 ++-
builtin/mailsplit.c | 23 +++
t/t5100-mailinfo.sh | 13 +
t
t's inherits the problems
of "mboxcl" while being completely incompatible with existing
tooling based around mailsplit.
ref:
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/mail-mbox-formats.html
Signed-off-by: Eric Wong
---
builtin/log.c | 2 +-
commit.
Eric Sunshine wrote:
> On Mon, May 30, 2016 at 7:21 PM, Eric Wong wrote:
> > diff --git a/pretty.c b/pretty.c
> > @@ -1697,12 +1699,34 @@ static void pp_handle_indent(struct
> > pretty_print_context *pp,
> > +static regex_t *mboxrd_prepare(void)
> > +
Matteo Bertini wrote:
> Sorry to all, but I missed a Checksum mismatch error, I'll have a
> look and submit an update.
Sure, when you reroll can you also ensure lines are wrapped at
80 cols or less? (at least for the git-svn code, but probably
for the rest of it, too).
As for the option name, th
Eric Sunshine wrote:
> On Tue, May 31, 2016 at 3:45 AM, Eric Wong wrote:
> > Eric Sunshine wrote:
Ah thanks, I can see your point-of-view, now.
I always had the '^' in my mind since I've written the same
thing in Perl and Ruby.
> >> I wonder if hand-coding,
Eric Wong wrote:
> Eric Sunshine wrote:
> > On Tue, May 31, 2016 at 3:45 AM, Eric Wong wrote:
> > > Eric Sunshine wrote:
> > >> I wonder if hand-coding, rather than using a regex, could be an
> > >> improvement:
> > >>
> &
Samuel GROOT wrote:
> On 05/29/2016 01:33 AM, Eric Wong wrote:
> >Matthieu Moy wrote:
> >>Samuel GROOT writes:
> >>
> >>>Parsing and processing in send-email is done in the same loop.
> >>>
> >>>To make the code more maintainab
Matteo Bertini wrote:
> Il 2016-05-31 20:12 Eric Wong ha scritto:
> >Matteo Bertini wrote:
> >>Sorry to all, but I missed a Checksum mismatch error, I'll have a
> >>look and submit an update.
>
> I've had a look, the problem is a missing smudge filter.
t's inherits the problems
of "mboxcl" while being completely incompatible with existing
tooling based around mailsplit.
ref:
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/mail-mbox-formats.html
Signed-off-by: Eric Wong
---
builtin/log.c | 2 +-
commit.
t --patch-format=mboxrd (2016-06-05 04:16:57 +)
----
Eric Wong (3):
pretty: support "mboxrd" output format
mailsplit: support unescaping mboxrd messages
am: support --patch-format=mboxrd
Documentation/git-am.t
This will allow us to parse the output of --pretty=mboxrd
and the output of other mboxrd generators.
Signed-off-by: Eric Wong
---
Documentation/git-mailsplit.txt | 7 ++-
builtin/mailsplit.c | 18 ++
t/t5100-mailinfo.sh | 31
Combined with "git format-patch --pretty=mboxrd", this should
allow us to round-trip commit messages with embedded mbox
"From " lines without corruption.
Signed-off-by: Eric Wong
---
Documentation/git-am.txt | 3 ++-
builtin/am.c | 14 +++---
t/t4150-a
Junio C Hamano wrote:
> This just makes me wonder if there is a practical reason why people
> would not want this always enabled. I just looked at output from
>
> $ git log --grep='>>*From '
Missing '^' ?
Auto-unescaping in mailsplit might throw off people on older
versions of git if reser
Peter Münster wrote:
> It would be nice, if timestamps could be preserved when rewriting the
> git-log.
Unfortunately, last I checked (a long time ago!), explicitly
setting revprops might require SVN administrators to enable the
feature for the repo.
It's been a while and I'm not up-to-date with
+Cc Alfred, David
Joseph Pecoraro wrote:
> `git help svn` does not mention `propset` but it does mention `proplist` and
> `propget`. This seems like an oversight.
>
>
> $ git help svn
> ...
> proplist
> Lists the properties stored in the Subversion repository about
Tom Russello wrote:
> Messages displayed by `send-email` should be shortened to avoid displaying
> unnecesseray informations.
unnecessary information.
In some of your other patches, the 'grep' can probably
be better replaced by 'fgrep' for fixed strings.
Otherwise, the '.' in the 'example.com' w
Samuel GROOT wrote:
> +++ b/perl/Git.pm
> +sub parse_email {
> + my %mail = ();
> + my $fh = shift;
> + my $last_header;
> +
> + # Unfold and parse multiline header fields
When you libify, I suggest you localize $/ since $/
may be set to something other than "\n" by a caller
and
Samuel GROOT wrote:
> Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1].
> Should we handle \n\r at end of line as well?
"\n\r" can never happen with local $/ = "\n"
> [1] *
> http://cpansearch.perl.org/src/RJBS/Email-Simple-2.210/lib/Email/Simple.pm
--
To unsubscribe from this li
Peter Münster wrote:
> On Tue, Jun 07 2016, Eric Wong wrote:
> > Peter Münster wrote:
> >> It would be nice, if timestamps could be preserved when rewriting the
> >> git-log.
> >
> > Unfortunately, last I checked (a long time ago!), explicitly
Peter Münster wrote:
> On Sat, Jun 11 2016, Eric Wong wrote:
>
> > The git log after dcommit is tied to the SVN log,
> > so git-svn can only reflect changes which appear in SVN.
>
> You mean, it's impossible, to keep the original timestamps??
It might be; just not
Samuel GROOT wrote:
> On 06/09/2016 02:21 AM, Eric Wong wrote:
> >Samuel GROOT wrote:
> >>Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1].
> >>Should we handle \n\r at end of line as well?
> >
> >"\n\r" can never happen with loca
Alfred Perlstein wrote:
> Add example usage to the git-svn documentation.
>
> Reported-by: Joseph Pecoraro
> Signed-off-by: Alfred Perlstein
> ---
>
> Junio, Pranit, + all,
>
> A week ago I was requested to provide documentation for the
> 'svn propset' command. I have attached a diff off of
Leo Gaspard wrote:
> First, sorry for not having this message threaded: I'm not subscribed to
> the list and haven't found a way to get a Message-Id from gmane.
Appending "/raw" to the gmane URL will get you the raw message
with full headers:
article.gmane.org/gmane.comp.version-control.git/$N
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
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
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:
> 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
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
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
Jeff King wrote:
> On Fri, Aug 12, 2016 at 10:42:55PM +, Eric Wong wrote:
> > Junio C Hamano wrote:
> > > is still available. An alternative
> > >
> > > nntp://news.public-inbox.org/inbox.comp.version-control.git
> > >
> > > w
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
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
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
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"
> >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
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
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
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
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 m...@public-inbox.o
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
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
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
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
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
Brian Henderson wrote:
> On Wed, Aug 10, 2016 at 08:56:35AM +, 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)
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
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.
> >
>
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)
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
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
>
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 @@
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
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,
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
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
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
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/
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
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
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?
&
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
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
Josh Triplett wrote:
> On Tue, Aug 16, 2016 at 09:27:04PM +, 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
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-
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
(Not sure how much time I'll have to continue in the next few weeks,
just jotting down my debugging progress so far...)
Yaroslav Halchenko wrote:
> even when (v 2.7.0) ran on the box where the server is, so
> unlikely to be network issue
>
> or from my laptop (v 2.9.3) with ok but wifi with a w
+)
Eric Wong (3):
http: warn on curl_multi_add_handle failures
http: consolidate #ifdefs for curl_multi_remove_handle
http: always remove curl easy from curlm session on release
http.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
--
EW
This will be useful for tracking down curl usage errors.
Signed-off-by: Eric Wong
---
http.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/http.c b/http.c
index cd40b01..cac5db9 100644
--- a/http.c
+++ b/http.c
@@ -1022,6 +1022,8 @@ int start_active_slot(struct active_request_slot *slot
I find #ifdefs makes code difficult-to-follow.
An early version of this patch had error checking for
curl_multi_remove_handle calls, but caused some tests (e.g.
t5541) to fail under curl 7.26.0 on old Debian wheezy.
Signed-off-by: Eric Wong
---
http.c | 17 ++---
1 file changed, 10
We must call curl_multi_remove_handle when releasing the slot to
prevent subsequent calls to curl_multi_add_handle from failing
with CURLM_ADDED_ALREADY (in curl 7.32.1+; older versions
returned CURLM_BAD_EASY_HANDLE)
Signed-off-by: Eric Wong
---
http.c | 10 ++
1 file changed, 6
Junio C Hamano wrote:
> Eric Wong writes:
> > The key patch here is 3/3 which seems like an obvious fix to
> > adding the problem of adding a curl easy handle to a curl multi
> > handle repeatedly.
>
> Yeah, sounds like the right thing to do and 2/3 makes it really e
Jeff King wrote:
> On Wed, Sep 21, 2016 at 09:46:23PM +, Eric Wong wrote:
>
> > ---8<---
> > Subject: [PATCH] http: check curl_multi_remove_handle error code
> >
> > This should help detect bugs in future changes. While we're at
> &g
Kevin Wern wrote:
> Hey, all,
>
> It's been a while (sent a very short patch in May), but I've
> still been working on the resumable clone feature and checking up on
> the mailing list for any updates. After submitting the prime-clone
> service alone, I figured implementing the whole thing would
Junio C Hamano wrote:
> Eric Wong writes:
>
> >> [primeclone]
> >>url = http://location/pack-$NAME.pack
> >>filetype = pack
> >
> > If unconfigured, I wonder if a primeclone pack can be inferred by
> > the existence of a pack bitmap (o
Hi Junio, have you taken a look at:
http://mid.gmane.org/20160116101719.ga21...@dcvr.yhbt.net ?
("git-svn: fix auth parameter handling on SVN 1.9.0+")
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo i
Junio C Hamano wrote:
> I am not sure if it is a good idea to show */*/* as an example in
> the message (that is an anti-example of 'one set of wildcard' by
> having three stars, isn't it?), but that is not a new issue this
> change introduces.
Actually, going back to commit 570d35c26dfbc40757da6
Junio C Hamano wrote:
> Eric Wong writes:
>
> > Hi Junio, have you taken a look at:
> > http://mid.gmane.org/20160116101719.ga21...@dcvr.yhbt.net ?
> > ("git-svn: fix auth parameter handling on SVN 1.9.0+")
>
> Yes, I did, and I also did notice tha
take the first successful
connection.
This may increase network traffic and server load slightly, but
makes the worst-case user experience more bearable when one
lacks permissions to edit /etc/gai.conf to favor IPv4 addresses.
Signed-off-by: Eric Wong
---
connect.c | 118
er. Since transport already has a
"verbose" field, use that field instead of another parameter
in connect_setup.
Signed-off-by: Eric Wong
---
Related, but independent of my other change to connect.c:
http://mid.gmane.org/20160128115720.ga1...@dcvr.yhbt.net
("attempt connects in
Jeff King wrote:
> On Thu, Jan 28, 2016 at 10:51:23PM +, Eric Wong wrote:
> > -static int connect_setup(struct transport *transport, int for_push, int
> > verbose)
> > +static int connect_setup(struct transport *transport, int for_push)
> > {
> >
Junio C Hamano wrote:
> Eric Wong writes:
>
> > getaddrinfo() may return multiple addresses, not all of which
> > are equally performant. In some cases, a user behind a non-IPv6
> > capable network may get an IPv6 address which stalls connect().
> > Instead
change reorders the buffers to have the same index as windows while
keeping the cursor default to the merged result as the bottom window.
Signed-off-by: Dickson Wong
---
mergetools/vimdiff | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mergetools/vimdiff b/mergetools
I have not used rsync remotes in ages, but I was working on the
patch for -4/-6 support and decided to test it against rsync.kernel.org
Cloning git.git takes forever and failed with:
$ git clone rsync://rsync.kernel.org/pub/scm/git/git.git
Checking connectivity... fatal: bad object
ecdc6d8612df8
Jeff King wrote:
> On Sat, Jan 30, 2016 at 02:21:26AM -0500, Jeff King wrote:
> > Even the commit porting rsync over to C from shell (cd547b4)
> > lists it as deprecated! So between the 10 years of informal
> > warnings, and the fact that it has been severely broken
> > since 2007, it's probably s
en called
with the verbose parameter. Since transport already has a
"verbose" field, use that field instead of another parameter
in connect_setup.
v2: add "-v" tests for clone/fetch/pull to t5570-git-daemon.sh
Signed-off-by: Eric Wong
---
t/t5570-git-daemon.sh | 25 +++
Junio C Hamano wrote:
> Eric Wong writes:
>
> > getaddrinfo() may return multiple addresses, not all of which
> > are equally performant. In some cases, a user behind a non-IPv6
> > capable network may get an IPv6 address which stalls connect().
>
> I'
deprecated
and scheduled to be removed.
Signed-off-by: Eric Wong
---
Documentation/fetch-options.txt | 8
Documentation/git-push.txt | 7 +++
builtin/clone.c | 4
builtin/fetch.c | 4
builtin/push.c | 4
connect.c
Eric Wong wrote:
> rsync support is untouched for now since it is deprecated
> and scheduled to be removed.
I forgot add I'm not sure how to actually go about testing these changes
automatically since they involve DNS setups. And the test suite seems
really slow nowadays, I guess/ho
Torsten Bögershausen wrote:
> On 2016-01-30 14.13, Eric Wong wrote:
> > The ssh(1) command has an equivalent switches which we may
> > pass when we run them.
> Should we mention that putty and tortoiseplink don't have these options ?
> At least in the commit message ?
ints to enum
- shorted CONNECT_* macro names to be consistent with switches
- remove unneeded TRANS_OPT_* macros and usage
- remove transport_set_family wrapper, enum is enough validation
- s/resolve/use/ in documentation
- document potential (but unconfirmed) problems with some ssh(1)
Sign
Kazutoshi Satoda wrote:
> I'm sorry not coming with test scripts, but I couldn't figure out how to
> write tests to reproduce problems happen only with non-UTF-8 paths while
> the tests seems to be run on UTF-8 locale.
Thank you. I will try to work on some tests throughout the week
(help appreci
201 - 300 of 955 matches
Mail list logo
