[ANNOUNCE] git-cinnabar 0.5.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.5.0

Re: Checks added for CVE-2018-11235 too restrictive?

On Wed, Jul 04, 2018 at 07:30:30AM +0900, Mike Hommey wrote: > That being said, I'm not even sure this particular use case is worth a > new feature. I'm not storing random stuff as gitlinks, I'm storing > sha1s. Well, maybe a mode that makes the distinction between "git oid"

Re: fast-import slowness when importing large files with small differences

On Tue, Jul 03, 2018 at 06:05:16PM +0200, Ævar Arnfjörð Bjarmason wrote: > > On Fri, Jun 29 2018, Mike Hommey wrote: > > > On Sat, Jun 30, 2018 at 12:10:24AM +0200, Ævar Arnfjörð Bjarmason wrote: > >> > >> On Fri, Jun 29 2018, Mike Hommey wrote: > >>

Re: Checks added for CVE-2018-11235 too restrictive?

On Tue, Jul 03, 2018 at 10:15:19AM -0400, Jeff King wrote: > On Tue, Jul 03, 2018 at 04:06:50PM +0900, Mike Hommey wrote: > > > I had a first shot at that a few months ago, but the format of the > > metadata branch made it impossible to push to github, hitting its push > &g

Re: [PATCH] fast-import: Don't count delta attempts against an empty buffer

On Tue, Jul 03, 2018 at 11:41:42AM -0700, Junio C Hamano wrote: > Mike Hommey writes: > > > When the reference buffer is empty, diff_delta returns NULL without > > really attempting anything, yet fast-import counts that as a delta > > attempt. > > But t

Checks added for CVE-2018-11235 too restrictive?

Hi, (Background) I'm the author of a git remote-helper that can talk directly to mercurial servers, known as git-cinnabar. One of the design decisions was to use git objects to store all the metadata necessary to reconstruct mercurial changesets, manifests and files, and one special thing that's

[PATCH] fast-import: Don't count delta attempts against an empty buffer

When the reference buffer is empty, diff_delta returns NULL without really attempting anything, yet fast-import counts that as a delta attempt. Signed-off-by: Mike Hommey --- fast-import.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fast-import.c b/fast-import.c index

Re: fast-import slowness when importing large files with small differences

On Sat, Jun 30, 2018 at 12:10:24AM +0200, Ævar Arnfjörð Bjarmason wrote: > > On Fri, Jun 29 2018, Mike Hommey wrote: > > > I noticed some slowness when fast-importing data from the Firefox mercurial > > repository, where fast-import spends more than 5 minutes importing ~2000

fast-import slowness when importing large files with small differences

Hi, I noticed some slowness when fast-importing data from the Firefox mercurial repository, where fast-import spends more than 5 minutes importing ~2000 revisions of one particular file. I reduced a testcase while still using real data. One could synthesize data with kind of the same properties,

Re: Git packs friendly to block-level deduplication

On Wed, Jan 24, 2018 at 02:23:57PM -0800, Junio C Hamano wrote: > Mike Hommey <m...@glandium.org> writes: > > > FWIW, I sidestep the problem entirely by using alternatives. > > That's a funny way to use the word "side-step", I would say, as the > alternate

Re: Git packs friendly to block-level deduplication

On Wed, Jan 24, 2018 at 11:03:47PM +0100, Ævar Arnfjörð Bjarmason wrote: > If you have a bunch of git repositories cloned of the same project on > the same filesystem, it would be nice of the packs that are produced > would be friendly to block-level deduplication. > > This would save space, and

Re: Bring together merge and rebase

On Fri, Dec 22, 2017 at 11:10:19PM -0700, Carl Baldwin wrote: > The big contention among git users is whether to rebase or to merge > changes [2][3] while iterating. I used to firmly believe that merging > was the way to go and rebase was harmful. More recently, I have worked > in some

Re: git-clone causes out of memory

On Fri, Oct 13, 2017 at 12:26:46PM +0200, Christian Couder wrote: > On Fri, Oct 13, 2017 at 12:06 PM, Mike Hommey <m...@glandium.org> wrote: > > On Fri, Oct 13, 2017 at 12:51:58PM +0300, Constantine wrote: > >> There's a gitbomb on github. It is undoubtedly creative an

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

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-for-windows] Re: Revision resolution for remote-helpers?

