[PATCH v6 5/9] connect: group CONNECT_DIAG_URL handling code

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 <m...@glandium.org> --- connect.c | 16 +--- 1 file changed, 1 insertion(+), 15 del

[PATCH v5 2/9] connect: only match the host with core.gitProxy

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 <m...@glandium.org> --- connect.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --g

[PATCH v5 8/9] connect: actively reject git:// urls with a user part

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 <m...@glandium.

[PATCH v5 0/9] connect: various cleanups

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

[PATCH v5 3/9] connect: fill the host header in the git protocol with the host and port variables

. Signed-off-by: Mike Hommey <m...@glandium.org> --- 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_c

[PATCH v5 6/9] connect: make parse_connect_url() return the user part of the url as a separate value

Signed-off-by: Mike Hommey <m...@glandium.org> --- 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_por

[PATCH v5 5/9] connect: group CONNECT_DIAG_URL handling code

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 <m...@glandium.org> --- connect.c | 16 +--- 1 file changed, 1 insertion(+), 15 del

[PATCH v5 1/9] connect: call get_host_and_port() earlier

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 <m...@glandium.org> --- connect.c | 47 +++

[PATCH v5 9/9] connect: move ssh command line preparation to a separate function

Signed-off-by: Mike Hommey <m...@glandium.org> --- 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 +

[PATCH v5 7/9] connect: change the --diag-url output to separate user and host

Signed-off-by: Mike Hommey <m...@glandium.org> --- 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

Re: [PATCH 1/6] connect: remove get_port()

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

[PATCH v4 05/11] connect: make parse_connect_url() return separated host and port

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 <m...@glandium.org> --- connect.c | 30 ++ t/t5500-fetch-pack.sh | 38 +

[PATCH v4 11/11] connect: move ssh command line preparation to a separate function

Signed-off-by: Mike Hommey <m...@glandium.org> --- 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 +

[PATCH v4 00/11] connect: various cleanups

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 connect

[PATCH v4 02/11] connect: call get_host_and_port() earlier

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 <m...@glandium.org> --- connect.c | 47 +++

[PATCH v4 09/11] connect: use "-l user" instead of "user@" on ssh command line

