Thanks a lot for your time. That cleared my doubts.

On Sat, Feb 23, 2013 at 3:29 PM, Prasoon Shukla <[email protected]>wrote:

> Yeah. A little more on rebase. Let's say here's your master:
>
> A ---- B ---- C (master)
> Then you create a new branch from master and make some commits. Also, in
> the meantime, someone else pushed to master. Then, your branch and master
> have the same tree till the commit 'C' from where it diverges.
>
> A ---- B ---- C ---- D ---- E ---- F (master)
>               \
>                \
>                  X ---- Y ---- Z (branch)
>
> Now, say you want the changes in master to be incorporated in branch. So,
> have two options: merge or rebase. Merging would create a new commit in
> branch that has changes from from both branches:
>
> A ---- B ---- C ---- D ---- E ---- F (master)
>               \                     \
>                \                     \
>                  X ---- Y ---- Z ---- MC (branch)
> Here, MC is the merge commit. Now, if you do more work, it goes on top of
> MC in branch.
>
> A ---- B ---- C ---- D ---- E ---- F (master)
>               \                     \
>                \                     \
>                  X ---- Y ---- Z ---- MC ---- G ---- H (branch)
>
> As you can see, this creates a non-linear tree structure.
> Rebasing changes the tree structure of your commit history. So, if you
> have this:
>
> A ---- B ---- C ---- D ---- E ---- F (master)
>               \
>                \
>                  X ---- Y ---- Z (branch)
> and you want changes from master in your branch, but you also want a
> linear commit tree, you can use rebase.
> Rebase will temporarily strip your commits, rewind work work (literally;
> git says so while you rebase) while you are in a temporary 'no-branch' and
> stacks commits from your branch top of master.
>
> A ---- B ---- C ---- D ---- E ---- F (master)
>                                     \
>                                      \
>                                        X' ---- Y' ---- Z' (branch)
>
> Note that I have added primes to X, Y and Z. This is because if you have
> any conflicts while you are rebasing, git will require you to remove the
> conflicts *during* the rebase. This is one of the problems of rebase
> actually - you will need to fix that particular conflict for *every single
> one* of the commits X, Y and Z whereas while merging, you need to do that
> only once.
>
> Btw, to see your commit tree, you can use git log --graph
> Hope this clarifies rebase and merge. Discussions on merge vs rebase are
> available in plenty on stackoverflow too.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/sympy?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
Regards,
Manoj Kumar,
Mech Undergrad.
BPGC
Blog <http://manojbits.wordpress.com>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to