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
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 bb3f458 (rebase: fix
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 such
ref
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
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
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. Not
knowing much about how
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
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
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 GitHub, and we
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
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
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
-by: Siddharth Agarwal s...@fb.com
Signed-off-by: Vicent Marti tan...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
I believe this should solve the problem you're seeing, and I think any
solution is going to be along these lines.
This covers all code paths that can be triggered by pack-objects
13 matches
Mail list logo
