<div dir="ltr">On Sat, Jan 11, 2014 at 4:09 AM, Mike Wey <span dir="ltr"><<a href="mailto:mike@mikewey.eu" target="_blank">mike@mikewey.eu</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On 01/10/2014 10:36 PM, Brad Roberts wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
     b. pull request for fixes should be made against and merged with<br>
the branch<br>
</blockquote>
<br>
wrong, fixes should _always_ be made on master first and then back<br>
ported to branches that might require them.  Consider the case of a<br>
regression that exists in multiple release branches.<br>
</blockquote>
<br></div>
Wouldn't the release branch be merged back into master?<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Mike Wey</font></span><br clear="all"></blockquote><div><br></div><div>This is the way I see it. The easiest way to fix a bug and merge it into other branches that need it is to fix it on the oldest branch it exists. To use the latest branch, as Walter mentions, brings in many other changes which may or may not be relevant to the issue. This can be as simple as fixing indentation (which wouldn't actually cause compilation error).<br>

<br>When merging from master to an older branch each needed change needs to be located during the cherry-pick, if you start with the older branch then it is just merge all commits, and since this is git we can do this any number of times. Cherry-picking is great, but I think it is stupid to rely on it as "standard."<br>

</div></div><br>-- <br>Jesse Phillips
</div></div>