Re: Regarding "git log" on "git series" metadata

On Fri, Nov 4, 2016 at 10:57 AM, Junio C Hamano [off-list ref] wrote:

I think this is backwards.  The root cause of the issue you have
with "gitk" is because you added something that is *NOT* a parent to
your commit.  We shouldn't have to add a mechanism to filter
something that shouldn't have been added there in the first place.

I am wondering if an alternative approach would work better.

Imagine we invent a new tree entry type, "gitref", that is similar
to "gitlink" in that it can record a commit object name in a tree,
but unlike "gitlink" it does imply reachability.  And you do not add
phony parents to your commit object.  A tree that has "gitref"s in
it is about annotating the commits in the same repository (e.g. the
tree references two commits, "base" and "tip", to point into a slice
of the main history).  And it is perfectly sensible for such a
pointer to imply reachability---after all it serves different
purposes from "gitlink".

I agree with your assessment here. The main difficulty in implementing
gitrefs is to ensure that they actually do get picked up by
reachability checks to prevent dropping commits. I'm not sure how easy
this is, but I would much rather we go this route rather than
continuing along with the hack. This seems like the ideal solution,
since it solves the entire problem and doesn't need more hacks bolted
on.

It would of course mean some work for people who previously used git
series as you would want to re-write the commits to drop the parent
links and become gitrefs instead of gitlinks. However, this can
(probably?) be solved by some sort of use of the filter-branch code.

I don't think you've hit upon any trivially obvious unworkable things.
It is probably somewhat complex to make the reachability checks detect
in-tree gitrefs but I don't think it would be impossible.

Thanks,
Jake