Re: Bug#813084: Background git gc fails, telling me to run git prune, which doesn't help
Control: forwarded -1 git@vger.kernel.org On Fri, 2016-01-29 at 21:05 +0700, Duy Nguyen wrote: > On Fri, Jan 29, 2016 at 8:35 PM, Ben Hutchings <b...@decadent.org.uk> wrote: > > git keeps trying to do a background gc on my linux repository, but > > fails, reporting this in .git/gc.log: > > > > warning: There are too many unreachable loose objects; run 'git prune' to > > remove them. > > > > However, after running 'git prune' and 'git gc' (which succeeds), git > > soon tries to a background gc again, resulting in the same error. > > > > Let me know what I can do to get any further diagnostic information. > > Make sure nobody is accessing the repository before you do this: > > git prune --expire=now > > Then you can try "git gc --auto" again to see if it is still > complaining. Report back on git@vger.kernel.org in that case. OK, I've now done that and I get the same failure. But 'git gc --prune=all' seems to work: $ git gc --prune=all Counting objects: 6479254, done. Delta compression using up to 4 threads. Compressing objects: 100% (939232/939232), done. Writing objects: 100% (6479254/6479254), done. Total 6479254 (delta 5503044), reused 6479254 (delta 5503044) Checking connectivity: 6479254, done. I kept a backup of the .git directory so I can run further experiments on that. Ben. -- Ben Hutchings Every program is either trivial or else contains at least one bug signature.asc Description: This is a digitally signed message part
Re: How to request a fast-forward pull
On Tue, 2012-08-21 at 10:22 -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: On Mon, Aug 20, 2012 at 01:40:33PM -0700, Jonathan Nieder wrote: When you have a moment, would you please migrate this across to your main linux-stable repository? Both a branch and signed tag are present and pointing at the same commit, but git request-pull does favour output of the tag over the branch name. But merging the tag will want to create a merge commit. So, to avoid a merge commit in your repo, you can fetch (fast fwd) into your (local) branch from my branch at: git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-stable.git linux-2.6.34.y and then fetch the signed tag listed below after that. Can this be made easier? I could imagine request-pull learning --ff-only that generates a message like Greg, Please pull --ff-only Where did the Greg,\n\n come from? Isn't it just the matter of adding the --ff-only when that string is added? git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-stable.git linux-2.6.34.y to get the following changes [...] which could work ok if the recipient notices the --ff-only, but I wonder if there is a simpler way. If it is something important for the sender to communicate to the recipient as part of the pull command-line, then I would think the natural place is on the line with the rest of it, like: Please pull: --ff-only remote ref It's maximally noticeable to the recipient, then, and anybody cutting-and-pasting the whole line would get it automagically. That is as close to machine-readable as pull-request emails get. However, I have to wonder if that is a good idea in general. Isn't the decision to --ff-only or not really the puller's business? In the general case, I would not expect senders of pull request to have advice in this area. Yes, absolutely. The advice of the sender that would be more helpful is not how, but where/when. Is the topic meant for the maintenance track? Why is it appropriate to pull this series at this moment in the history of the overall project? This particular case seems to be caused by a policy mismatch between the project and request-pull. The latter's behavior to favor a matching tag is because tags carry more information. But in this case, it sounds like the project would rather avoid the extra merge commits, even if it means losing information. That's a project decision and can be done by whoever is pulling, as you mentioned earlier. In any case, why is this even become an issue in the context of linux-stable? I thought people over there were working hard to *increase* verifiability of the history by using signed merges, [...] Each *stable update* series is a single branch made up almost entirely of cherry-picked commits, possibly managed as a quilt series before being reviewed and then committed. Tags are signed, and each commit has a reference to the original (though the format of that reference isn't well standardised). Although Greg owns the linux-stable.git repository, several stable updates series and the corresponding branches are maintained by others, such as Paul and myself. When Greg pulls from them, he's mirroring the other maintainer's branch and never merging with anyone else's work. So it should always be a fast-forward merge. Further, the head of the branch is always going to have a tag signed by the respective maintainer. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Surprising tag selection by 'git describe --contains'
On Fri, 2012-08-17 at 06:22 -0700, Greg KH wrote: On Fri, Aug 17, 2012 at 09:18:44AM +0200, Daniel Vetter wrote: On Fri, Aug 17, 2012 at 1:18 AM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Aug 14, 2012 at 01:50:11AM -0400, Gregs git-bot wrote: commit: 5ab3633d6907018b0b830a720e877c3884d679c3 From: Hunt Xu mhun...@gmail.com Date: Sun, 1 Jul 2012 03:45:07 + Subject: drm/i915: make rc6 in sysfs functions conditional Commit 0136db586c028f71e7cc21cc183064ff0d5919c8 merges rc6 information into the power group. However, when compiled with CONFIG_PM not set, modprobing i915 would taint since power_group_name is defined as NULL. This patch makes these rc6 in sysfs functions conditional upon the definition of the CONFIG_PM macro to avoid the above-mentioned problem. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45181 Cc: sta...@vger.kernel.org Tested-by: Kris Karas bugs-...@moonlit-rail.com Signed-off-by: Hunt Xu mhun...@gmail.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_sysfs.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) As commit 0136db586c028f71e7cc21cc183064ff0d5919c8 only first showed up in 3.6-rc1, is this patch still needed for the stable tree(s)? My git tag --contains claims it's in 3.5 already. Really? $ git describe --contains 0136db586c028f71e7cc21cc183064ff0d5919c8 v3.6-rc1~59^2~56^2~76 Do you see something else? 'git describe --contains' seems to choose the containing tag whose tree has the shortest path from the given tree-like. So, when some branch has relatively few changes after Linus pulls it for release N and before he pulls it for release N+1 *and* he pulls it later in the merge window for release N+1, commits include in v3.N-rc1 can still be closer to v3.(N+1)-rc1 because the extra merge commits on the path to v3.N-rc1 outweigh the extra non-merge commits on the path to v3.(N+1)-rc1. git certainly doesn't (and shouldn't) know anything about ordering of tag names, but I think that if one of the containing tags is the ancestor of all the others then 'git describe --contains' should prefer to use that. Or at least, there should be some way to request that behaviour. For now, if in doubt, 'git tag --contains' will tell you all the containing tags. Ben. And people have reported the regressions to prove it ;-) Ok, fair enough, I'll apply it. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure. signature.asc Description: This is a digitally signed message part
