VCS comparison table

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jakub Narebski wrote:
>>Ah, now I see what you mean, and the "graft" plugin mentioned by others
>>fills that role.  I've never used it, though.
> 
> 
> Very useful as a kind of poor-man's-Quilt (or StGit). You develop some
> feature step by step, commit by commit in your repository cooking it
> in topic branch. Then before sending it to mailing list or maintainer
> as a series of patches (using git-format-patch and git-send-email)
> you rebase it on top of current work (current state), to ensure that
> it would apply cleanly.

What is the bad side of using merge in this situation?

>>Interesting.  We don't do 'fast-forward' in that case.
> 
> 
> Fast-forward is a really good idea. Perhaps you could implement it,
> if it is not hidden under different name?

We support it as 'pull', but merge doesn't do it automatically, because
we'd rather have merge behave the same all the time, and because 'pull'
throws away your local commit ordering.

>>So it sounds to me like git is extensible, though not as thoroughly as bzr.
> 
> 
> I think having good API for C, shell and Perl (and to lesser extent for any
> scripting language) means that it is extensible more.

I guess it's a value judgement on which is more important to extensibility:

Git has more language support.

Bzr has plugin autoloading, Protocol plugins, Repository format plugins,
and more.  Because Python supports monkey-patching, a plugin can change
absolutely anything.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFFNUrP0F+nu1YWqI0RAizXAJ0Wnf2ZoIRpaba3mX2L4pN9XcWDPQCePtg/
G/W6Oxm+kd8SzhGEEfLAxL8=
=VqC7
-----END PGP SIGNATURE-----