somewhat OT: maybe useful git script git-test-merge
Hi @ll, I'd like to tell you about a small script I've written to make life easier with git: git clone git://mawercer.de/git-test-merge It remembers test merge setups so that you can merge different feature branches by typing: $ gtm set setup1 branch1 remotes/branch2 branch3 $ gtm update setup1 $ gtm continue # after resolving conflicts To remove brances from the setup you have to edit .git/config Additionally it uses a commit message warning about it beeing a test merge only. Unfortunately I don't know a nice way to share the git-rerere cache yet which remembers conflict resolutions automatically. It works best on orthogonal branches of course :) Read about Linus complaint in man git-rerere to find out why I've written this script Sincerly Marc Weber ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
git and sync-all: Why not merge in libraries?
Hi all, With the upcoming switchover to git, has any thought gone into merging in the libraries into the main ghc tree (eliminating the need for a 'git-all')? git can merge two histories with no common ancestor, so no history would be lost - though you'd have to ask greater gurus than I the proper procedure. It's been done a few times on git itself to fold in externally developed tools. As I understand it, you could even continue development of the libraries on a seperate tree, as long as you don't try merging changes on ghc.git to $library.git, unless you filter out the GHC-only changes first somehow (merging $library.git back into ghc.git, as I understand it, should work...). Not sure if I'm missing something here, or if it's impractical for some reason... Thanks, Bryan Donlan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: git and sync-all: Why not merge in libraries?
With the upcoming switchover to git, has any thought gone into merging in the libraries into the main ghc tree The libraries are going to remain under darcs, because they are shared with other haskell compilers. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
Max Bolingbroke: 2008/8/6 Duncan Coutts [EMAIL PROTECTED]: On Tue, 2008-08-05 at 22:12 -0700, Don Stewart wrote: marlowsd: Following lots of useful discussion and evaluation of the available DVCSs out there, the GHC team have made a decision: we're going to switch to git. Hooray, this will generate a lot of open source good will, and help make GHC more accessible to the outside world. Heh, you still need darcs to build it, because all the libs are using darcs, and that's not going to change any time soon. One thing that might be a good idea is setting up Git mirrors of the libraries etc that we cannot convert to Git since other people depend on them. This would give us nice integration with Gits submodule support, allowing us to check out a consistent snapshot of the entire tree (including the libraries, Cabal etc) at any point in time straightforwardly. Of course, as a bonus you wouldn't have to install Darcs to clone. I seriously hope the plan is to move all *core* libraries (including GHC's cabal repo) etc over to git, too. In other word, everything that you need to build the development version of GHC should come via git. Having a mix of VCSs would be the worst option of all. Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
