Michael Haggerty mhag...@alum.mit.edu writes:
The lock conflict scenario is the only one that really worries me.
Actually, I'd feel worried if this were on the receive-pack side, as
it is entirely valid that two or more people make uncoordinated push
into a single meeting point, but much less
On 03/19/2015 08:24 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Now that we have ref_transaction_*, I think if git-fetch fed all of the
deletes (along with the updates) into a single transaction, we would get
the same optimization for free. Maybe that is even part
On Thu, Mar 19, 2015 at 03:49:08PM +0100, Michael Haggerty wrote:
For pruning, we can't use a ref_transaction as it is currently
implemented because it would fail if any of the reference deletions
failed. But in this case I think if any deletions fail, we would prefer
to emit a warning but
On 03/06/2015 11:59 PM, Jeff King wrote:
On Fri, Mar 06, 2015 at 05:48:39PM +0100, Ævar Arnfjörð Bjarmason wrote:
The --prune option to fetch added in v1.6.5-8-gf360d84 seems to be
around 20-30x slower than the equivalent operation with git remote
prune. I'm wondering if I'm missing
Michael Haggerty mhag...@alum.mit.edu writes:
Now that we have ref_transaction_*, I think if git-fetch fed all of the
deletes (along with the updates) into a single transaction, we would get
the same optimization for free. Maybe that is even part of some of the
pending ref_transaction work
On Thu, Mar 19, 2015 at 12:24:21PM -0700, Junio C Hamano wrote:
For pruning, we can't use a ref_transaction as it is currently
implemented because it would fail if any of the reference deletions
failed. But in this case I think if any deletions fail, we would prefer
to emit a warning but
On Fri, Mar 06, 2015 at 05:48:39PM +0100, Ævar Arnfjörð Bjarmason wrote:
The --prune option to fetch added in v1.6.5-8-gf360d84 seems to be
around 20-30x slower than the equivalent operation with git remote
prune. I'm wondering if I'm missing something and fetch does something
more, but it
The --prune option to fetch added in v1.6.5-8-gf360d84 seems to be
around 20-30x slower than the equivalent operation with git remote
prune. I'm wondering if I'm missing something and fetch does something
more, but it doesn't seem so.
To test this clone git.git, create 1000 branches it in, create
8 matches
Mail list logo