On 1/18/21 11:06 AM, Aiyee Bee wrote: > Hello everybody! > > I want to implement a feature in git, and I'm looking for some help. > > I wanted to add a history-simplification option to rev-list so that it > doesn't simplify away any irrelevant commits if they have multiple > relevant _children_, i.e. when they are the point where two relevant > histories diverge. I'm actually working on something that does the opposite---it ignores the fork point when drawing the graph. (I'm currently dog-fooding a partial implementation of this.) > Basically the effect I want for --show-forkpoints (named like --show-pulls): > http://ix.io/2Ms6 > > But it seems there is no existing apparatus in the revision walker for > deciding simplification on basis of *children*, am I correct? Admittedly > my understanding of it is still a WIP, but I don't see anything that > could help. It's even worse than this. AFAICT, there are two code paths: one for when the git-commit-graph is enabled, and one when it is not. There's a special "revs->limited" option which lets you deal with the commits all at once, at the expense of losing all the speed improvements from the git-commit-graph efforts. Aside: I want to get rid of that alternative path. But I only have limited time. > I was hoping that simply the flag CHILD_SHOWN could be checked, but it > seems that's only set on boundary commits :( > > This option would be pretty useful when used with some diffs, to see how > much two forks have diverged. Currently if you use history simplification, > the diffs for both divergent histories will be created against the last > relevant commit instead of the last common ancestor, which creates pretty > useless diffs with a lot of intersection between them. Sounds neat! > Are there any viable alternative means to do this that I can explore? I too would like to hear about suggestions for this. > > Thanks! > > FriendlyNeighborhoodShane >
