Re: Migrating away from CVS? was: [temporal snapshot of cvs source is prepared]

[Tait <gnu...@t4...>]

> > Mercurial is nice, and I've used it, too. The learning curve of Mercurial
> > is lower, and it certainly appeals to those who don't like/use the
> > index. I find the index to be an invaluable tool.
> 
> Please explain index tool.  I can't recall what that is.

Sorry, I should have been clearer. The index is what one manipulates
with "git add". It's the "platform" that you described earlier. It is
variously called the index, the cache (usually for options like git
diff --cached), or the stage (but usually as a verb, "staged"). It all
means the stuff that will become the next commit.

> > For those wanting
> > to mostly pretend it doesn't exist, git has options like git commit -a
> > (which can be aliased using your shell, or git itself).
> 
> Thereby avoiding the "add to platform" step, correct me if I'm wrong.

Correct.

> Mobile phone free, and still going.

I chose a poor analogy, then.  The concept of branches in git is much
the same as it was with CVS, but the practical usage is a world apart.

In git, branching is easy and cheap. It is no effort at all to create
a branch, delete it, move it in history (if there are no conflicts),
merge it, or switch between branches. This makes branches a useful way
to collect related sets of commits (changes).

I make a new branch (locally on my computer) for every development idea
I try. I can record my progress on these ideas as I go. When I'm done,
it's easy to go back, clean, reorganize, and package it so someone
else can make sense of the history. Or I can throw it away and nobody
else knows what a horrible idea I had. Or I can carry forward my idea
indefinitely, keeping it always up-to-date with the latest upstream
changes (git calls this "rebase"). Nobody else benefits from the last
scenario, but it makes maintaining my own private set of changes easy.

With CVS, I would just accumulate more and more uncommitted changes, or
I'd have to track my changes externally somehow. Either way, it's hard
to revisit what I did, or keep it up to date with upstream changes. Easy
branching is useful to developers even if the gnuplot project itself
never actually creates a branch. And I think the project would want to
create a few branches anyway. Developers can make their local changes
in a different tool than the project uses (as I do currently with git
and gnuplot's CVS, for example), but why force the use of two different
tools?

> > Where git does shine a little brighter than Mercurial is in the maintainer
> > role. Whoever is accepting patches (from SourceForge, mailing list, ...)
> > and committing them will have an easier time in that role with git.
> 
> How or why?

I think I touched on this in the explanation of how the git project
handles user contributions, but it comes down to tools for managing and
incorporating contributions from other users, support for delegating
tasks (like conflict resolution) to others, and minimizing the time
involved in merging and creating releases.