On Thu, Jun 12, 2008 at 09:14:21AM +0200, Johan Herland wrote:

quoted text
> > The grafts file isn't part of the object stream and refs, and clones (and
> > fetches) very much just copy the object database.
> 
> AFAICS, there's already a perfectly fine way to distribute grafted history:
> 1. Add a grafts file
> 2. Run git-filter-branch
> 3. Remove grafts file
> 4. Distribute repo
> 5. Profit!
> 
> Since git-filter-branch turns grafted parentage into _real_ parentage,
> there's no point in ever having a grafts file at all (except transiently
> for telling git-filter-branch what to do).

But then you have rewritten all of the later commits, so you can no
longer talk to other people about them.

The kernel repo is split into "historical" and active repos. You can
graft the historical repo and get more far-reaching answers to things
like "git log" and "git blame". But if you run filter-branch, you can't
share development on that repo via push / pull to people who _don't_ use
the graft, since they don't share your history (and they probably don't
want to, because of the extra resources required to pull in the
historical chunk).

That being said, I don't know how common such a setup is. And you did
mention a "follow-grafts" config option for such people.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html