Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> On Sat, 9 Feb 2008, Nicolas Pitre wrote:
>
> > I, too, have some reservations about adding any kind of generation
> > header to commit objects. First because it can be generated and
> > maintained locally, just like the pack index. But also because its
> > usefulness has not been proven in all possible graph topologies, and
> > adding it to the commit header pretty much deny any further
> > modifications/improvements on it, if for example some other kind of
> > generation notation becomes advantageous to use.
>
> I fully agree.
I think I'd agree, also because without 'generation' (and 'roots')
commit object header being there from beginning it is not clear when
to calculate it: the first few commits with it would be costly.
Besides graft and shallow information is local, and it affect commit
traversal.
I was thinking about pack-index like file, either directly mapping
"sha1 -> generation + roots", or indirectly "sha1 -> offset",
"offset -> generation + roots".
P.S. Would having generation + roots be enough?
gen(rev) = max_i { gen(i) + 1 : i in parents(rev) } || 1
roots(rev) = { rev if rev is a root (parentless) commit
{ union of roots of parents of a commit otherwise
Union in the sense of set sum.
Note that if roots was to be saved in commit header, then it couldn't
be as simple as commit-id for root commits: no self links. It would
have to be empty for root commits, and the "union of roots" would have
to be modified to "union of roots or commit ids for root commits, of
each of parents of a commit".
--
Jakub Narebski
Poland
ShadeHawk on #git
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
