On Tue, 2017-12-26 at 12:44 -0700, Carl Baldwin wrote: > > Sure, it could be opt in, be a new format etc. But you haven't > > explained why you think a feature like this would need to rely on > > an entirely new parent structure and side-DAG, as opposed to just > > the more minor changes I'm pointing out above, and which I think > > will give you what you need from a UX level. > > I have not wrapped my head around it enough to convince myself that > it gives what I'm after. Let me spend a little more time with it to > get a feel for it.
As someone working in an environment where we do a lot of rebasing and very little merging, I read these proposals with interest. I'm not convinced that we would switch to using a "replaces"-type feature, but I'm pretty sure that the "null-merge and rebase" trick described previously would not be something we're interested in using. Although "git log" doesn't follow these merges (unless requested), all the graphical tools that are used to display history WOULD show all those branches. In a "replaces"-type environment I think the point is that we would not want to see them (certainly not by default) as they would be used mainly for deeper spelunking, but since they just seem like normal merges I don't see any way to turn them off. If "replaces" was a separate capability then it could be treated differently by history browsing tools, and shown or not shown as desired. For example, a commit that had a "replaces" element could be selected somehow and you could expand that set of commits that were replaced, or something like that.
