emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Git transition checklist


From: Stephen J. Turnbull
Subject: Re: Git transition checklist
Date: Thu, 09 Jan 2014 13:27:44 +0900

Glenn Morris writes:

 > Can I replicate such a [bzr shared repo] setup?
 > How do I make a bound branch?

Replicate, no -- there are minor semantic differences.  Get space
savings and avoid network traffic when the object is available
locally, yes.  Bound branch, see Option 2 below.

DO NOT read the footnotes unless you are a git fan, if you're a bzr
kinda hacker your brain will explode.

Two ways to do it.  Both start by cloning the upstream repo

    cd $PARENT_DIRECTORY_FOR_EMACS_REPOS
    git clone $URL_TO_SAVANNAH_GIT_EMACS_TRUNK trunk

Option 1:

    # In same CWD as above:

    git clone --shared trunk ws1

Option 2:

    # In same CWD as above; [branch2] is an optional argument to
    # choose the named branch from trunk to check out.  It may be
    # irrelevant to the Emacs repo setup, I don't know.
    # The git-new-workdir script is in the git contrib directory, it's
    # not enabled by default.

    git new-workdir trunk ws2 [branch2]

CAVEAT for both options: DO NOT BLOW AWAY TRUNK!!  It is the
equivalent of the shared-repo's .bzr.

Difference between the options:

Option 1 is like a regular bzr branch: branch1's history is identical
to trunk up to the point of cloning, after that independent of trunk.

It is possible to switch the workspace to a different branch using
git-checkout, but that branch's history may not be complete unless you
pull it again from trunk.[1]

Option 2 has many similarities to a *local* bound branch.  *All*
history and branch configuration is shared.[2]  This has some glitches.

The obvious one is that it only works locally, so unlike a bzr bound
branch it's useless as an "automatically synced staging area for
pushes."  Almost as obvious, since HEAD is usually a pointer to a
branch ref (not to a commit), a commit in ws1 will advance HEAD in all
workspaces that have checked out the same branch.  This is usually not
what is wanted in a development workspace.

For more glitches, ask Stefan.  It's against my religion to believe in
glitches in git, so surely there aren't any more.

Now, you can make an informed choice.  Pick your poison!

I hereby license this text to all under the MIT/X license.  For a
signed paper copy, send me an SASE (110 yen).

Footnotes: 
[1]  Technically the history DAG is complete because the objects
directory is hardlinked in both GIT_DIRs, but the branch ref in ws1
does not advance with the branch ref of the same name in trunk.

[2]  Technically, the refs and .git/config as well as the DAG are shared.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]