Hi Junio, On Sun, 10 Mar 2019, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > If you care deeply about the commit history, I hereby offer to you to > > clean up the built-in stash patches when you say you're ready to advance > > them to `master`. > > What's the goal of such a rebase? To appease you enough that you stop complaining about the current, or previous, state of `ps/stash-in-c`. I am genuinely interested in making this all more pleasant for you, even if my efforts to that end show no fruit. > To rebuild the topic as a sensible sequence of commits that logically > builds on top of previous steps to ease later bisection and > understanding? > > Thanks for an offer out of good intentions,, but let's move on and > polish the tree shape at the tip of this topic. I would be prepared to do that, but I am constantly reminded of the unfortunate way we handled `ps/stash-in-c`, where you thought it was way too early to move to `next`, and I am convinced that we simply were way too late to start cooking in `next`. So I keep offering to do work so that you would be happier, but none of my suggestions seem to work. > The history behind it may be messier than other segments of our history, > and future developers may have harder time learning the intention of the > topic when making changes on top, but this one was supposed to create a > bug-to-bug reimplementation of the scripted version. Right. But we moved right past that, and continued enhancing `git stash`, (like the `--quiet` thing) and were now stuck with the unfortunate situation that we had to do it in both built-in and scripted version. > What matters more would be our future changes on top of this code, which > improves what we used to have as scripted Porcelain. They will > genuinely be novel efforts, need to be built in logical order and > explainable steps to help future developers. Compared to that, so the > history of our stumbling along the way to reach today's tip of the topic > has much lower value. > > Besides I think it is way too late for the current topic. We > established before the topic hit 'next' that reviewers' eyes all > lost freshness and patience to review another round of this series > adequately. > > We at least know that the ordering and organization of the iteration > we see in 'next' is crappy, because some reviewers did look at them. > The rewrite will see no reviews, if any, far fewer and shallower > reviews than the iteration we have; nobody would be able to say with > confidence that the rewritten series achieves its goal of leaving a > sensible history. Doing so just before it hits 'master' makes it a > sure thing. Fine. But in that case, I would appreciate not being reminded of the messiness. Not unless you let me do something about it. Don't put me between a rock and a hard place, please. > Let's just we all admit that we did a poor job when we decided to > push this topic to 'next' before it was ready, and learn the lesson > to avoid haste making waste for the future topics. Quite honestly, I am at a loss what you are suggesting here. The original contributor (Paul) got unexpectedly busy with university, so he was not able to take care of any updates. I would have made those updates (I promised, after all), but at some stage it felt more logical to explain in add-on topics what breakages were introduced by the built-in rewrite and fix them: squashing the fixes in would have made it less obvious why certain changes had to be done that way (after all, I missed in the original dozens of reviews, pre-submission and post-submission, e.g. the ORIG_HEAD problems). But you did not complain about me adding on top back then, so I do not understand why you complain about it now... I am more than willing to move on, but if we keep repeating how messy the current state is and do not even come up with a way how we could handle this better in the future, then I do not really feel that we *are* moving on after all. Ciao, Dscho > Thanks. >
