Two additional notes:
1) Note (*R6*) not using --onto parameter.
2) With rebase flow, the final merge may be given a `--no-ff` parameter,
causing an explicit merge commit to be created instead of a fast-forward
merge, giving this situation instead of previously shown (R12):
(*R12a*) ---A---B---C---D---E---F---G---H-----------------------M (master)
\ /
X'''Y'''Z'''W''-V'--U' (Dish)
Some people prefer this to (R12) as it keeps topic branch logically/visibly
separated from the main flow, providing a clear merge point M (even if
topic branch "Dish" gets deleted), also making it easier to revert/undo the
whole topic later, in case needed.
On Saturday, March 25, 2017 at 2:08:40 AM UTC+1, Igor Djordjevic wrote:
>
> Hi Michael,
>
> On Thursday, March 23, 2017 at 10:10:02 PM UTC+1, Michael Gersten wrote:
>>
>> I need help with the syntax of rebase.
>>
>> I have a branch, "Dish", that was branched off of master. This was about
>> a month ago.
>>
>> Making a new branch off master, and merging Dish into it, worked just
>> fine. No problem.
>>
>> Now, I have "master", and from it, "merged-dish".
>>
>> Time to update master. All good so far.
>>
>> What I want is an easy way to update "merged-dish". So I tried to rebase
>> it.
>>
>> git rebase --onto master Dish
>>
>> git rebase --onto master merged-dish
>>
>> Both of these were no-ops.
>>
>> So what's the best way to keep a local branch up to date as the upstream
>> master updates?
>>
>
> Until more knowledgeable/experienced people chime in, I`ll try to give
> some hopefully useful feedback. Anyone, please feel free to correct me or
> provide additional info I might have missed, I`m still learning myself.
>
> To understand what happened, it might be best to use some visualization of
> what is going on.
> Prior to your "rebase" attempts, after you updated "master", your history
> looked something like this:
>
> (*1*) ---A---B---C---D---E---F (master)
> \ \
> \ M (merged-dish)
> \ /
> X---Y---Z (Dish)
>
>
> As you said you`re trying to rebase "merged-dish" now, I`ll assume you`re
> on the "merged-dish" branch.
>
> (*2*) git rebase --onto master Dish
>
> This means "rebase current branch (merged-dish) on new base `master`
> (commit F) from old base `Dish` (commit Z)". But what are the actual steps?
> Let`s see:
>
> 1. Find all commits between old base "Dish" (Z) and current branch
> "merged-dish" (M) (contained in "merged-dish" but not in "Dish"). This
> results in commits B, C, D (you may expect to see M here, too, but it is
> missing as "rebase" by default does not preserve merge commits).
> 2. Replay these commits on top of new base "master" - but as these are
> contained inside "master" already, there is nothing to be done here, as
> you
> noticed, only "merged-dish" gets updated to point to where "master" is
> (commit F):
>
> (*3*) ---A---B---C---D---E---F (master, merged-dish)
> \
> X---Y---Z (Dish)
>
> (depending on the changes you have, you might end up with some merge
> conflicts during a rebase, but the end result should be as shown above)
>
>
> Now, on to the next one:
>
> (*4*) git rebase --onto master merged-dish
>
> This one confuses me a bit as you didn`t mention if you did anything
> between this and the previous command, because if you tried it right after
> the previous one, it doesn`t really make much sense.
>
> Why? If we ended up in a situation shown on graph (3) and tried command
> (4), the steps to do would look something like this:
>
> 1. Find all commits between old base "merged-dish" (F) and current
> branch "merged-dish" (F) (contained in "merged-dish" but not in
> "merged-dish")... and as already obvious, this returns nothing, no
> commits,
> so there`s nothing to be done in the next step - as you noticed again.
>
>
> All this said, the important question is - what should you have done
> instead?
>
> As usual, it depends on what you wanted to accomplish in the first place.
> For example, I`m not sure what was the idea behind "merged-dish" branch...?
>
> Anyway, let`s say this is some starting point:
>
> (*5*) ---A---B---C---D (master)
> \
> X---Y---Z (Dish)
>
>
> MERGE FLOW (M)
>
> If you wanted to update your "Dish" branch with recent commits from
> "master" using a merge, you should have just done that (while on "Dish"
> branch):
>
> (*M6*) git merge master
>
> ... which would give you this situation:
>
> (*M7*) ---A---B---C---D (master)
> \ \
> X---Y---Z---M (Dish)
>
>
> You can then keep working on both "master" and "Dish", and merge from
> "master" to "Dish" when you feel like it***:
>
> (*M8*) ---A---B---C---D---E---F (master)
> \ \
> X---Y---Z---M---W (Dish)
>
> (*M9*) ---A---B---C---D---E---F (master)
> \ \ \
> X---Y---Z---M---W---M2 (Dish)
>
>
> Finally, when you`re satisfied with your "Dish" completeness, you may
> merge it back to "master":
>
> (*M10*) ---A---B---C---D---E---F---G---H (master)
> \ \ \
> X---Y---Z---M---W---M2--V---U (Dish)
>
> (*M11*) ---A---B---C---D---E---F---G---H---M3 (master)
> \ \ \ /
> X---Y---Z---M---W---M2--V---U (Dish)
>
>
> You can now delete branch "Dish", keep it for reference, or even merge
> "master" into it (being a fast-forward merge):
>
> (*M12*) ---A---B---C---D---E---F---G---H---M3 (master, Dish)
> \ \ \ /
> X---Y---Z---M---W---M2--V---U
>
>
> REBASE FLOW (R)
>
> Alternatively, if you wanted to use the rebasing flow, you can just keep
> rebasing "Dish" on top of "master". So in situation (5), you would do this
> instead (while on "Dish" branch):
>
> (*R6*) git rebase master
>
> ... which would give you this (in comparison to previous (M7)):
>
> (*R7*) ---A---B---C---D (master)
> \
> X'--Y'--Z' (Dish)
>
>
> Again, you can then keep working on both "master" and "Dish", and rebase
> "Dish" to "master" when you feel like it*** (command (R6)):
>
> (*R8*) ---A---B---C---D---E---F (master)
> \
> X'--Y'--Z'--W (Dish)
>
> (*R9*) ---A---B---C---D---E---F (master)
> \
> X''-Y''-Z''-W' (Dish)
>
>
> Finally, when you`re satisfied with your "Dish" completeness, you may do
> one more (final) rebase:
>
> (*R10*) ---A---B---C---D---E---F---G---H (master)
> \
> X''-Y''-Z''-W'--V---U (Dish)
>
> (*R11*) ---A---B---C---D---E---F---G---H (master)
> \
> X'''Y'''Z'''W''-V'--U' (Dish)
>
> ... and then merge it back to "master" (which will now be a fast-forward
> merge):
>
> (*R12*) ---A---B---C---D---E---F---G---H---X'''Y'''Z'''W''-V'--U'
> (master, Dish)
>
>
> [***] There is a whole theory behind making a decision when to merge (or
> rebase) to update your topic branch, depending on what your flow/goal is,
> and even if that should be done at all (until all the work is done), but
> that is yet another topic.
>
> Regards,
> Buga
>
--
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.
