ReviewBoard is now the official review tool for juju

[roger peppe]

On 15 September 2014 21:39, Ian Booth <ian.booth at canonical.com> wrote:
> On 16/09/14 00:50, Eric Snow wrote:
>> On Mon, Sep 15, 2014 at 8:09 AM, Eric Snow <eric.snow at canonical.com> wrote:
>>> Yeah, those steps are a lot, though keep in mind that effectively it's
>>> only 2 steps more than before if you use the -p flag to rbt post and
>>> were already keeping your local master up to date.
>>
>> Just to be clear, here are the steps again, slightly reformatted:
>>
>> (0). Rebase relative to upstream master.
>>   - if origin is different than upstream, sync and push it
>
> Before I create a new branch, I ensure my local and origin (forked copy) master
> branches are up to date. However, once the branch is created, thereafter I do
> not rebase because it has caused nothing but trouble, with lots of manual effort
> required to fix things up wrt conflicts etc.

Here's a trick I use (I imagine it's a well
known technique) that makes it easy to do a lightweight
rebase without the conflicts that often come when rebase
replays your commits:

$ git fetch upstream
$ git merge upstream/master
$ git reset upstream/master
$ git add any new files added in your branch
$ git commit -am 'describe your branch'

As far as I can make out, as long as you want to
propose your branch with only a single commit
added to the log, this makes it easy to use a
merge-based flow and amounts to
the same thing in the end.

I use it a lot, and it's saved no end of "this is the *third* time
I've resolved these conflicts" pain.

  cheers,
    rog.