Ævar Arnfjörð Bjarmason wrote: > I'm a bit surprised at what seems to be some hostility or annoyance that > I submitted this as a set of patches. That's ultimately something that > saves everyone involved time (well, except me by coming up with said > patches). To borrow some words: > > "Talk is cheap. Show me the code." ― Linus Torvalds. Words I live by. > If I give you feedback suggesting that maybe we should reorganize this > thing to split out refactorings from behavior changes I'm asking you to > do extra work. Ultimately neither I, you nor anyone else can really know > if such a proposed effort is going to be better until it happens. Indeed. That's why a lot of time instead of simply replying to a mail with an idea, I actually attempt to code the idea, and only then send te reply. I would say 90% of the time what I originally thought changes once I actually try to implement it. > It's can be really hard to see how/where to split things when you're the > author of the code. It's really hard in the "theory of mind" sense of > things to explain an idea to someone who doesn't have the information > you have. More like impossible. No comic simply writes an act and goes to an auditorium like Carnegie Hall to simply present it knowing full well how people are going to react to it. You never really know how other people are going to react, so it's better to not make assumptions, just try and find out. > I think I've made a good argument above for why this takes you a step > forward, not backwards, I'm hoping despite this initial reply that > you'll come to agree on that. Not to mention that the goal is not to land Emily's patches, the goal is to improve the code while minimizing the potential breakage. For that we need as many eyes as possible, and in my opinion your reorganization patches totally help in that regard. The fact that this makes it easier to land Emily's patches is an added benefit. > In any case, writing code is hard, but splitting it up like I've done > here is rather easily done. It took me about a day with waiting for > "rebase -i --exec='make test'" equivalent, and that's from being mostly > unfamiliar with the code in question beforehand. It's easy if you are an expert at rebasing, which not many people are. But you can't become an expert if you don't do it, over and over. So it's usually better to not think too much about it and simply do it. Cheers. -- Felipe Contreras
