Re: VCS comparison table

[Jakub Narebski <jnareb@gmail.com>]

Aaron Bentley wrote:
> 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?

We want linear history, not polluted by merges. For example you cannot
send merge commit via email. Another problem is that you want to
send _series_ of patches, string of commits (revisions), creating feature
part by part, with clean history; with merge you get _final result_
which will apply cleanly, with rebase you would get that series
of patches will apply cleanly.
 
>>>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.

I smell yet another terminology conflict (although this time fault is
on the git side), namely that in git terminology "pull" is "fetch"
(i.e. getting changes done in remote repository since laste "fetch"
or since "clone") followed by merge. pull = fetch + merge.

>>>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.

Which is _not_ a good idea. Git is created in such way, that the repository
is abstracted away (introduction of pack format, and improving pack format
can and was done "behind the scenes", not changing any porcelanish (user)
commands), but we don't want any chage that would change this abstraction.
Changing repository format is not a good idea for "dumb" protocols; native
protocol is quite extensible (for example there was introduced multi-ack
extension for better downloading of multiple branches with lesser number
of object in the pack sent; even earlier there were intoduced thin packs),
and does a kind of feature detection between client and server. Adding
cURL based FTP read-only support to existing HTTP support was a matter
of few lines, if I remember correctly.

Besides, if monkey-patching is something akin to advices, I guess that
performance might suffer.


To make perhaps not that good analogy. In git adding new commands is
like adding new filesystem to Linux kernel using existing VFS interface,
or existing FUSE/LUFS interface. In Bazaar adding new command is like
writing new filesystem support (plugin) in mikrokernel like L4/Mach.
(And please take note for what project git was created for :-))

-- 
Jakub Narebski
ShadeHawk on #git
Poland