accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [ATTN] Cleaning up extra refs in git
Date Fri, 04 Mar 2016 21:45:09 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message