Re: VCS comparison table

Aaron Bentley wrote:

Andreas Ericsson wrote:

quoted

Aaron Bentley wrote:

quoted

Ah.  Bazaar uses negative numbers to refer to <n>th parents, and
positive numbers to refer to the number of commits that have been made
since the branch was initialized.

What do you do once a branch has been thrown away, or has had 20 other
branches merged into it? Does the offset-number change for the revision
then, or do you track branch-points explicitly?

We always track the number of parents since the initial commit in the
project.  Sorry, I don't think I said that clearly before.

While this I think is quite reliable (there was idea to store "generation
number" with each commit, e.g. using not implemented "note" header, or
commit-id to generation number "database" as a better heuristic than
timestamp for revision ordering in git-rev-list output), and probably
independent on repository (it is global property of commit history,
and commit history is included in sha1 of its parents), numbering branching
points is unreliable, as is relying on branch names.
 

quoted

quoted

If I understand correctly, in Bazaar, you'd just merge the current work
into 'xx/topic'.

merge != rebase though, although they are indeed similar. Let's take the
example of a 'master' branch and topic branch topicA. If you rebase
topicA onto 'master', development will appear to have been serial.

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.
 

quoted

If
you instead merge them, it will either register as a real merge or, if
the branch tip of 'master' is the branch start-point of topicA, it will
result in a "fast-forward" where 'master' is just updated to the
branch-tip of 'topicA'.

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?
 

quoted

quoted

I'm not sure what you mean by API, unless you mean the commandline.  If
that's what you mean, surely all unix commands are extensible in that
regard.

I'm fairly certain he's talking about the API in the sense it's being
talked about in every other application. Extensive work has been made to
libify a lot of the git code, which means that most git commands are
made up of less than 400 lines of C code, where roughly 80% of the code
is command-specific (i.e., argument parsing and presentation).

Ah, okay.

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. Git is not as of yet
libified; when it would be we could think about bindings for other
programming languages (there is preliminary Java binding/interface).
-- 
Jakub Narebski
Poland