If i am not mistaken if you have multiple commits in a branch git has something built in called git squash. This obviously eliminates the 5 step process into one merge and one push.
--- Regards, Jonathan Aquilina Founder Eagle Eye T On 2014-09-16 09:44, roger peppe wrote: > On 15 September 2014 21:39, Ian Booth <[email protected]> wrote: > >> On 16/09/14 00:50, Eric Snow wrote: >> >>> On Mon, Sep 15, 2014 at 8:09 AM, Eric Snow <[email protected] [1]> 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. Links: ------ [1] mailto:[email protected]
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