On Fri, Aug 25, 2017 at 12:58:52PM +0200, Johannes Schindelin wrote: > Hi Mike, > > On Thu, 24 Aug 2017, Mike Hommey wrote: > > > On Tue, Aug 22, 2017 at 10:15:20PM +0200, Johannes Schindelin wrote: > > > > > > On Fri, 18 Aug 2017, Jonathan Nieder wrote

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

On Tue, Aug 22, 2017 at 10:15:20PM +0200, Johannes Schindelin wrote: > Hi, > > On Fri, 18 Aug 2017, Jonathan Nieder wrote: > > > Mike Hommey wrote[1]: > > > On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote: > > >> Mike Hommey wrote: &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

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

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] 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: [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.

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

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

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 >

[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: [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,

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

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: 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: [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 > &

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

[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

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

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

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

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

Sorry, I forgot the v2 in the subject. Mike

[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

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

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/

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

[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

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

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

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

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

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

[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

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

[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

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

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

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

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

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.

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 >

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

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

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

Re: What's cooking in git.git (Jun 2016, #04; Tue, 14)

On Wed, Jun 15, 2016 at 11:32:39AM -0700, Junio C Hamano wrote: > Mike Hommey <m...@glandium.org> writes: > > > On Tue, Jun 14, 2016 at 03:08:04PM -0700, Junio C Hamano wrote: > > >> * mh/connect (2016-06-06) 10 commits > >> - connect: [host:port] is

Re: What's cooking in git.git (Jun 2016, #04; Tue, 14)

On Tue, Jun 14, 2016 at 03:08:04PM -0700, Junio C Hamano wrote: > Here are the topics that have been cooking. Commits prefixed with > '-' are only in 'pu' (proposed updates) while commits prefixed with > '+' are in 'next'. The ones marked with '.' do not appear in any of > the integration

Re: [PATCH v2 4/4] bundle v3: the beginning

On Tue, Jun 07, 2016 at 10:46:07AM +0200, Christian Couder wrote: > The high level overview of the patch series I would like to send > really soon now could go like this: > > --- > Git can store its objects only in the form of loose objects in > separate files or packed objects in a pack file. >

Re: What's cooking in git.git (Jun 2016, #02; Mon, 6)

On Mon, Jun 06, 2016 at 10:58:44PM -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 (Jun 2016, #01; Thu, 2)

On Sat, Jun 04, 2016 at 04:51:28PM +0200, Torsten Bögershausen wrote: > On 2016-06-04 07.14, Mike Hommey wrote: > > On Fri, Jun 03, 2016 at 04:47:33PM -0700, Junio C Hamano wrote: > >> Mike Hommey <m...@glandium.org> writes: > >> > >>> In

Re: What's cooking in git.git (Jun 2016, #01; Thu, 2)

On Fri, Jun 03, 2016 at 04:47:33PM -0700, Junio C Hamano wrote: > Mike Hommey <m...@glandium.org> writes: > > > In fact, the parser doesn't even reject the one that is considered > > invalid (the first). > > My question was what the desired behaviour is, and if your

Re: What's cooking in git.git (Jun 2016, #01; Thu, 2)

On Fri, Jun 03, 2016 at 08:59:46AM -0700, Junio C Hamano wrote: > Torsten Bögershausen writes: > > > There where 2 comments in the review. > > The most important thing is that now > > git://[example.com:123]/path/to/repo is valid, but it shouldn't. > > This patch fixes it: > > > >

Re: What's cooking in git.git (Jun 2016, #01; Thu, 2)

On Thu, Jun 02, 2016 at 03:52:41PM -0700, Junio C Hamano wrote: > * mh/connect (2016-06-01) 9 commits > - connect: move ssh command line preparation to a separate function > - connect: actively reject git:// urls with a user part > - connect: change the --diag-url output to separate user and

Re: [PATCH 2/2] strbuf: allow to use preallocated memory

On Tue, May 31, 2016 at 12:46:23AM +0200, William Duclot wrote: > Mike Hommey <m...@glandium.org> writes: > >> struct strbuf { > >> + unsigned int flags; > >>size_t alloc; > >>size_t len; > >>char *buf; > >> }; &

Re: [PATCH 2/2] strbuf: allow to use preallocated memory

> struct strbuf { > + unsigned int flags; > size_t alloc; > size_t len; > char *buf; > }; Depending whether the size of strbuf matters, it /might/ be worth considering some packing here. malloc() usually returns buffers that can contain more data than what is requested.

Re: [PATCH v8 0/9] connect: various cleanups

On Sat, May 28, 2016 at 10:17:19AM +0200, Torsten Bögershausen wrote: > On 28.05.16 07:33, Mike Hommey wrote: > > On Sat, May 28, 2016 at 07:02:01AM +0200, Torsten Bögershausen wrote: > >> On 27.05.16 23:59, Mike Hommey wrote: > >>> On Fri, May 27, 2016 at 04:24:20

Re: [PATCH v8 0/9] connect: various cleanups

On Sat, May 28, 2016 at 07:02:01AM +0200, Torsten Bögershausen wrote: > On 27.05.16 23:59, Mike Hommey wrote: > > On Fri, May 27, 2016 at 04:24:20PM +0200, Torsten Bögershausen wrote: > >> On 27.05.16 04:27, Mike Hommey wrote: > >>> Changes from v7: > >>>

Re: [PATCH v8 0/9] connect: various cleanups

On Fri, May 27, 2016 at 04:24:20PM +0200, Torsten Bögershausen wrote: > On 27.05.16 04:27, Mike Hommey wrote: > > Changes from v7: > > - Fixed comments. > > > > Mike Hommey (9): > > connect: document why we sometimes call get_port after > >

Re: [PATCH] add: add --chmod=+x / --chmod=-x options

On Thu, May 26, 2016 at 11:41:12PM -0500, Edward Thomson wrote: > On Wed, May 25, 2016 at 12:36:55AM -0700, Junio C Hamano wrote: > > > > At the design level, I have a few comments. > > Thanks, I will submit a new patch that incorporates your (and dscho's) > comments. > > > * This is about a

[PATCH v8 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 0819c25..0c4d23b 100644 --- a/connect.c +++ b/connect.c @@ -714,10

[PATCH v8 1/9] connect: document why we sometimes call get_port after get_host_and_port

Signed-off-by: Mike Hommey <m...@glandium.org> --- connect.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/connect.c b/connect.c index c53f3f1..6e520c3 100644 --- a/connect.c +++ b/connect.c @@ -742,6 +742,13 @@ struct child_process *git_connect(int fd[2], const char

[PATCH v8 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 v8 0/9] connect: various cleanups

Changes from v7: - Fixed comments. Mike Hommey (9): connect: document why we sometimes call get_port after get_host_and_port connect: call get_host_and_port() earlier connect: re-derive a host:port string from the separate host and port variables connect: make parse_connect_url

[PATCH v8 4/9] connect: make parse_connect_url() return separated host and port

the "user@" part of the host, in order to pick the port properly. Signed-off-by: Mike Hommey <m...@glandium.org> --- connect.c | 47 --- t/t5500-fetch-pack.sh | 32 +--- 2 files changed, 49 insertions

[PATCH v8 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 9aea3cd..076ae09 100644 --- a/connect.c +++ b/connect.c @@ -684,6 +

[PATCH v8 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 v8 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 | 54 -- 1 file changed, 36 insertions(+), 18 deletions(-) diff --git a/connect.c b/connect.c index 4be06f4..0819c25 100644 --- a/connect.c +++ b/connect.c @@ -588,11 +

[PATCH v8 2/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 v8 3/9] connect: re-derive a host:port string from the separate host and port variables

-derive one from the host and port variables. This will allow to refactor parse_connect_url() to return separate host and port strings. Signed-off-by: Mike Hommey <m...@glandium.org> --- connect.c | 31 +++ 1 file changed, 23 insertions(+), 8 deletions(-) diff

Re: [PATCH v4 2/2] rev-parse: fix some options when executed from subpath of main tree

On Thu, May 26, 2016 at 07:19:16AM -0400, Michael Rappazzo wrote: > Executing `git-rev-parse` with `--git-common-dir`, `--git-path `, > or `--shared-index-path` from the root of the main worktree results in > a relative path to the git dir. > > When executed from a subdirectory of the main tree,

  1   2   3   4   >