-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jakub Narebski wrote: > Aaron Bentley wrote: >> 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. Oh. Bazaar supports sending merge commits by 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. Yes, that's something that I'd heard about the kernel development methodology-- that a series of small patches is preferred to one patch that makes the whole change. That's not the way we operate. We like to review all the changes at once. But because bundles are applied with a 'merge' command, not a 'patch' command, an old bundle will tend to apply more cleanly than an old patch would. > 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. I guess so, since git merge will do fast-forward after a fetch. >> 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. I'm not sure what you think Bazaar does. In Bazaar, a repository format plugin implements the same API that a native repository format does. This is how bzr supports Subversion, Mercurial and Git repositories. > Changing repository format is not a good idea for "dumb" protocols; I can't parse this. Repository formats and protocols are different things, right? > native > protocol is quite extensible I was meaning dumb protocol extension. I can't say how extensible the bzr native protocol is. > Adding > cURL based FTP read-only support to existing HTTP support was a matter > of few lines, if I remember correctly. We support read and write over native, ftp and WebDAV (a plugin). We also have readonly http support. > Besides, if monkey-patching is something akin to advices, I guess that > performance might suffer. No, monkey-patched code executes at the same speed as unpatched code. There are arguments against monkey-patching, but speed is not one of them. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFNVkM0F+nu1YWqI0RAjCaAJwOcWSUdVy7RpUZROJVxAC9aj/V/wCfUg0T uHkdc9k6i+v0QnhEvTXdszM= =YO8G -----END PGP SIGNATURE----- - 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