On Fri, Nov 4, 2016 at 10:57 AM, Junio C Hamano <gitster@xxxxxxxxx> 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