accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [ATTN] Cleaning up extra refs in git
Date Fri, 04 Mar 2016 22:11:04 GMT
Thanks for taking the time to clean these up!

Christopher wrote:
> Not much change. After doing 'git gc --aggressive --prune=now' on a 'git
> clone --mirror', the repo size was 33M before the removal of these refs,
> and 27M after. Since they were mostly pointing to existing blobs, I
> wouldn't expect it to have dropped much. I'm actually a bit surprised it
> dropped as much as 6M.
>
> That said, i don't know how frequently ASF does a 'gc', or if git does that
> automatically on the ASF remote, so I don't know if/when the potential for
> a slightly smaller size will benefit anybody.
>
> On Fri, Mar 4, 2016 at 4:32 PM William Slacum<wslacum@gmail.com>  wrote:
>
>> Any stats on what the repo size is after removing the refs and doing
>> something like `git gc`?
>>
>> On Fri, Mar 4, 2016 at 4:25 PM, Christopher<ctubbsii@apache.org>  wrote:
>>
>>> I was able to deleted 135 duplicate refs of the kind I described. Only
>> one
>>> resulted in a new branch being created (ACCUMULO-722). We probably don't
>>> need that at all, but it might be useful to turn into patches to attach
>> to
>>> the "Won't Fix" ticket, rather than preserve them as an inactive branch.
>>>
>>> Also note that the ACCUMULO-722 branch is not rooted on any other
>> branches
>>> in our git repo. It was essentially just a sandbox in svn where Eric had
>>> been working.
>>>
>>> On Wed, Mar 2, 2016 at 6:14 PM Christopher<ctubbsii@apache.org>  wrote:
>>>
>>>> (tl;dr version: I'm going to clean up refs/remotes/** in git, which
>>>> contains duplicate history and messes with 'git clone --mirror'; these
>>> are
>>>> refs which are neither branches nor tags and leftover from git-svn)
>>>>
>>>> So, when we switched from svn to git, there were a lot of leftover refs
>>>> left in the git repository that are from old branches/history which has
>>>> already been merged into the branches/tags that we've since created. I
>>>> think these were leftover from weird git-svn behavior. These can, and
>>>> should, be cleaned up.
>>>>
>>>> You can see all of them when you do a:
>>>> git ls-remote origin
>>>>
>>>> In that output, our current branches are the refs/heads/*, and our tags
>>>> are the refs/tags/*
>>>> The extras which need to be cleaned up are the refs/remotes/*
>> (including
>>>> refs/remotes/tags/*)
>>>>
>>>> As you can see, these are duplicates of branches which have been merged
>>> in
>>>> already, or temporary tags which didn't make it to a release (release
>>>> candidates) but whose relevant history is already in our normal git
>>>> history, or they are branches which were abandoned on purpose
>>>> (ACCUMULO-722).
>>>>
>>>> Usually these extra refs don't present a problem, because we don't
>>>> normally see them when we clone (they aren't branches which are
>> normally
>>>> fetched). However, there are a few cases where this is a problem. In
>>>> particular, they show up when you do "git clone --mirror", and if you
>>> push
>>>> this mirror to another git repository, like a GitLab mirror (git push
>>>> --mirror), they show up as extra branches which don't appear to exist
>> in
>>>> the original (a very confusing situation for a "mirror").
>>>>
>>>> The interesting thing about these, is that even when they have the same
>>>> history as the git branches/tags we maintain now, the SHA1s don't match
>>> up.
>>>> This seems to imply they were leftover from a previous invocation of
>>>> git-svn.
>>>>
>>>> So, what I'd like to do is go through each of these extra refs one by
>>> one,
>>>> and figure out if we already have this history in our branches/tags. If
>>> we
>>>> do, then I'd delete these extras. If we don't (as in the case of
>>>> ACCUMULO-722), I'd just convert that to a normal git branch
>>> (refs/heads/*)
>>>> until we decide what to do with it at some future point in time (for
>>>> example, perhaps do a 'git format-patch' on it and attach the files to
>>> the
>>>> "Won't Fix" ticket so we can delete the dead branch? not sure, but that
>>> can
>>>> be deferred).
>>>>
>

Mime
View raw message