ithout the tree that refers to it, we
would not know that the blob is relevant to our walk.
2. We do not need to test a tip commit that is missing.
Upload-pack omits these for us (and in fact, we
complain even in the non-bitmap case if it fails to do
so).
Reported-by: Si
On 03/26/2014 03:40 PM, Siddharth Agarwal wrote:
On 03/26/2014 12:22 AM, Jeff King wrote:
[tl;dr the patch is the same as before, but there is a script to measure
its effects; please try it out on your repos]
Here are the numbers from another, much larger repo:
Test
On 03/26/2014 12:22 AM, Jeff King wrote:
[tl;dr the patch is the same as before, but there is a script to measure
its effects; please try it out on your repos]
Here are results from one of our repos:
Test origin HEAD
-
Hi,
We're still experimenting with bitmaps, and we've have run into issues
where fetching from a repository with bitmaps enabled can lead to
objects that used to be present on the server but have since been GC'd
being accessed, and git pack-objects on the server failing because of that.
I ca
On 03/22/2014 05:56 AM, Jeff King wrote:
On Fri, Mar 21, 2014 at 07:58:55PM -0700, Siddharth Agarwal wrote:
Is it also reproducible just with the tip of "next"? Note that the
patches in jk/bitmap-reuse-delta have not been widely deployed (in
particular, we are not yet using them at G
Hi all,
At Facebook we've found that fetch speed is a bottleneck for our Git
repos, so we've been looking to deploy bitmaps to speed up fetches.
We've been trying out git-next with the top two patches from
https://github.com/peff/git/commits/jk/bitmap-reuse-delta, but the
following is reprodu
On 01/23/2014 06:28 PM, Jeff King wrote:
I think your understanding is accurate here. So we want repack to
respect keep files for deletion, but we _not_ necessarily want
pack-objects to avoid packing an object just because it's in a pack
marked by .keep (see my other email).
Yes, that makes sen
On 01/23/2014 03:45 PM, Siddharth Agarwal wrote:
The worry is less certain objects not being packed and more the old
packs being deleted by git repack, isn't it? From the man page for
git-index-pack:
This should probably be "new pack" and not "old packs", I guess
On 01/23/2014 02:52 PM, Jeff King wrote:
Right, that's expected.
The bitmap format cannot represent objects that are not present in the
pack. So we cannot write a bitmap index if any object reachable from a
packed commit is omitted from the pack.
We could be nicer and downgrade it to a warning,
On 01/22/2014 06:38 PM, Siddharth Agarwal wrote:
In our case we have .keep files lying around from ages ago (possibly
due to kill -9s run on the server). It also means that running repack
-a with bitmap writing enabled on a repo becomes problematic if a
fetch is run concurrently.
We briefly
Running git-next, writing bitmap indexes fails if a keep file is present
from an earlier pack.
With git at b139ac2, the following commands demonstrate the problem:
git init test
cd test
touch a
git add a
git commit -m "a"
git repack -ad # generate a pack file
for f in .git/objects/pack/*.pack
With git-next, the --max-pack-size option to git repack doesn't work.
With git at b139ac2, `git repack --max-pack-size=1g` says
error: option `max-pack-size' expects a numerical value
while `git repack --max-pack-size=1073741824` says
error: unknown option `max_pack_size=1073741824'
I bisecte
On 01/17/2014 12:40 AM, John Keeping wrote:
On Thu, Jan 16, 2014 at 06:47:38PM -0800, Siddharth Agarwal wrote:
On 01/16/2014 06:21 PM, Jeff King wrote:
On Thu, Jan 16, 2014 at 05:08:14PM -0800, Siddharth Agarwal wrote:
With git-next, where git pull --rebase can print out "fatal: No suc
On 01/16/2014 06:21 PM, Jeff King wrote:
On Thu, Jan 16, 2014 at 05:08:14PM -0800, Siddharth Agarwal wrote:
With git-next, where git pull --rebase can print out "fatal: No such
ref: ''" if git pull --rebase is run on branches without an upstream.
This is already fixed in
With git-next, where git pull --rebase can print out "fatal: No such
ref: ''" if git pull --rebase is run on branches without an upstream.
With git at b139ac2589b15d55cd9fa5c6957da44b150d0737, the following
commands demonstrate the problem:
git init repo1
cd repo1
touch a; git add a; git comm
15 matches
Mail list logo