While it is not strictly necessary, it makes the connect code simpler when there is user. Signed-off-by: Mike Hommey <m...@glandium.org> --- connect.c| 12 t/t5601-clone.sh | 52 2 files changed, 48 insertions(

[PATCH v4 06/11] connect: group CONNECT_DIAG_URL handling code

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 <m...@glandium.org> --- connect.c | 16 +--- 1 file changed, 1 insertion(+), 15 del

[PATCH v4 03/11] connect: only match the host with core.gitProxy

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 <m...@glandium.org> --- connect.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --g

[PATCH v4 07/11] connect: make parse_connect_url() return the user part of the url as a separate value

Signed-off-by: Mike Hommey <m...@glandium.org> --- 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 *ge

[PATCH v4 04/11] connect: fill the host header in the git protocol with the host and port variables

. Signed-off-by: Mike Hommey <m...@glandium.org> --- 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_c

[PATCH v4 10/11] connect: actively reject git:// urls with a user part

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 <m...@glandium.

[PATCH v4 01/11] add fetch-pack --diag-url tests for some corner cases

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 <m...@glandium.org> --- t/t5500-fetch-pack.sh | 38 ++ 1 file changed, 34 inse

[PATCH v4 08/11] connect: change the --diag-url output to separate user and host

Signed-off-by: Mike Hommey <m...@glandium.org> --- 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

[PATCH v4.1 11/11] connect: move ssh command line preparation to a separate function

--- 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 +++

Re: [PATCH v4 09/11] connect: use "-l user" instead of "user@" on ssh command line

On Tue, May 03, 2016 at 01:33:24PM -0400, Eric Sunshine wrote: > On Tue, May 3, 2016 at 4:50 AM, Mike Hommey <m...@glandium.org> wrote: > > While it is not strictly necessary, it makes the connect code simpler > > when there is user. > > > > Signed-off-b

Re: [PATCH v4 08/11] connect: change the --diag-url output to separate user and host

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 <tbo...@web.de> wrote: > > On 2016-05-03 10.50, Mike Hommey wrote: > >> - git fetch-pack --diag-url "$1" | grep -v host= | grep -v port= &g

Re: [PATCH v4 01/11] add fetch-pack --diag-url tests for some corner cases

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 <m...@glandium.org> writes: > > > > > t5603-clone-dirname uses url patterns that are not tested with > > > fetch-

Re: [PATCH 1/6] connect: remove get_port()

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 > > return a port. But get_port() does the same search as > > get_host_and_port(), exc

Re: [PATCH 2/6] connect: uniformize and group CONNECT_DIAG_URL handling code

On Sun, May 01, 2016 at 03:37:24PM +0200, Torsten Bögershausen wrote: > I skipped the dates and names (I was responsible for one regression) > I hope this gives a half-correct overview, > why I am reluctant to change any code in connect.c > unless there is a fix for a real world problem. I don't

Re: [PATCH 2/6] connect: uniformize and group CONNECT_DIAG_URL handling code

On Mon, May 02, 2016 at 06:56:54AM +0200, Torsten Bögershausen wrote: > On 05/01/2016 08:02 AM, Mike Hommey wrote: > > + if (flags & CONNECT_DIAG_URL) { > > printf("Diag: url=%s\n", url ? url : "NULL"); > > pri

Re: [PATCH v4 01/11] add fetch-pack --diag-url tests for some corner cases

On Tue, May 03, 2016 at 09:07:41AM -0700, Junio C Hamano wrote: > Mike Hommey <m...@glandium.org> 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,

Re: [PATCH 2/6] connect: uniformize and group CONNECT_DIAG_URL handling code

On Mon, May 02, 2016 at 01:29:15PM +0200, Torsten Bögershausen wrote: > On 05/02/2016 10:31 AM, Mike Hommey wrote: > > On Mon, May 02, 2016 at 06:56:54AM +0200, Torsten Bögershausen wrote: > > > On 05/01/2016 08:02 AM, Mike Hommey wrote: > > > > +

Re: fast-import's gfi_unpack_entry causes too many munmap/mmap cycles

On Sat, Apr 16, 2016 at 08:04:03PM +0900, Mike Hommey wrote: > So I think I got myself a workaround... > > > A --- B > > \ > > \-- C > > > > I have: > > - diff between null-tree and A > > - diff between A and B > > - diff between B and

Re: fast-import's gfi_unpack_entry causes too many munmap/mmap cycles

On Sun, Apr 17, 2016 at 09:54:43AM +0900, Mike Hommey wrote: > On Sat, Apr 16, 2016 at 08:04:03PM +0900, Mike Hommey wrote: > > So I think I got myself a workaround... > > > > > A --- B > > > \ > > > \-- C > > > > > > I have: >

Re: Ambiguous sha-1 during a rebase

On Thu, Apr 14, 2016 at 11:09:06AM +0200, Matthieu Moy wrote: > I suspect you did: > > $ git rebase -i > # editor pops up > # switch to another terminal and fetch from elsewhere > # close editor That's possible, but I don't remember with certainty. At least it's plausible. > Then only, git

Ambiguous sha-1 during a rebase

Hi, Something interesting happened to me. I was in the middle of an interactive rebase, and after a --continue, I got: error: short SHA1 e34ff55 is ambiguous. fatal: Needed a single revision Invalid commit name: e34ff55 One thing that happened, is that, while running that interactive rebase, I

Re: Ambiguous sha-1 during a rebase

On Wed, Apr 13, 2016 at 03:42:44PM -0700, Junio C Hamano wrote: > Mike Hommey <m...@glandium.org> writes: > > > Should git-rebase use full sha-1s under the hood to avoid these type of > > races? > > It already should be doing so since Aug 2013, IIRC. I'm usin

Re: fast-import's gfi_unpack_entry causes too many munmap/mmap cycles

On Sat, Apr 16, 2016 at 06:18:39PM +0900, Mike Hommey wrote: > And even if I am okay with that overhead, I still hit the problem again > when using that tree later with `M 04 $sha1 ` in the next commit, > because that does a load_tree() for the tree sha1, after a commit having &

fast-import's gfi_unpack_entry causes too many munmap/mmap cycles

Hi, I think I've mentioned this issue in the past, and fixed one case of munmap/mmap cycle in fast-import. I've found more cases where this can happen, and while on Linux, it's not a problem, on OSX, it leads to catastrophic performance, when the import is massive. One part of the problem is

Re: fast-import's gfi_unpack_entry causes too many munmap/mmap cycles

On Sat, Apr 16, 2016 at 06:18:39PM +0900, Mike Hommey wrote: > Now, while each individual case could be improved to avoid > gfi_unpack_entry, it seems to me it would be better to make > gfi_unpack_entry better somehow. Come to think of it, there are cases that might still be worth fix

Re: 32-bit Travis, was Re: [ANNOUNCE] Git v2.9.1

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

[ANNOUNCE] git-cinnabar 0.4.0 beta 2

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 [

Re: [PATCH/RFC] fast-import: Keep a fake pack window on the recently written data

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 some a

Re: 32-bit Travis, was Re: [ANNOUNCE] Git v2.9.1

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.

Re: [PATCH] blame: Allow to blame paths freshly added to the index

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". >

Re: [PATCH] blame: Allow to blame paths freshly added to the index

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' ' > > > > + > > > > + { > > > > +

[PATCH v2] blame: Allow to blame paths freshly added to the index

nteresting 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 <m...@glandium.org> --- builtin/blame.c | 4 ++- t/t8

[PATCH v3 2/2] t/t8003-blame-corner-cases.sh: Use here documents

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 <m...@glandium.org> --- t/t8003-blame-co

[PATCH v3 1/2] blame: Allow to blame paths freshly added to the index

nteresting 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 <m...@glandium.org> --- builtin/blame.c | 10 +

Re: [PATCH] blame: Allow to blame paths freshly added to the index

> 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

[PATCH] blame: Allow to blame paths freshly added to the index

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

Re: Plugin mechanism(s) for Git?

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

Integer-overflow in read-cache.c can cause buffer-overflow (bug requires a crafted/corrupted index)

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

Re: [PATCH] am: counteract gender bias

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 >

Re: What's cooking in git.git (Aug 2016, #02; Thu, 4)

On Thu, Aug 04, 2016 at 04:32:02PM -0700, Junio C Hamano wrote: > Mike Hommey <m...@glandium.org> 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 lega

Re: What's cooking in git.git (Aug 2016, #02; Thu, 4)

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

Re: What's cooking in git.git (Aug 2016, #02; Thu, 4)

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 <m...@glandium.org> writes: > [] > > >> What kind of support are you expecting? > > > > The only rat

Re: topological index field for commit objects

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 > >

[ANNOUNCE] git-cinnabar 0.4.0 beta 1

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 [

[PATCH/RFC] fast-import: Keep a fake pack window on the recently written data

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

Re: [PATCH/RFC] fast-import: Keep a fake pack window on the recently written data

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't be

Re: Fwd: Possibly nicer pathspec syntax?

On Tue, Feb 07, 2017 at 06:49:24PM -0800, Linus Torvalds wrote: > On Tue, Feb 7, 2017 at 6:40 PM, Mike Hommey <m...@glandium.org> wrote: > > > > As such, the default positive match should be ':/' (which is shorter and > > less cumbersome than ':(top)', btw) >

Re: Fwd: Possibly nicer pathspec syntax?

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

Re: [PATCH] gpg-interface: Add some output from gpg when it errors out.

On Wed, Jan 25, 2017 at 03:04:38PM -0800, Junio C Hamano wrote: > Mike Hommey <m...@glandium.org> 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 chan

Re: [PATCH] gpg-interface: Add some output from gpg when it errors out.

On Wed, Jan 25, 2017 at 06:37:55PM -0800, Junio C Hamano wrote: > Mike Hommey <m...@glandium.org> 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 > &

[PATCH] gpg-interface: Add some output from gpg when it errors out.

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-by: Mike Hommey

Re: SHA1 collisions found

On Sat, Feb 25, 2017 at 02:26:56PM -0500, Jeff King wrote: > On Sat, Feb 25, 2017 at 06:50:50PM +, brian m. carlson wrote: > > > > As long as the reader can tell from the format of object names > > > stored in the "new object format" object from what era is being > > > referred to in some way

[ANNOUNCE] git-cinnabar 0.4.0

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

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 12:06:23PM -0700, Linus Torvalds wrote: > On Thu, Sep 29, 2016 at 11:55 AM, Linus Torvalds > wrote: > > > > For the kernel, just the *math* right now actually gives 12 > > characters. For current git it actually seems to say that 8 is the > >

[ANNOUNCE] git-cinnabar 0.4.0 release candidate

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 [

Should reset_revision_walk clear more flags?

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

Re: Should reset_revision_walk clear more flags?

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 reques

Rebasing multiple branches at once

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:

Counter-intuitive result from diff -C --stat

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

Re: Preserve/Prune Old Pack Files

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 > > > >

Re: [PATCH] fast-import: properly fanout notes when tree is imported

Sorry, I forgot the v2 in the subject. Mike

Re: [PATCH] fast-import: properly fanout notes when tree is imported

On Tue, Dec 20, 2016 at 11:34:04AM -0800, Junio C Hamano wrote: > Mike Hommey <m...@glandium.org> 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: > > ... > &g

[PATCH] fast-import: properly fanout notes when tree is imported

. Signed-off-by: Mike Hommey <m...@glandium.org> --- 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

[ANNOUNCE] git-cinnabar 0.4.0 release candidate 2

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 [

Re: [ANNOUNCE] git-cinnabar 0.4.0 release candidate 2

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/

[PATCH] fast-import: properly fanout notes when tree is imported

. Signed-off-by: Mike Hommey <m...@glandium.org> --- 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 http

Corner case involving null sha1, alternates, cache misses, and submodule config API

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

[PATCH] notes: Fix note_tree_consolidate not to break the note_tree structure

*. This doesn't have a practical effect on git because all that happens after a remove_note is a write_notes_tree, which just iterates the entire note tree, but this affects anything using libgit.a that would try to do lookups after removing notes. Signed-off-by: Mike Hommey <m...@glandium.

Re: RFC: Another proposed hash function transition plan

On Mon, Mar 06, 2017 at 03:40:30PM -0800, Jonathan Nieder wrote: > David Lang wrote: > > >> Translation table > >> ~ > >> A fast bidirectional mapping between sha1-names and sha256-names of > >> all local objects in the repository is kept on disk. The exact format > >> of that

Re: SHA1 collisions found

On Thu, Mar 02, 2017 at 02:27:15PM -0800, Linus Torvalds wrote: > On Thu, Mar 2, 2017 at 1:54 PM, Joey Hess wrote: > > > > There's a surprising result of combining iterated hash functions, that > > the combination is no more difficult to attack than the strongest hash > >

Re: [PATCH] strbuf: use designated initializers in STRBUF_INIT

On Mon, Jul 10, 2017 at 10:57:57AM -0400, Ben Peart wrote: > Correct. MSVC also supports designated initializers but does not fully > support C99. Precision: *recent versions* of MSVC support designated initializer. 2013 introduced them, but there were bugs until 2015, see e.g.

Re: [PATCH] strbuf: use designated initializers in STRBUF_INIT

On Fri, Jul 14, 2017 at 09:11:33AM -0700, Junio C Hamano wrote: > Junio C Hamano writes: > > > Oh, absolutely. > > > > Here is another possible test balloon, that may actually be useful > > as an example. I think there is a topic in flight that touches this > > array,

Re: Revision resolution for remote-helpers?

On Fri, Aug 18, 2017 at 08:15:09AM -0400, Jeff King wrote: > On Fri, Aug 18, 2017 at 03:42:08PM +0900, Mike Hommey wrote: > > > I was thinking it could be useful to have a special syntax for revisions > > that would query a helper program. The helper program could use a &g

Re: Revision resolution for remote-helpers?

On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote: > Hi, > > Mike Hommey wrote: > > > My thought is that a string like :: could be used > > wherever a committish is expected. That would call some helper > > and request to resolve revision, and

Revision resolution for remote-helpers?

Hi, As you might remember, I'm maintaining a remote helper that allows to talk directly to mercurial servers with git: git-cinnabar. When dealing with "foreign (non-git) repositories", it is often necessary to refer to revisions with their native name. With mercurial, that's a sha1, with svn

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

On Wed, May 10, 2017 at 12:33:44AM -0400, Jeff King wrote: > On Tue, May 09, 2017 at 09:22:11PM -0700, Shawn Pearce wrote: > > > > Hmm. That makes sense generally, as the request should succeed. But it > > > seems like we're creating a client that will sometimes succeed and > > > sometimes fail,

Re: [PATCH] fast-import: Increase the default pack depth to 50

On Thu, Jun 08, 2017 at 03:05:37AM -0400, Jeff King wrote: > On Thu, Jun 08, 2017 at 02:34:36PM +0900, Mike Hommey wrote: > > > In 618e613a70, 10 years ago, the default for pack depth used for > > git-pack-objects and git-repack was changed from 10 to 50, while > > leavi

[PATCH] fast-import: Increase the default pack depth to 50

, fast-import uses pack.depth when it's set, and the git-config manual says the default for pack.depth is 50. While the git-fast-import manual does say the default depth is 10, the inconsistency is also confusing. Signed-off-by: Mike Hommey <m...@glandium.org> --- Documentation/git-fast-import.t

[ANNOUNCE] git-cinnabar 0.5.0b1

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.5.0b1

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote: > Footnote *1*: SHA-256, as all hash functions whose output is essentially > the entire internal state, are susceptible to a so-called "length > extension attack", where the hash of a secret+message can be used to > generate the

[ANNOUNCE] git-cinnabar 0.5.0b2

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.5.0b2

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Thu, Jun 15, 2017 at 09:01:45AM -0400, Jeff King wrote: > On Thu, Jun 15, 2017 at 08:05:18PM +0900, Mike Hommey wrote: > > > On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote: > > > Footnote *1*: SHA-256, as all hash functions whose output is essenti

Re: Feature request: Please add support to stash specific files

On Tue, Jun 06, 2017 at 02:38:08PM -0400, rajdeep mondal wrote: > Hi Randall, > > I completely agree to what you are saying, but sometimes it just so > happens that in the middle of a change, i feel like if some portion of > the changes are fine I can commit them. Stashing some of the files >

Re: [git-for-windows] Re: Revision resolution for remote-helpers?

On Fri, Aug 25, 2017 at 09:02:36PM +0900, Mike Hommey wrote: > On Fri, Aug 25, 2017 at 12:58:52PM +0200, Johannes Schindelin wrote: > > > > > Cc-ing the Git for Windows mailing list as an FYI. > > > > > > > > > > I have faint memori

Re: git-clone causes out of memory

On Fri, Oct 13, 2017 at 12:51:58PM +0300, Constantine wrote: > There's a gitbomb on github. It is undoubtedly creative and funny, but since > this is a bug in git, I thought it'd be nice to report. The command: > > $ git clone https://github.com/x0rz/ShadowBrokersFiles What fills memory is

<    1   2   3   4   >