git for versioning

[martin f krafft]

also sprach Manish <mailtomanish.sharma at gmail.com> [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: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20080730/f204cb8c/attachment-0001.pgp>