a git plan, long term

[Cantor, Scott]

On 8/8/13 6:01 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>I admittedly don't understand branching in Git (or anything else in Git
>for that matter), but at least wrt to frequency of branching I don't see
>any particular advantage with Git.

The reason it's viewed as better for brancing is that it's low overhead to
branch. Subversion takes some time to branch, particularly on slow links,
and switching between branches is a heavier operation.

Brancing and switching with Git is very fast and done offline.

That said, I don't find it very advantageous to branch like that because I
don't trust merging (which is why I use neither svn nor git very
effectively, unlike you and most others). That's one of those things you
either trust or you don't, and it's very hard to achieve that trust when
you've had nothing but broken merges whenever you've tried it. A hundred
conflicts is not going to install that confidence.

I agree that realistically if we were to use svn more effectively, we'd
need to branch more and avoid requiring stable builds on some of the
branches. Today, I have to work very deliberately if I want to move
between machines because I don't want a check in to break the build. Git
is one way around that problem, but that's specialized to my use of
multiple laptops.

Wrt githib as a "centralized" SCM, the way people use it with git is that
their work is a clone of the central copy, and that's more or less the
"stable trunk" or "stable branch" of the project. All the unstable stuff
is private (often).

-- Scott