Coda File System

Re: patches/merging

From: Jan Harkes <>
Date: Thu, 17 Jul 2014 15:23:31 -0400
On Thu, Jul 17, 2014 at 07:46:57AM -0400, Greg Troxel wrote:
> Jan Harkes <> writes:
> > The only question is what to do for tagging in the development tree. I
> > assume we just tag the whole tree when a new distribution tarball is
> > created so the git checkout of the source tree will match lwp-2.6 in the
> > lib-src/lwp subtree but isn't guaranteed to match anything sane in the
> > rest of the tree (except that you can assume that a developer most
> > likely has compiled them at the same time.
> You are saying "the development tree", which I don't follow.  Surely
> when releasing 2.6 of lwp then the lwp repo gets a tag, since it is
> primarily an independent project.

Git tags are associated with the commit object, which in turn points a
the tree. So the development tree would consist of the whole of
coda/lwp/rpc2/rvm at the point in time that the tag is created.

> So it might be that coda.git is the independent version, and there's a
> coda-meta.git that pulls all of them in as submodules.  That seems much
> cleaner.

Well, except that I'm trying to get away from using submodules. But it
may be moot because I just seem to hit problems in reposurgeon and the
git filter branch history rewriting afaik doesn't do what I would like.

> CVS is just messy, especially long-ago usage.

Yes, I've mostly given up on trying to fix that except for the low
hanging fruit cases. At least operations like git blame can give some
idea of approximately when/why particular changes were made, it is
unlikely that a checkout of early versions will actually return a
tree that can be compiled without changes.

> > ALso, the current git repositories actually have a much better history
> > because they track author information and actual commit times, the
> > recent CVS history only track the time when the git development tree
> > got synced back with CVS.
> I wonder if there is an easy way to merge the two histories, basically
> converting until a date and then exporting all the commits from the git
> repo and then replaying them.  That might not be that hard.

I have done that before with grafts and filter-branch, I do not remember
it as being too terribly hard.

Received on 2014-07-17 15:23:40