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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html