Martin Langhoff wrote: > On 11/29/06, Nicholas Allen <nick.allen@xxxxxxxxxxxxx> wrote: >> yes I can see if you just use plain patches. In bzr though there are >> bundles that store extra data along with the patch and if you use this >> instead of a simple patch this will never be a problem as bzr can then >> notice the same bundle being merged into 2 branches. > > Well, there you start depending on everyone using bzr and providing > metadata-added patches. Git is really good at dealing with scenarios > where not everyone is using Git.. so the > content-is-kind-and-metadata-be-damned pays off handsomely. > > And the "scenarios where not everyone is using Git" are everytime that > we are tracking a project that uses a different SCM. For me, the > "killer-app" of git is that, as it does not rely on magic metadata, it > is perfectly useful on projects that I track that use CVS or SVN. > > I submit or commit patches upstream and git spots the commits being > echoed back in just right because it does not rely on the metadata. > Only on the content. > > cheers, > > > martin > ps: hope you don't mind I re-added the CC to git@vger in my reply Of course not - I also added bzr mailing list back on this discussion too... I have to agree that's pretty cool! For the kind of development we do this is not really a big deal though as all developers can agree on using one RCS. But if you mix git and svn in this way then the changes can only go one way (from svn to git) can't they as svn is not so intelligent so this somewhat limits its usefulness doesn't it? I know bzr it has some beta level plugin support for SVN foreign branches (git, mercurial and svk ones too I think) and I believe this works in both directions. So you can commit to bzr, push that to an svn repository and also pull changes from svn. Merge branches in bzr and commit back to svn with log messages and history intact. So bzr still allows the use of multiple RCS systems... Nick - 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