-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jakub Narebski wrote:
quoted
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?
quoted
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.
quoted
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-----