On Tue, Aug 04, 2015 at 05:27:13PM -0400, Taylor Braun-Jones wrote:
> On Tue, Aug 4, 2015 at 2:56 PM, Stefan Beller wrote:
> > On Tue, Aug 4, 2015 at 10:45 AM, Taylor Braun-Jones
> > wrote:
> >> Fetching from an hg remote fails with bare git repositories. Non-bare
> >> repositories work fine.
> >
On Wed, Sep 16, 2015 at 03:06:32PM -0700, Jacob Keller wrote:
> This topic depends on mh/notes-allow-reading-treeish and actually
> expands what this topic allowed before. Previously, treeishes such as
> notes@{1} were made allowable, but the ref still had to be found under
> refs/notes.
I haven't
rful, they don't have an equivalent override.
Add a GIT_REPLACE_NAMESPACE environment variable to control where git is
going to look for replace refs.
Signed-off-by: Mike Hommey
---
I'm not sure if I need to care about avoiding strlen in log-tree.c, or if I
should handle the lack
On Wed, Jun 10, 2015 at 09:55:30PM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > It can be useful to have grafts or replace refs for specific
> > use-cases while keeping the default "view" of the repository
> > pristine (or with a different set of g
On Thu, Jun 11, 2015 at 08:16:02AM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > I do agree that this is all confusing, but allow me to point out that
> > it's already plenty confusing: "namespace" is a term that has been used to
> > designate
rful, they don't have an equivalent override.
Add a GIT_REPLACE_REF_BASE environment variable to control where git is
going to look for replace refs.
Signed-off-by: Mike Hommey
---
builtin/replace.c | 6 +++---
cache.h | 2 ++
environment.c | 6 ++
log-tree.c|
allowing them, e.g. git log --notes=foo@{1}, although
I haven't checked whether that's the case for all of them.
Signed-off-by: Mike Hommey
---
My motivation for this change is to allow to use init_notes from a
third-party helper that links to libgit.a with a commit that is not
pointed at dir
On Tue, Jun 16, 2015 at 11:22:31PM -0400, Jeff King wrote:
> On Wed, Jun 17, 2015 at 10:15:31AM +0900, Mike Hommey wrote:
>
> > init_notes() is essentially the only point of entry to the notes API.
> > It is an arbitrary restriction that all it allows as input is a strict
On Tue, Jun 16, 2015 at 08:17:03PM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > init_notes() is essentially the only point of entry to the notes API.
> > It is an arbitrary restriction that all it allows as input is a strict
> > ref name, when callers may w
Hi,
I did something "stupid" with a script using fast-import, and that made
the whole process ~20% slower on Linux and 400~500% slower on Mac. The
reason this happened is that the script was essentially adding a "from"
to every "commit" command, even when the "from" commit is the current
head of t
is has the side effect of enabling the use of committish as notes refs
in commands allowing them, e.g. git log --notes=foo@{1}.
Signed-off-by: Mike Hommey
---
The die() message in init_notes is left to be desired. But I don't have a
better idea at the moment.
Note that die()ing in an API is n
is has the side effect of enabling the use of committish as notes refs
in commands allowing them, e.g. git log --notes=foo@{1}.
Signed-off-by: Mike Hommey
---
builtin/notes.c | 29 -
notes-cache.c | 11 ++-
notes-utils.c | 6 +++---
notes
On Mon, Jul 06, 2015 at 03:54:35PM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > One of the first things parse_from does is unconditionally throw away
> > the tree for the given branch, and then the "from" tree is loaded. So
> > when the "from&qu
On Thu, Jul 09, 2015 at 02:03:15PM +0900, Mike Hommey wrote:
> On Mon, Jul 06, 2015 at 03:54:35PM -0700, Junio C Hamano wrote:
> > Mike Hommey writes:
> >
> > > One of the first things parse_from does is unconditionally throw away
> > > the tree for the given br
cularly slow at least on OSX.
So, avoid resetting the tree when it's unmodified, and avoid calling
gfi_unpack_entry when the given mark points to the same commit as the
current branch head.
Signed-off-by: Mike Hommey
---
fast-import.c | 29 +
1 file changed, 17 inse
On Thu, Jul 09, 2015 at 01:37:02PM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> Cc'ed a few people who appear at the top of "shortlog --no-merges";
> I think the end result is not incorrect, but I want to hear second
> opinions on this one. I do not k
the side effect of enabling the use of treeish as notes refs in
commands allowing them, e.g. git log --notes=foo@{1}.
Signed-off-by: Mike Hommey
Reviewed-by: Johan Herland
---
builtin/notes.c | 29 -
notes-cache.c | 11 ++-
notes-utils.c | 6 +++---
notes
On Fri, Jul 10, 2015 at 09:16:16AM +0200, Johan Herland wrote:
> On Fri, Jul 10, 2015 at 3:28 AM, Mike Hommey wrote:
> > init_notes() is the main point of entry to the notes API. It is an arbitrary
> > restriction that all it allows as input is a strict ref name, when callers
>
the side effect of enabling the use of treeish as notes refs in
commands allowing them, e.g. git log --notes=foo@{1}.
Signed-off-by: Mike Hommey
---
builtin/notes.c | 29 -
notes-cache.c| 11 ++-
notes-utils.c| 6 +++---
notes.c | 11 +
On Mon, Jul 13, 2015 at 09:35:40AM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > init_notes() is the main point of entry to the notes API. It is an arbitrary
> > restriction that all it allows as input is a strict ref name, when callers
> > may want to g
On Thu, Jun 30, 2016 at 11:12:52AM -0700, Linus Torvalds wrote:
> On Thu, Jun 30, 2016 at 3:30 AM, Jakub Narębski wrote:
> >
> > P.S. Having Git ensure that committerdate (as an epoch) is greater
> > than committerdates of its parents at the commit creation time (with
> > providing warning about t
The are many ways in which fast-import ends up calling gfi_unpack_entry,
and fery few work-arounds. I've patched fast-import for it to be smarter
in corner cases, allowing some additional work-arounds, but it's just
too easy to fall on gfi_unpack_entry again, so I abandonned that path.
The problem
On Mon, Jul 04, 2016 at 08:44:39AM +0900, Mike Hommey wrote:
> + /* Ensure a pack window on the data before that, otherwise,
> + * use_pack() may try to create a window that overlaps with
> + * this one, and that won't work because it won
Git-cinnabar is a git remote helper to interact with mercurial
repositories. It allows to clone, pull and push from/to mercurial remote
repositories, using git.
Code on https://github.com/glandium/git-cinnabar
This release on
https://github.com/glandium/git-cinnabar/releases/tag/0.4.0b1
[ Previou
On Thu, Jul 07, 2016 at 01:47:19PM +0200, Johannes Schindelin wrote:
> Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), i.e. for
> almost 11 years already, we demonstrated our disrespect to the pioneers
> of software development like Ada Lovelace, Grace Hopper and Margaret
> Hamilton
Hi,
I had a procastination episode today and wrote
https://glandium.org/blog/?p=3659 . It started with me looking what git
was doing with the size of the index when writing the index header,
leading me to find a rather improbable integer overflow in
https://github.com/git/git/blob/5c589a73de4394ad
On Thu, Jul 14, 2016 at 09:58:45AM +0200, Johannes Schindelin wrote:
> Hi Junio,
>
> On Wed, 13 Jul 2016, Junio C Hamano wrote:
>
> > Does Travis CI testing have an option to run our tests on some
> > 32-bit platforms?
>
> AFAIR Docker does not support 32-bit, and IIRC that's what Travis uses.
>
On Thu, Jul 14, 2016 at 12:58:47PM +0200, Johannes Schindelin wrote:
> Hi Mike,
>
> On Thu, 14 Jul 2016, Mike Hommey wrote:
>
> > On Thu, Jul 14, 2016 at 09:58:45AM +0200, Johannes Schindelin wrote:
> > > Hi Junio,
> > >
> > > On Wed, 13 Jul 20
When blaming files, changes in the work tree are taken into account
and displayed as being "Not Committed Yet".
However, when blaming a file that is not known to the current HEAD,
git blame fails with `no such path 'foo' in HEAD`, even when the file
was git add'ed.
This would seem uninteresting w
On Fri, Jul 15, 2016 at 08:46:03AM +0200, Christian Couder wrote:
> Hi,
>
> It seems to me that there are many current topics/patch series in
> flight that are about making Git interact with external code/processes
> and that it could be interesting to step back a bit and see if we
> could find a
On Fri, Jul 15, 2016 at 12:45:15PM +0200, Johannes Schindelin wrote:
> Hi Mike,
>
> On Fri, 15 Jul 2016, Mike Hommey wrote:
>
> > When blaming files, changes in the work tree are taken into account
> > and displayed as being "Not Committed Yet".
> >
>
On Fri, Jul 15, 2016 at 08:37:59AM -0400, Jeff King wrote:
> On Fri, Jul 15, 2016 at 09:32:45PM +0900, Mike Hommey wrote:
>
> > > > +test_expect_success 'blame wholesale copy and more in the index' '
> > > > +
> > > > + {
> >
would seem uninteresting with the plain `git blame` case, which
it is, but it becomes useful when using copy detection, and the new file
was created from pieces already in HEAD, moved or copied from other
files.
Signed-off-by: Mike Hommey
---
builtin/blame.c | 4 ++-
t/t8003-b
> I suspect that this would be useful without copy detection. If you
> "git mv fileA fileB" (optionally followed by "edit fileB"), fileB
> would not be in HEAD but you should be able to trace the lineage of
> the lines in it back through the renaming event, and this change
> also allows that use c
Somehow, this test was using:
{
echo A
echo B
} > file
block to feed file contents. This changes those to the form most common
in git test scripts:
cat >file <<-\EOF
A
B
EOF
Signed-off-by: Mike Hommey
---
t/t8003-blame-corner-c
would seem uninteresting with the plain `git blame` case, which
it is, but it becomes useful when using copy detection, and the new file
was created from pieces already in HEAD, moved or copied from other
files.
Signed-off-by: Mike Hommey
---
builtin/blame.c | 10 +-
t/t8
Hi,
Any thoughts on the following?
Mike
On Mon, Jul 04, 2016 at 08:44:39AM +0900, Mike Hommey wrote:
> The are many ways in which fast-import ends up calling gfi_unpack_entry,
> and fery few work-arounds. I've patched fast-import for it to be smarter
> in corner cases, allowing s
Git-cinnabar is a git remote helper to interact with mercurial
repositories. It allows to clone, pull and push from/to mercurial remote
repositories, using git.
Code on https://github.com/glandium/git-cinnabar
This release on
https://github.com/glandium/git-cinnabar/releases/tag/0.4.0b2
[ Previou
On Thu, Aug 04, 2016 at 03:28:55PM -0700, Junio C Hamano wrote:
> * mh/connect (2016-06-06) 10 commits
> - connect: [host:port] is legacy for ssh
> - connect: move ssh command line preparation to a separate function
> - connect: actively reject git:// urls with a user part
> - connect: change t
On Thu, Aug 04, 2016 at 04:32:02PM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > On Thu, Aug 04, 2016 at 03:28:55PM -0700, Junio C Hamano wrote:
> >> * mh/connect (2016-06-06) 10 commits
> >> - connect: [host:port] is legacy for ssh
> >>
On Mon, Aug 08, 2016 at 08:48:55AM +0200, Torsten Bögershausen wrote:
> On 2016-08-05 01.32, Junio C Hamano wrote:
> > Mike Hommey writes:
> []
>
> >> What kind of support are you expecting?
> >
> > The only rationale I recall you justifying this series w
ually.
Signed-off-by: Mike Hommey
---
This is something I should have submitted a patch for a long time ago, back
when this was discussed in the thread starting from
https://www.spinics.net/lists/git/msg242426.html. The message most relevant to
this patch in the thread is https://www.spinics.net/l
Hi,
Git-cinnabar is a git remote helper to interact with mercurial
repositories. It allows to clone, pull and push from/to mercurial remote
repositories, using git.
Code on https://github.com/glandium/git-cinnabar
This release on
https://github.com/glandium/git-cinnabar/releases/tag/0.4.0rc2
[ P
On Tue, Dec 20, 2016 at 05:47:44PM +0900, Mike Hommey wrote:
> Hi,
>
> Git-cinnabar is a git remote helper to interact with mercurial
> repositories. It allows to clone, pull and push from/to mercurial remote
> repositories, using git.
>
> Code on https://github.com/glandiu
On Tue, Dec 20, 2016 at 11:34:04AM -0800, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > In typical uses of fast-import, trees are inherited from a parent
> > commit. In that case, the tree_entry for the branch looks like:
> > ...
> > +# Create another notes tr
ually.
Signed-off-by: Mike Hommey
---
fast-import.c| 8 +---
t/t9301-fast-import-notes.sh | 42 ++
2 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index cb545d7df5..5e528b1999 100644
--- a/f
Sorry, I forgot the v2 in the subject.
Mike
Hi,
As you might be aware, I'm working on a mercurial remote helper for git.
The way it stores metadata for mercurial manifests abuses "commit"
references in trees, which are normally used for submodules.
Some operations in the helper use git diff-tree on those trees to find
files faster than jus
Hi,
So I was checking out differences between two branches, accounting for
file moves with -C, and was surprised by the number of insertions and
deletions that it indicated, because it was telling me I had removed
more than I added, which I really don't think is true.
I took a closer look, and wh
Hi,
I've had this kind of things to do more than once, and had to do it a
lot today, so I figured it would be worth discussing whether git-rebase
should be enhanced to support this, or if this should go in a separate
tool or whatever.
So here is what I'm trying to do in a not-too painful way:
I'
On Mon, Jan 09, 2017 at 01:21:37AM -0500, Jeff King wrote:
> On Wed, Jan 04, 2017 at 09:11:55AM -0700, Martin Fick wrote:
>
> > I am replying to this email across lists because I wanted to
> > highlight to the git community this jgit change to repacking
> > that we have up for review
> >
> > h
Hi,
Git-cinnabar is a git remote helper to interact with mercurial
repositories. It allows to clone, pull and push from/to mercurial remote
repositories, using git.
Code on https://github.com/glandium/git-cinnabar
This release on
https://github.com/glandium/git-cinnabar/releases/tag/0.4.0
What's
gpg.
With this change applied, the output becomes, on this new machine:
gpg: keyblock resource '/usr/share/keyrings/debian-keyring.gpg': No
such file or directory
error: gpg failed to sign the data
error: unable to sign the tag
which makes it clearer what's wrong.
Signed-off-
On Wed, Jan 25, 2017 at 03:04:38PM -0800, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > For instance, after changing my laptop for a new one, I copied my
> > configs, but had some environment differences that broke gpg.
> > With this change applied, the output beco
On Wed, Jan 25, 2017 at 06:37:55PM -0800, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > On Wed, Jan 25, 2017 at 03:04:38PM -0800, Junio C Hamano wrote:
> > ...
> >> Overall I think this is a good thing to do. Instead of eating the
> >> status output, sho
On Tue, Feb 07, 2017 at 06:49:24PM -0800, Linus Torvalds wrote:
> On Tue, Feb 7, 2017 at 6:40 PM, Mike Hommey wrote:
> >
> > As such, the default positive match should be ':/' (which is shorter and
> > less cumbersome than ':(top)', btw)
>
> S
On Tue, Feb 07, 2017 at 05:48:26PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 7 Feb 2017, Linus Torvalds wrote:
> >
> > [ Clarification from original message, since Junio asked: I didn't
> > actually want the semantics of '.' at all, since in a subdirectory it
> > limits to the current subdi
Hi,
Git-cinnabar is a git remote helper to interact with mercurial
repositories. It allows to clone, pull and push from/to mercurial remote
repositories, using git.
Code on https://github.com/glandium/git-cinnabar
This release on
https://github.com/glandium/git-cinnabar/releases/tag/0.4.0rc
[ Pr
Hi,
While trying to use the revision walking API twice in a row, I noticed
that the second time for the same setup would not yield the same result.
In my case, it turns out I was requesting boundaries, and
reset_revision_walk() is not resetting CHILD_SHOWN and BOUNDARY, both
required to be reset f
On Mon, Dec 05, 2016 at 08:09:58AM +0900, Mike Hommey wrote:
> Hi,
>
> While trying to use the revision walking API twice in a row, I noticed
> that the second time for the same setup would not yield the same result.
> In my case, it turns out I was requesting
On Tue, May 03, 2016 at 01:03:38AM -0400, Jeff King wrote:
> On Sun, May 01, 2016 at 12:10:09PM +0200, Torsten Bögershausen wrote:
>
> > On 2016-05-01 08.02, Mike Hommey wrote:
> > > get_port() is only used as a fallback when get_host_and_port() does not
> > > retu
.org/path.
This per-port behavior seems like an oversight rather than a deliberate
choice, so, make git://kernel.org:port/path call the gitProxy script in
the case described above.
Signed-off-by: Mike Hommey
---
connect.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/connect
the "user@" part of the host, in order to pick the port
properly. This also fixes the tests added 4 commits ago.
Signed-off-by: Mike Hommey
---
connect.c | 30 ++
t/t5500-fetch-pack.sh | 38 +-
2 files changed,
Signed-off-by: Mike Hommey
---
connect.c | 109 ++
1 file changed, 59 insertions(+), 50 deletions(-)
diff --git a/connect.c b/connect.c
index 215d6d9..37b3140 100644
--- a/connect.c
+++ b/connect.c
@@ -673,6 +673,62 @@ static enum
I went even further this time around. I'm not totally satistifed with
the resulting parse_connect_url function, but at least it feels to me
this series puts us in a better place to actually improve it further.
Mike Hommey (11):
add fetch-pack --diag-url tests for some corner cases
co
however preserve hostandport, at least for now.
Note that in git_tcp_connect_sock, the port was set to "" in a
case that never can happen, so that code path was removed.
Signed-off-by: Mike Hommey
---
connect.c | 47 +++
1 file changed, 23
While it is not strictly necessary, it makes the connect code simpler
when there is user.
Signed-off-by: Mike Hommey
---
connect.c| 12
t/t5601-clone.sh | 52
2 files changed, 48 insertions(+), 16 deletions(-)
This is
Previous changes made both branches handling CONNECT_DIAG_URL identical.
We can now remove one of those branches and have CONNECT_DIAG_URL be
handled in one place.
Signed-off-by: Mike Hommey
---
connect.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a
ables.
Signed-off-by: Mike Hommey
---
connect.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/connect.c b/connect.c
index 2a08318..ed1a00d 100644
--- a/connect.c
+++ b/connect.c
@@ -695,11 +695,24 @@ struct child_process *git_connect(int fd[2],
Currently, urls of the for git://user@host don't work because user@host
is not resolving at the DNS level, but we shouldn't be relying on it
being an invalid host name, and actively reject it for containing a
username in the first place.
Signed-off-by: Mike Hommey
---
connect.c | 3 +
Signed-off-by: Mike Hommey
---
connect.c | 37 +
1 file changed, 29 insertions(+), 8 deletions(-)
diff --git a/connect.c b/connect.c
index 8813f90..e95e385 100644
--- a/connect.c
+++ b/connect.c
@@ -588,11 +588,13 @@ static char *get_port(char *host
Signed-off-by: Mike Hommey
---
connect.c | 6 ++
t/t5500-fetch-pack.sh | 14 --
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/connect.c b/connect.c
index e95e385..2c5b722 100644
--- a/connect.c
+++ b/connect.c
@@ -703,10 +703,8 @@ struct
ed by git, the values used
could be valid user names (user names can actually contain colons
and at signs), and are still worth testing the url parser for.
Signed-off-by: Mike Hommey
---
t/t5500-fetch-pack.sh | 38 ++
1 file changed, 34 insertions(+), 4 dele
---
connect.c | 109 ++
1 file changed, 59 insertions(+), 50 deletions(-)
Err, I had forgotten to commit --amend to add a missing argument.
diff --git a/connect.c b/connect.c
index 215d6d9..5f86983 100644
--- a/connect.c
+++ b/connect.c
On Tue, May 03, 2016 at 09:07:41AM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > t5603-clone-dirname uses url patterns that are not tested with
> > fetch-pack --diag-url, and it would be useful if they were.
> >
> > Interestingly, some of those test
On Tue, May 03, 2016 at 01:23:37PM -0400, Eric Sunshine wrote:
> On Tue, May 3, 2016 at 12:20 PM, Torsten Bögershausen wrote:
> > On 2016-05-03 10.50, Mike Hommey wrote:
> >> - git fetch-pack --diag-url "$1" | grep -v host= | grep -v port=
> >> >actual
On Tue, May 03, 2016 at 01:33:24PM -0400, Eric Sunshine wrote:
> On Tue, May 3, 2016 at 4:50 AM, Mike Hommey wrote:
> > While it is not strictly necessary, it makes the connect code simpler
> > when there is user.
> >
> > Signed-off-by: Mike Hommey
> > ---
>
On Wed, May 04, 2016 at 07:48:30AM +0900, Mike Hommey wrote:
> On Tue, May 03, 2016 at 09:07:41AM -0700, Junio C Hamano wrote:
> > Mike Hommey writes:
> >
> > > t5603-clone-dirname uses url patterns that are not tested with
> > > fetch-pack --diag-url, an
Signed-off-by: Mike Hommey
---
connect.c | 6 ++
t/t5500-fetch-pack.sh | 14 --
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/connect.c b/connect.c
index c40ff35..df15ff3 100644
--- a/connect.c
+++ b/connect.c
@@ -703,10 +703,8 @@ struct
.org/path.
This per-port behavior seems like an oversight rather than a deliberate
choice, so, make git://kernel.org:port/path call the gitProxy script in
the case described above.
Signed-off-by: Mike Hommey
---
connect.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/connect
Currently, urls of the for git://user@host don't work because user@host
is not resolving at the DNS level, but we shouldn't be relying on it
being an invalid host name, and actively reject it for containing a
username in the first place.
Signed-off-by: Mike Hommey
---
connect.c | 3 +
I removed the two controvertial patches, and applied the various suggestions
from the last cycle.
Mike Hommey (9):
connect: call get_host_and_port() earlier
connect: only match the host with core.gitProxy
connect: fill the host header in the git protocol with the host and
port variables
ables.
Signed-off-by: Mike Hommey
---
connect.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/connect.c b/connect.c
index 2a08318..ed1a00d 100644
--- a/connect.c
+++ b/connect.c
@@ -695,11 +695,24 @@ struct child_process *git_connect(int fd[2],
the "user@" part of the host, in order to pick the port
properly.
Signed-off-by: Mike Hommey
---
connect.c | 30 ++
t/t5500-fetch-pack.sh | 32 +---
2 files changed, 39 insertions(+), 23 deletions(-)
diff --git a/connect
Signed-off-by: Mike Hommey
---
connect.c | 33 +
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/connect.c b/connect.c
index 8813f90..c40ff35 100644
--- a/connect.c
+++ b/connect.c
@@ -588,11 +588,13 @@ static char *get_port(char *host)
* Extract
Previous changes made both branches handling CONNECT_DIAG_URL identical.
We can now remove one of those branches and have CONNECT_DIAG_URL be
handled in one place.
Signed-off-by: Mike Hommey
---
connect.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a
however preserve hostandport, at least for now.
Note that in git_tcp_connect_sock, the port was set to "" in a
case that never can happen, so that code path was removed.
Signed-off-by: Mike Hommey
---
connect.c | 47 +++
1 file changed, 23
Signed-off-by: Mike Hommey
---
connect.c | 108 +-
1 file changed, 58 insertions(+), 50 deletions(-)
diff --git a/connect.c b/connect.c
index fdd40b0..ae9ef7b 100644
--- a/connect.c
+++ b/connect.c
@@ -673,6 +673,61 @@ static enum
On Mon, May 16, 2016 at 03:30:01PM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > Currently, core.gitProxy doesn't actually match purely on domain names
> > as documented: it also matches ports.
> > ...
> > This per-port behavior seems like an
On Mon, May 16, 2016 at 03:39:08PM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > + get_host_and_port(&host, &port);
> > +
> > + if (*host && !port) {
> > + /* The host might contain a user:password string, ignore it
> &
The main difference here is patch 2/9 now throwing an error in user's face
when they have a core.gitProxy configuration with a port number. There might
be some bikeshedding to do on the content of the error message.
Mike Hommey (9):
connect: call get_host_and_port() earlier
connect:
Previous changes made both branches handling CONNECT_DIAG_URL identical.
We can now remove one of those branches and have CONNECT_DIAG_URL be
handled in one place.
Signed-off-by: Mike Hommey
---
connect.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a
Currently, urls of the for git://user@host don't work because user@host
is not resolving at the DNS level, but we shouldn't be relying on it
being an invalid host name, and actively reject it for containing a
username in the first place.
Signed-off-by: Mike Hommey
---
connect.c | 3 +
change.
Signed-off-by: Mike Hommey
---
connect.c | 20 +---
t/t5532-fetch-proxy.sh | 8 +++-
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/connect.c b/connect.c
index d3448c2..0f48cde 100644
--- a/connect.c
+++ b/connect.c
@@ -490,6 +
however preserve hostandport, at least for now.
Note that in git_tcp_connect_sock, the port was set to "" in a
case that never can happen, so that code path was removed.
Signed-off-by: Mike Hommey
---
connect.c | 47 +++
1 file changed, 23
ables.
Signed-off-by: Mike Hommey
---
connect.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/connect.c b/connect.c
index 0f48cde..0676ee0 100644
--- a/connect.c
+++ b/connect.c
@@ -709,11 +709,24 @@ struct child_process *git_connect(int fd[2],
Signed-off-by: Mike Hommey
---
connect.c | 6 ++
t/t5500-fetch-pack.sh | 14 --
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/connect.c b/connect.c
index 2659b40..dcaf32f 100644
--- a/connect.c
+++ b/connect.c
@@ -720,10 +720,8 @@ struct
the "user@" part of the host, in order to pick the port
properly.
Signed-off-by: Mike Hommey
---
connect.c | 33 +
t/t5500-fetch-pack.sh | 32 +---
2 files changed, 42 insertions(+), 23 deletions(-)
diff --git a/c
Signed-off-by: Mike Hommey
---
connect.c | 108 +-
1 file changed, 58 insertions(+), 50 deletions(-)
diff --git a/connect.c b/connect.c
index 7360d57..38cdffc 100644
--- a/connect.c
+++ b/connect.c
@@ -690,6 +690,61 @@ static enum
Signed-off-by: Mike Hommey
---
connect.c | 33 +
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/connect.c b/connect.c
index 3a77b2f..2659b40 100644
--- a/connect.c
+++ b/connect.c
@@ -602,11 +602,13 @@ static char *get_port(char *host)
* Extract
1 - 100 of 368 matches
Mail list logo
