git for versioning

[Manish]

  On Wed, Jul 30, 2008 at 7:26 PM, martin f krafft wrote:
  > also sprach Manish [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.

You are right.  Branches live on till they are deleted intentionally.

  > 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.

Thank you.  It helped.

-- Manish