Thank you for your advice, Philip! Table, in this case, is a new major feature in the app, and parts of that feature are already pushed to get feedback, that's why I have pushed commits. We are following (more or less) the GitHub flow, so master always works. Meanwhile these intermediate branches are free to use (although it's strongly advised for its origin side to be mergeable any time).
Also, merging with master on the feature branch is somewhat optional until the pull request, but we do it after all bugfix pulls, and most feature pulls. As we do heavy testing, most final pull requests don't affect master too hard (except some accidents, of course). What I finally did, a bit reversing you advise, is this: On branch table $ git branch tmp $ git reset --hard origin/table $ git merge master Fix conflicts, run tests $ git checkout tmp $ git rebase origin/table Fix more commits, run tests, all fine $ git checkout table $ git reset --hard tmp All this, of course on a copy of my repo, all hail git for making it possible :-) Everything seems fine so far, although now that I write this, it would have been a bit shorter with your version, but I can't see how it is less error prone. On 3 Aug 2014 17:00, "Philip Oakley" <philipoak...@iee.org> wrote: > *From:* Gergely Polonkai <gerg...@polonkai.eu> > > *To:* git-users@googlegroups.com > *Sent:* Sunday, August 03, 2014 2:09 PM > *Subject:* [git-users] Merge+rebase diverged branches > > Hello, > > I have two branches, master and table, both went through some changes and > have their respective tracking brances: > > M1! - M2! - M3! > \ > \-T1! - T2! - T3 - T4 > > commits marked with ! are pushed upstream. I'd like to merge master into > table, and rebase my local commits (T3 and T4) on top of the result. How > can I do that? I was thinking about "saving" T4 as a tmp branch, resetting > table to origin/table, but here I lost my track, as I don't know how to > apply those local commits on my new merge commit. > > Thanks in advance! > > I'd start a new new branch at T2! (git checkout -b), then do the merge > with master (M3!), and then do a rebase of Table (T3-T4) onto the new tip. > > However I'm not quite sure how that would fit with your upstream workflow > - it depends on how they want to see the intermediate merges (i.e. should > master appear to be a first or second parent in the merge record?) > > Similarly you can rename the various branches to make them all look good > (i.e. get the right 'names'. ). > > The main difference between my approach and yours is that I add extra > branches at the mid points while you were reseting to those points (which > would be error prone for me ;-) > > Don't forget to use Gitk (visualisation) and Git Gui (sneak ammending, > etc) and any other useful tool to do things by the back door! > > Philip > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
