3 ms·

I have the opposite reaction, I’m skeptical that the abstract “objections are goals” rule has significant value. But the concrete points about TCR are interesti

I have the opposite reaction, I’m skeptical that the abstract “objections are goals” rule has significant value. But the concrete points about TCR are interesting. To address the objections about fast and trustworthy tests, you could limit its use to code that already has good tests. To address the version history objection, you could use “git commit --amend” to limit it to a single commit. So in some situations TCR may actually be usable (and in fact it’s not too far away from the process I often use! Frequent small commits with --amend)

mlthoughts2018 8y ago
I envy your ability to use that workflow. Across three enterprise jobs over the last 7 years, all places using git and GitHub, I’ve never worked on any sections of code where this could be tractable, except maybe for the process of using —amend in some rare cases where we wouldn’t want this history of those commits to be well separated for later purposes of bisecting to find regressions and bugs.
- iainmerrick 8y ago
  This is not something I’d do on master, of course -- just on my own branch while working on stuff that will eventually become a single PR. I like to curate my commit(s) as I go, so that the final PR is easy to understand.
  - mlthoughts2018 8y ago
    Oh, I see. Yes, that is a very standard workflow. I also commonly address PR change requests in isolated commits as well, and then link back in the PR review page with something like “fixed in <commit hash>”, so that reviewers can see isolated commit changes fixing itemized requests, and also so that no review comments ever go without some explicit reply, either demonstrating the fix or explain why to not do it or table it for later. I guess in this sense, these items don’t have much to do with whether the big conjunction of conditions necessary for TCR are satisfied or not.

mlthoughts2018 8y ago

I envy your ability to use that workflow. Across three enterprise jobs over the last 7 years, all places using git and GitHub, I’ve never worked on any sections of code where this could be tractable, except maybe for the process of using —amend in some rare cases where we wouldn’t want this history of those commits to be well separated for later purposes of bisecting to find regressions and bugs.

iainmerrick 8y ago
This is not something I’d do on master, of course -- just on my own branch while working on stuff that will eventually become a single PR. I like to curate my commit(s) as I go, so that the final PR is easy to understand.
- mlthoughts2018 8y ago
  Oh, I see. Yes, that is a very standard workflow. I also commonly address PR change requests in isolated commits as well, and then link back in the PR review page with something like “fixed in <commit hash>”, so that reviewers can see isolated commit changes fixing itemized requests, and also so that no review comments ever go without some explicit reply, either demonstrating the fix or explain why to not do it or table it for later. I guess in this sense, these items don’t have much to do with whether the big conjunction of conditions necessary for TCR are satisfied or not.