<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 16 September 2014 08:39, Ian Booth <span dir="ltr"><<a href="mailto:ian.booth@canonical.com" target="_blank">ian.booth@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 16/09/14 00:50, Eric Snow wrote:<br></span></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><br>
> Step (0) is also pretty easy and I'll argue that people should be<br>
> doing it anyway.<br>
><br>
<br>
</span>Disagree :-)<br>
I never (or very, very rarely) had to do this with Launchpad and bzr and things<br>
Just Worked. I don't do it now with github and pull requests. I'd like to think<br>
we'd be able to avoid the burden moving forward also.<br></blockquote><div><br></div><div>Sorry, I didn't mean for this to turn into a rebase vs merge discussion. A different choice of wording would have helped. The first step could have been written like:</div><div><br></div><div>    0.  Sync up your feature branch with upstream (by merging or rebasing)</div><div><br></div><div>Some people like rebasing and some like merging. It doesn't matter much to the rest of the team which approach you use but I presume that everyone syncs up their branch somehow soon before proposing (rerunning tests etc) to ensure that other people's changes haven't impacted theirs. </div><div><br></div><div>- Menno<br></div></div></div></div>