Aaron Bentley wrote: > 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. Perhaps it would be nice to have "bundles" in git too. As of now we can save arbitrary part of history in a pack, but it is binary not textual representation. Some of git workflow stems from old, pre-SCM Linux kernel workflow of sending _patches_ via email. By the way, are bzr "bundles" compatibile with ordinary patch? git-format-patch patches are. They have additional metainfo, but they are patches in heart. >>> 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. But if I remember correctly Subversion does not remember merge points (merge commits), so how can you provide full Bazaar-NG compatibility with Subversion repository as backend? Some repository formats lack some features. Besides, as I said repository database and stuff is quite well abstracted away. In git we have import tools (most of them capable of incremental import), a few exchange tools like git-cvsexportcommit, git-cvsserver, and Tailor-like git-svn. >> Changing repository format is not a good idea for "dumb" protocols; > > I can't parse this. Repository formats and protocols are different > things, right? "Dumb" protocols in git are protocols for which server provides access to contents git repository plus some additional info (usually generated using hooks). The client (be it git-fetch or git-push) discovers which files to download or what to upload, but it only can download repository "as is". So if server repository was created with repository format plugin, and client doesn't have said plugin, you are out of luck. >> native protocol is quite extensible > > I was meaning dumb protocol extension. I can't say how extensible the > bzr native protocol is. Native git protocol (git:// and git+ssh://) does feature discovery, then negotiates what contents has to be send, and finally tries to send minimal number of objects. >> 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. Git has read-only access over git:// protocol (served by git-daemon on port 9418), read-write access over git+ssh:// protocol (you can limit exposition using git-shell), read-only access via HTTP, HTTPS, FTP "dumb" protocols, read-write access via WebDAV "dumb" protocol. Git is open-source, we don't need plugins ;-) -- 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