<div dir="ltr"><div dir="ltr">On Thu, Dec 19, 2019 at 10:38 AM Frank Shearar <<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Chris wants a clean history with _meaningful_ chunks of changes.<div>Other people want commits to be discrete/isolated changes, where "fixing typos" is one kind of change. (*)</div></div></blockquote><div><br></div><div>I want that too, just not micro-sized singles.  **There's plenty to do** in every package, please include a couple more non-critical typo's, categorizations, comments, or obvious bug-fixes, and submit it as a "fix pack".  The contents should be more significant than the packaging that wraps it, not less.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Everyone wants an efficient version control system.</div><div><br></div><div>Also: code is easy to change, while people are very hard to change.</div><div><br></div><div>Wikis have handled this for decades with a "minor edit" flag. (PhpWiki certainly had it in the last century.)</div><div><br></div><div>If Monticello commits had such a concept, Chris could say "please don't show me dust" and other reviewers could demand "separate out the typo fixes from the interesting changes". I'm sure there are interesting technical discussions to be had, but my meta-point is this: quit arguing about process and invest in the tools and everyone can get what they want.</div></div></blockquote><div><br></div><div>Interesting.  Something like that could be helpful.  Maybe even, "fix" or "feature", that way it's less </div><div><br></div><div> - Chris</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>frank</div><div><br></div><div>(*) 

I'm in this camp: refactors, behaviour changes, typo fixes should be in separate chunks, because I spend too much time reviewing code. At work I have the privilege of rejecting commits that don't meet these rules, and I'm not shy in using that privilege. And I encourage my staff to do the same.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 19 Dec 2019 at 02:56, Tobias Pape <<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Christian<br>
<br>
> On 18.12.2019, at 22:58, Christian Kellermann <<a href="mailto:ckeen@pestilenz.org" target="_blank">ckeen@pestilenz.org</a>> wrote:<br>
><br>
> * Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>> [191218 22:45]:<br>
>> Please don't put this dust into the trunk ancestry.  Does anyone have<br>
>> anything else for the PreferencesBrowser they could include this with..?<br>
><br>
> I am sorry, how should I deal with these mini things in the future?<br>
<br>
Like you did. I think it's a perfectly valid commit. :)<br>
<br>
Best regards<br>
        -Tobias<br>
<br>
<br>
</blockquote></div>
<br>
</blockquote></div></div>