On Tue, Dec 26, 2017 at 03:19:02PM -0500, Paul Smith wrote: > 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. In the near term, maybe. I'm still working with it to be sure I understand it right. > 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. You've touched on some of my concerns with the null-merge approach. I want the end result to be as clean as possible which I think is what lures many to the rebase methodology in the first place. > 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. Exactly! Carl
