Re: ignoring extra bitmap file?

On Fri, 18 Aug 2017 02:53:34 +, Jeff King wrote: ... > Whether there's a .bitmap doesn't impact whether .pack and .idx files > are deleted. The next full repack would pack everything into a new big > pack, and then delete any existing files, including .pack, .idx, and > .bitmap. It took a bit

ignoring extra bitmap file?

Hi everyone, I'm seeing the message remote: warning: ignoring extra bitmap file: ./objects/pack/pack-2943dc24pack and indeed, there is such a thing (two, actually): 171736188 Aug 17 08:20 pack-2943dc2477026f87b280ebcefa93fe28412688df.idx 12662268 Aug 17 08:24

git repack leaks disk space on ENOSPC

Hi all, I observed (again) an annoying behavior of 'git repack': When the new pack file cannot be fully written because the disk gets full beforehand, the tmp_pack file isn't deleted, meaning the disk stays full: $ df -h .; git repack -ad; df -h .; ls -lart .git/objects/pack/tmp*; rm

git merge commits staged files (when two trees are identical)

Hi everybody, we just stumbled over a situation in which a merge commits staged changes into the merge commit. This happens when the merged-in branch does have commits ('main') but has the same tree ('--allow-empty') as the merge base: git init echo eins >a git add a git commit

bug: --shallow-since misbehaves on old branch heads

Hi everybody, I think I have discovered a problem with clone/fetch --shallow-since: When a ref that is fetches has a head that is already older than the 'since' time, then the entire branch is fetched, instead of just the current commit. Repro: rm -rf tmp out deep git init tmp for i in

Re: clone, hardlinks, and file modes (and CAP_FOWNER)

On Fri, 24 Aug 2018 16:48:37 +, Ævar Arnfjörð Bjarmason wrote: ... > I don't understand how this hardlink approach would work (doesn't mean > it won't, just that I don't get it). I just detect whether there is insufficient sharing (df is quite handy here; 'df this/.git that/.git' tells the

clone, hardlinks, and file modes (and CAP_FOWNER)

Hi everybody, I'm currently looking into more aggressively sharing space between multiple repositories, and into getting them to share again after one did a repack (which costs us 15G space). One thing I stumbled on is the /proc/sys/fs/protected_hardlinks stuff which disallows hardlinking

Speed of git branch --contains

Hi everybody, I'm just looking at some scripts that do a 'git branch --contains $id --remote' for each new commit in a repo, and unfortunately each invokation already takes four minutes. It feels like git branch does the reachability detection separately for each branch potentially listed. The

git submodule update - reset instead of checkout?

Hi everyone, I've been reading up on the current state of git submodules (our customer's customers want to use them, causing a slight groan from our customer). The usability thing I wonder about - with git submodule update, is it necessary to detach the head to the current (or upstream) head,

Re: Git should preserve modification times at least on request

On Thu, 22 Feb 2018 03:05:35 +, 'Peter Backes' wrote: ... > The bigger issue is usually to copy with those pesky leap seconds. It > makes a difference whether one uses solar seconds ("posix" style; those > are more commonly seen) or atomic seconds ("right" style) for the UNIX > timestamp.

approxidate woes

Hi everybody, I've now located why our backup repo shrinks every month: git gc --prune=2d doesn't do what I expected, and differs a lot from --prune=48h. The latter actually means 'older than two days', while the former is 'since the second day of this month, same time as now'. Even '2d

<    1   2