<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 24 June 2016 at 10:06, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Holger,<br>
<span class=""><br>
<br>
> On Jun 20, 2016, at 1:24 AM, Holger Freyther <<a href="mailto:holger@freyther.de">holger@freyther.de</a>> wrote:<br>
><br>
><br>
><br>
>> On 20 Jun 2016, at 09:53, Norbert Hartl <<a href="mailto:norbert@hartl.name">norbert@hartl.name</a>> wrote:<br>
>><br>
>><br>
>><br>
>> A commit is associated with a comment. So commits should be rather small and describing the change. Most of the time there are some changes/commits that only make sense when being together. This would be the view from the build server or from the process of having buildable artifacts all the time. So you can see it as freedom to have a commit that breaks the software which can be build after 5 more commits. So no problem for the world if you push 5 commits at once.<br>
><br>
> This approach breaks tools like git bisect. If a user has something easy/quick to reproduce and a "good" version and "bad" one, he/she can identify the first broken commit almost automatically. If commits are small then it is quite easy for the maintainer to identify the issue and resolve it.<br></span></blockquote><div><br></div><div>That's true only for commits _on master_, right? (More accurately, IIUC git bisect will binary search over a chain of commits. If a merged-into-master feature branch has a commit that doesn't compile, git bisect will not even see that commit; it will walk over the merge commit, marking it good/bad.</div><div><br></div><div>frank</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Projects like Linux have the policy that each single commit needs to compile and for my GPRS/EDGE PCU[1] we have the same policy and I can point to a recent example of git bisect used by a user[2]. As a maintainer this reduces the work I have to do.<br>
><br>
> In the context of spur there is a significant performance regression of our TCAP benchmark from one spur version to another and with git bisect I could do:<br>
><br>
> git bisect start<br>
> git bisect good <SHA1 of better VM><br>
> git bisect bad <SHA1 of first bad VM><br>
><br>
> and then commits from good to bad will be picked and all I need to do is:<br>
><br>
> make<br>
> bench<br>
><br>
> and then decide to mark this commit as:<br>
><br>
> git bisect bad<br>
> git bisect good<br>
><br>
> and eventually end with the first bad commit (or none if I track noise)<br>
><br>
><br>
> It is obviously up to the maintainers if they want to support git bisect but thanks to git it is not really a burden. One can experiment with temporary branches and then rebase to a final and working patchset. With later git versions can be easily automated as well.<br>
<br>
</span>I think this is a very sensible policy and that we should support bisect. Do you have energy to work with Tim F to update CONTRIBUTING.md to include this policy? Are there ways of enforcing or advising the policy when using git tools or is it simply something we have to tell users? This latter approach is terribly fragile.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> git rebase -i --execute "./compile_and_test_all.sh" origin/master<br>
> close the editor..and git starts compiling all your intermediate commits and stops if they fail<br>
><br>
><br>
><br>
> kind regards<br>
> holger<br>
><br>
><br>
><br>
><br>
> [1] A GSM component that converts a LLC frame to smaller pieces. Decides on the coding scheme (error correction bits vs. data), schedules resources across several handsets.<br>
> [2] <a href="http://lists.osmocom.org/pipermail/openbsc/2016-May/009139.html" rel="noreferrer" target="_blank">http://lists.osmocom.org/pipermail/openbsc/2016-May/009139.html</a><br>
</div></div></blockquote></div><br></div></div>