also sprach Manish <[EMAIL PROTECTED]> [2008.07.30.1520 +0200]: > I am also new to git so just to confirm. Merge will leave us with one > less branch whereas a rebase will move our changes on top of the > changes of other branch. Right?
No, you'll have two branches in both cases. The distinction is between linear (rebase), meaning that one branch builds off the tip of another, and recursive (merge), meaning that the branches run in parallel and later join up. I really suggest to play around with this, the manpages, and gitk! > Also if a document is modified in master and also modified in > branch A, then when we rebase A on top of master what will be the > state of contents of A? Same as master or same as A or will > a merge be performed? A merge will be performed, or conflict resolution required. Just like if you merged them. Rebasing is essentially taking each commit and cherry-picking/applying it on top of the destination tip; if a commit cleanly applies, move on; if not, try merge; if that fails, ask the user to resolve the conflict. -- martin | http://madduck.net/ | http://two.sentenc.es/ "no survivors? then where do the stories come from I wonder?" -- captain jack sparrow spamtraps: [EMAIL PROTECTED]
Description: Digital signature (see http://martin-krafft.net/gpg/)
_______________________________________________ vcs-home mailing list email@example.com http://lists.madduck.net/listinfo/vcs-home