Loading ...
Sorry, an error occurred while loading the content.

MacVim: Version Control System

Expand Messages
  • björn
    I have been thinking about using GIT for version control instead of SVN since it is very hard to provide patches which requires changes to both the MacVim code
    Message 1 of 27 , Oct 8, 2007
    • 0 Attachment
      I have been thinking about using GIT for version control instead of
      SVN since it is very hard to provide patches which requires changes to
      both the MacVim code and the Vim code. Also, I have files that belong
      to the Vim code, but for obvious reasons I can't add them to the Vim
      repository (at the moment I keep these files in separate directories
      in the MacVim repo and copy them to their respective places in the Vim
      hierarchy before building).

      If you have any _constructive_ comments regarding (for or against)
      this move, then make your voice heard before I do this. I am not
      interested in comments like "I think XXX is better than YYY for
      version control".

      (Nico, George, Jiang; since you are the only developers apart from me
      at the moment, I would like you to at least say "YES" or "NO" to this
      proposal.)

      I was intending to keep the svn repo and merge my git repo with it
      every now and then...so the git repos will be used so that we can
      maintain our own branches (and for the reasons already stated).


      Thanks,
      Björn

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Jjgod Jiang
      Hi,2007/10/9, björn : I have been thinking about using GIT for version control instead of SVN since it is very hard to
      Message 2 of 27 , Oct 8, 2007
      • 0 Attachment
        Hi,

        2007/10/9, björn <bjorn.winckler@...>:
        >
        > I have been thinking about using GIT for version control instead of
        > SVN since it is very hard to provide patches which requires changes to
        > both the MacVim code and the Vim code. Also, I have files that belong
        > to the Vim code, but for obvious reasons I can't add them to the Vim
        > repository (at the moment I keep these files in separate directories
        > in the MacVim repo and copy them to their respective places in the Vim
        > hierarchy before building).
        >
        > If you have any _constructive_ comments regarding (for or against)
        > this move, then make your voice heard before I do this. I am not
        > interested in comments like "I think XXX is better than YYY for
        > version control".
        >
        > (Nico, George, Jiang; since you are the only developers apart from me
        > at the moment, I would like you to at least say "YES" or "NO" to this
        > proposal.)
        >
        > I was intending to keep the svn repo and merge my git repo with it
        > every now and then...so the git repos will be used so that we can
        > maintain our own branches (and for the reasons already stated).

        Hmm, how about using git-svn to fetch from the upstream vim repo?
        I've been looking at git for a while, but I have to admit it's a little bit
        too complicated for me, but if you'd like to use git, I'm fine, because
        I don't have any experiences using other distributed version control
        systems (hg, bzr, etc.) either, maybe I need some practice. :)

        So my answer is YES.

        - Jiang

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Bram Moolenaar
        ... Most people I know recommend using Mercurial instead of GIT: http://www.selenic.com/mercurial/wiki/ There are very strong arguments, but I don t have the
        Message 3 of 27 , Oct 9, 2007
        • 0 Attachment
          Bjorn Winckler wrote:

          > I have been thinking about using GIT for version control instead of
          > SVN since it is very hard to provide patches which requires changes to
          > both the MacVim code and the Vim code. Also, I have files that belong
          > to the Vim code, but for obvious reasons I can't add them to the Vim
          > repository (at the moment I keep these files in separate directories
          > in the MacVim repo and copy them to their respective places in the Vim
          > hierarchy before building).
          >
          > If you have any _constructive_ comments regarding (for or against)
          > this move, then make your voice heard before I do this. I am not
          > interested in comments like "I think XXX is better than YYY for
          > version control".
          >
          > (Nico, George, Jiang; since you are the only developers apart from me
          > at the moment, I would like you to at least say "YES" or "NO" to this
          > proposal.)
          >
          > I was intending to keep the svn repo and merge my git repo with it
          > every now and then...so the git repos will be used so that we can
          > maintain our own branches (and for the reasons already stated).

          Most people I know recommend using Mercurial instead of GIT:
          http://www.selenic.com/mercurial/wiki/
          There are very strong arguments, but I don't have the list written down.

          Otherwise, anything you feel comfortable with should be OK. So long as
          we can all download the latest version when we want to.

          --
          Never enter the boss's office unless it's absolutely necessary. Every boss
          saves one corner of the desk for useless assignments that are doled out like
          Halloween candy to each visitor.
          (Scott Adams - The Dilbert principle)

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          \\\ download, build and distribute -- http://www.A-A-P.org ///
          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • George Harker
          I ve never used git, though it s workflow sounds interesting, and I always wanted to investigate. I use svn for my opensource projects and have always found it
          Message 4 of 27 , Oct 9, 2007
          • 0 Attachment
            I've never used git, though it's workflow sounds interesting, and I
            always wanted to investigate.

            I use svn for my opensource projects and have always found it to be
            good. The deficiencies that there are (for me) are adressed with the
            newer releases with merge-memory. However, this may just mean it fits
            the scale (developer number wise) of the projects I've been involved
            in.

            I don't have a strong preference (though I'd prefer not to have to
            install something wild and exotic, if I can get it via fink or the
            like).

            It's one of those religous wars I guess - I don't mind all that much.
            Svn based would be a plus, but I'm not that bothered.

            Cheers

            George

            On 09/10/2007, Bram Moolenaar <Bram@...> wrote:
            >
            >
            > Bjorn Winckler wrote:
            >
            > > I have been thinking about using GIT for version control instead of
            > > SVN since it is very hard to provide patches which requires changes to
            > > both the MacVim code and the Vim code. Also, I have files that belong
            > > to the Vim code, but for obvious reasons I can't add them to the Vim
            > > repository (at the moment I keep these files in separate directories
            > > in the MacVim repo and copy them to their respective places in the Vim
            > > hierarchy before building).
            > >
            > > If you have any _constructive_ comments regarding (for or against)
            > > this move, then make your voice heard before I do this. I am not
            > > interested in comments like "I think XXX is better than YYY for
            > > version control".
            > >
            > > (Nico, George, Jiang; since you are the only developers apart from me
            > > at the moment, I would like you to at least say "YES" or "NO" to this
            > > proposal.)
            > >
            > > I was intending to keep the svn repo and merge my git repo with it
            > > every now and then...so the git repos will be used so that we can
            > > maintain our own branches (and for the reasons already stated).
            >
            > Most people I know recommend using Mercurial instead of GIT:
            > http://www.selenic.com/mercurial/wiki/
            > There are very strong arguments, but I don't have the list written down.
            >
            > Otherwise, anything you feel comfortable with should be OK. So long as
            > we can all download the latest version when we want to.
            >
            > --
            > Never enter the boss's office unless it's absolutely necessary. Every boss
            > saves one corner of the desk for useless assignments that are doled out like
            > Halloween candy to each visitor.
            > (Scott Adams - The Dilbert principle)
            >
            > /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            > \\\ download, build and distribute -- http://www.A-A-P.org ///
            > \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
            >
            > >
            >

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Ben Schmidt
            ... I use Macports, and it seems to include both, with a bit of a vote for Mercurial: git-core 1.5.2.4, Revision 1, devel/git-core (Variants: universal, doc,
            Message 5 of 27 , Oct 9, 2007
            • 0 Attachment
              > I've never used git, though it's workflow sounds interesting, and I
              > always wanted to investigate.
              >
              > I use svn for my opensource projects and have always found it to be
              > good. The deficiencies that there are (for me) are adressed with the
              > newer releases with merge-memory. However, this may just mean it fits
              > the scale (developer number wise) of the projects I've been involved
              > in.
              >
              > I don't have a strong preference (though I'd prefer not to have to
              > install something wild and exotic, if I can get it via fink or the
              > like).
              >
              > It's one of those religous wars I guess - I don't mind all that much.
              > Svn based would be a plus, but I'm not that bothered.
              >
              > Cheers
              >
              > George

              I use Macports, and it seems to include both, with a bit of a vote for Mercurial:

              git-core 1.5.2.4, Revision 1, devel/git-core (Variants: universal, doc, svn)
              http://git.or.cz/

              A stupid (but extremely fast) directory content manager. It doesn't do a whole
              lot, but what it _does_ do is track directory contents efficiently.

              vs.

              mercurial 0.9.4, devel/mercurial (Variants: universal)
              http://www.selenic.com/mercurial/

              Mercurial is a fast, lightweight Source Control Management system designed for
              efficient handling of very large distributed projects. A distributed SCM tool is
              designed to support a model in which each Repository is loosely coupled to many
              others. Each Repository contains a complete set of metadata describing one or more
              projects. These repositories may be located almost anywhere. Individual developers
              only need access to their own repositories, not to a central one, in order to
              commit changes. Changes can be share via the builtin webserver, CGI, SSH or a
              stream of patch emails. Mercurial supports Apples' FileMerge for merges.

              I don't really know whether I will become involved in MacVim development, but
              would probably put in a vote for Mercurial. With big names like Mozilla and the
              FreeBSD kernel using it (both of which seem to have for some reason gained more
              respect in my eyes than the Linux kernel) it would seem to me to be a good choice.
              From what I can gather, the benefits of Git over Mercurial are dangerous anyway,
              and it seems to have a few quite un-Mac-like deficiencies--difficulty of use, poor
              documentation, etc.

              Ben.





              Send instant messages to your online friends http://au.messenger.yahoo.com


              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • björn
              Thanks for all the comments so far. I thought I d just add my own story to the mix... I am pretty lazy when it comes to learning about the latest wonderful
              Message 6 of 27 , Oct 9, 2007
              • 0 Attachment
                Thanks for all the comments so far. I thought I'd just add my own
                story to the mix...

                I am pretty lazy when it comes to learning about the latest wonderful
                tools in software development, so I would like something that doesn't
                take up too much of my time. Actually I would love to keep using svn,
                but I can't see any way that it will let us keep personal branches
                around (I really don't feel good about giving lots of people write
                access to the svn repo). The way things work now I think hamper
                development (if it isn't easy to contribute, then lots of people who
                are lazy like me won't bother).

                I will take a look at Mercurial and Git (I don't know either of them)
                and try to assess which of them will be easiest to get into (again, if
                it is too hard, then potential contributors probably will be scared
                off).


                /Björn

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_mac" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • vivacarlie
                I second the use of git because murcural takes a few more steps to set up than git. If you can get a hold of the murcural irc channel than you can ask them to
                Message 7 of 27 , Oct 9, 2007
                • 0 Attachment
                  I second the use of git because murcural takes a few more steps to set
                  up than git. If you can get a hold of the murcural irc channel than
                  you can ask them to give their own arguments. the very active git
                  channel gave me their argument as "murcural is over engeneered" for
                  example, they said, "look at the project names and branch names that
                  murcural creates" its kind of hairy. I preferr git, and ...
                  free hosting at repo.or.cz!!!
                  i second git!


                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_mac" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • Nico Weber
                  ... + 1 for git (for no real reason; I guess mercurial is just as fine, but i always wanted to look at git). Nico
                  Message 8 of 27 , Oct 9, 2007
                  • 0 Attachment
                    > I will take a look at Mercurial and Git (I don't know either of them)
                    > and try to assess which of them will be easiest to get into (again, if
                    > it is too hard, then potential contributors probably will be scared
                    > off).

                    + 1 for git (for no real reason; I guess mercurial is just as fine,
                    but i always wanted to look at git).

                    Nico


                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_mac" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • Panos
                    It wouldn t hurt to look into Bazaar[1] either :) I ve started trying out two days ago instead of Subversion and it s pretty easy/fun. It can be easily
                    Message 9 of 27 , Oct 9, 2007
                    • 0 Attachment
                      It wouldn't hurt to look into Bazaar[1] either :)

                      I've started trying out two days ago instead of Subversion and it's
                      pretty easy/fun. It can be easily installed through MacPorts[2]


                      [1] http://bazaar-vcs.org
                      [2] http://bazaar-vcs.org/MacPorts

                      On Oct 10, 12:41 am, Nico Weber <nicolaswe...@...> wrote:
                      > > I will take a look at Mercurial and Git (I don't know either of them)
                      > > and try to assess which of them will be easiest to get into (again, if
                      > > it is too hard, then potential contributors probably will be scared
                      > > off).
                      >
                      > + 1 for git (for no real reason; I guess mercurial is just as fine,
                      > but i always wanted to look at git).
                      >
                      > Nico


                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_mac" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • Ryan Phillips
                      ... I would second the git-svn approach... git-svn allows for a transparent view of a Subversion repository and also can commit directly back to it. Done
                      Message 10 of 27 , Oct 9, 2007
                      • 0 Attachment
                        Jjgod Jiang <gzjjgod@...> said:
                        > Hmm, how about using git-svn to fetch from the upstream vim repo?
                        > I've been looking at git for a while, but I have to admit it's a little bit
                        > too complicated for me, but if you'd like to use git, I'm fine, because
                        > I don't have any experiences using other distributed version control
                        > systems (hg, bzr, etc.) either, maybe I need some practice. :)

                        I would second the git-svn approach... git-svn allows for a transparent
                        view of a Subversion repository and also can commit directly back to it.
                        Done right, no one would know patches would be coming from git. (However,
                        publishing the git repository would give that away :)

                        -Ryan

                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_mac" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • Jim Tittsler
                        ... svk adds this sort of functionality building on (most of) svn. It effectively adds star-merge capabilities and the ability to keep local repositories.
                        Message 11 of 27 , Oct 9, 2007
                        • 0 Attachment
                          On Oct 10, 2007, at 07:46, björn wrote:

                          > I am pretty lazy when it comes to learning about the latest wonderful
                          > tools in software development, so I would like something that doesn't
                          > take up too much of my time. Actually I would love to keep using svn,
                          > but I can't see any way that it will let us keep personal branches
                          > around (I really don't feel good about giving lots of people write
                          > access to the svn repo).

                          svk adds this sort of functionality building on (most of) svn. It
                          effectively adds star-merge capabilities and the ability to keep
                          local repositories. I've ended up using it just because it is so
                          close to svn (and because working directories don't all have .svn
                          subdirs :-).

                          http://svk.bestpractical.com/view/HomePage
                          OS X binaries: http://homepage.mac.com/hiirem/svkbuilds.html


                          --~--~---------~--~----~------------~-------~--~----~
                          You received this message from the "vim_mac" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                          -~----------~----~----~----~------~----~------~--~---
                        • Ben Schmidt
                          ... I have no experience with either, but would think that setup time would be a minor consideration. It is more the day-to-day usage that should be
                          Message 12 of 27 , Oct 9, 2007
                          • 0 Attachment
                            > I second the use of git because murcural takes a few more steps to set
                            > up than git.

                            I have no experience with either, but would think that setup time would be a minor
                            consideration. It is more the day-to-day usage that should be considered, and
                            developer participation. I found this article interesting on this front:

                            http://changelog.complete.org/posts/594-More-on-Git,-Mercurial,-and-Bzr.html

                            And here are some others I referenced in case you find them helpful in making your
                            choice, Bjorn. These were the ones I found most helpful and looking at the issues.

                            http://lwn.net/Articles/151624/
                            (especially the many comments on that page)

                            http://www.jukie.net/~bart/blog/git-vs-hg
                            (and other articles linked to by that one)

                            http://tytso.livejournal.com/29467.html

                            http://weblogs.mozillazine.org/preed/2007/04/version_control_system_shootou_1.html

                            http://changelog.complete.org/posts/586-Rebase-Considered-Harmful.html

                            I think it's the numerous comments like this one that make me favour Mercurial,
                            though without having tried either:

                            "I think that Mercurial has a more complete, consistent command line UI than git,
                            and certainly one that's more familiar to CVS or SVN users."

                            I also get the feeling that Git is prety Linux-centred, but Mercurial is more
                            cross platform and happy to play nice with Windows, Mac, etc., and of course, it's
                            Mac we're mainly interested in here! That said, though, if other Vim development
                            ever also wants to move to a distributed VCS, Windows support would be a plus, as
                            would having a consistent VCS on different platforms! It would be undesirable in
                            my eyes to have the Mac stuff using Git, and Windows and Unix using Mercurial or
                            some other more cross-platform solution! If the Mac folks lead the way, I think it
                            would be wise to lead the way with a solution that could go cross platform if
                            other platform developers want to.

                            Ben.




                            Send instant messages to your online friends http://au.messenger.yahoo.com


                            --~--~---------~--~----~------------~-------~--~----~
                            You received this message from the "vim_mac" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                            -~----------~----~----~----~------~----~------~--~---
                          • vivacarlie
                            the only problem with git on windows is that the cygwin people won t take into consideration compatibility issues with so they don t use a simple compile
                            Message 13 of 27 , Oct 9, 2007
                            • 0 Attachment
                              the only problem with git on windows is that the cygwin people won't
                              take into consideration compatibility issues with so they don't use a
                              simple compile option that would fix the issue. just ask someone on
                              the git irc channel. mostly what i appreciate about git is the
                              actively cooperative user/developer comunity. and there is no problem
                              with git on mac, its as simple as "port git-core" i would like it if
                              git on debian would update but then again ... what does update on
                              debian?

                              On Oct 9, 7:19 pm, Ben Schmidt <mail_ben_schm...@...> wrote:
                              > > I second the use of git because murcural takes a few more steps to set
                              > > up than git.
                              >
                              > I have no experience with either, but would think that setup time would be a minor
                              > consideration. It is more the day-to-day usage that should be considered, and
                              > developer participation. I found this article interesting on this front:
                              >
                              > http://changelog.complete.org/posts/594-More-on-Git,-Mercurial,-and-B...
                              >
                              > And here are some others I referenced in case you find them helpful in making your
                              > choice, Bjorn. These were the ones I found most helpful and looking at the issues.
                              >
                              > http://lwn.net/Articles/151624/
                              > (especially the many comments on that page)
                              >
                              > http://www.jukie.net/~bart/blog/git-vs-hg
                              > (and other articles linked to by that one)
                              >
                              > http://tytso.livejournal.com/29467.html
                              >
                              > http://weblogs.mozillazine.org/preed/2007/04/version_control_system_s...
                              >
                              > http://changelog.complete.org/posts/586-Rebase-Considered-Harmful.html
                              >
                              > I think it's the numerous comments like this one that make me favour Mercurial,
                              > though without having tried either:
                              >
                              > "I think that Mercurial has a more complete, consistent command line UI than git,
                              > and certainly one that's more familiar to CVS or SVN users."
                              >
                              > I also get the feeling that Git is prety Linux-centred, but Mercurial is more
                              > cross platform and happy to play nice with Windows, Mac, etc., and of course, it's
                              > Mac we're mainly interested in here! That said, though, if other Vim development
                              > ever also wants to move to a distributed VCS, Windows support would be a plus, as
                              > would having a consistent VCS on different platforms! It would be undesirable in
                              > my eyes to have the Mac stuff using Git, and Windows and Unix using Mercurial or
                              > some other more cross-platform solution! If the Mac folks lead the way, I think it
                              > would be wise to lead the way with a solution that could go cross platform if
                              > other platform developers want to.
                              >
                              > Ben.
                              >
                              > Send instant messages to your online friendshttp://au.messenger.yahoo.com


                              --~--~---------~--~----~------------~-------~--~----~
                              You received this message from the "vim_mac" maillist.
                              For more information, visit http://www.vim.org/maillist.php
                              -~----------~----~----~----~------~----~------~--~---
                            • Tim Allen
                              ... The beautiful thing about Git[1] is that because the identifier for each commit is based on a hash of its contents, so if two different people branch from
                              Message 14 of 27 , Oct 9, 2007
                              • 0 Attachment
                                On Oct 10, 8:33 am, Ryan Phillips <ryan-...@...> wrote:
                                > Jjgod Jiang <gzjj...@...> said:
                                >
                                > > Hmm, how about using git-svn to fetch from the upstream vim repo?
                                > > I've been looking at git for a while, but I have to admit it's a little bit
                                > > too complicated for me, but if you'd like to use git, I'm fine, because
                                > > I don't have any experiences using other distributed version control
                                > > systems (hg, bzr, etc.) either, maybe I need some practice. :)
                                >
                                > I would second the git-svn approach... git-svn allows for a transparent
                                > view of a Subversion repository and also can commit directly back to it.
                                > Done right, no one would know patches would be coming from git. (However,
                                > publishing the git repository would give that away :)

                                The beautiful thing about Git[1] is that because the identifier for
                                each commit is based on a hash of its contents, so if two different
                                people branch from the base repository and make changes, they'll have
                                a consistent common base that can be used to compare them.

                                git-svn is a wonderful way to use Git to work with a Subversion
                                repository, but two people running git-svn to branch from the base
                                repository are not guaranteed to get identical hashes, and hence the
                                two resulting Git repositories cannot be (as) easily compared.

                                If someone wanted to make an Official git-svn clone of the MacVim and
                                Vim upstream repositories, people could clone from that and get all
                                the advantages of git, but just using git-svn to deal with the current
                                central Subversion repository would not deliver all the benefits of a
                                true distributed version control system.

                                [1] Mercurial works on the same hashing scheme, so I suspect it has
                                the same benefits.


                                --~--~---------~--~----~------------~-------~--~----~
                                You received this message from the "vim_mac" maillist.
                                For more information, visit http://www.vim.org/maillist.php
                                -~----------~----~----~----~------~----~------~--~---
                              • Tim Allen
                                ... I m pretty sure Mozilla would have gone for Git if it had had a decent Windows port: As good, performant Win32 (and Mac and Linux) is a hard-requirement,
                                Message 15 of 27 , Oct 9, 2007
                                • 0 Attachment
                                  On Oct 10, 1:22 am, Ben Schmidt <mail_ben_schm...@...> wrote:
                                  > I don't really know whether I will become involved in MacVim development, but
                                  > would probably put in a vote for Mercurial. With big names like Mozilla and the
                                  > FreeBSD kernel using it (both of which seem to have for some reason gained more
                                  > respect in my eyes than the Linux kernel) it would seem to me to be a good choice.

                                  I'm pretty sure Mozilla would have gone for Git if it had had a decent
                                  Windows port:

                                  "As good, performant Win32 (and Mac and Linux) is a hard-requirement,
                                  Git lost in early Kombat rounds. This is unfortunate because (as we
                                  would soon find out), lots of issues with the other systems did "just
                                  work" in Git."
                                  -- http://weblogs.mozillazine.org/preed/2007/04/version_control_system_shootou_1.html

                                  > From what I can gather, the benefits of Git over Mercurial are dangerous anyway,
                                  > and it seems to have a few quite un-Mac-like deficiencies--difficulty of use, poor
                                  > documentation, etc.

                                  The advantages I feel Git has over Mercurial include:
                                  - A better-designed basic data model (the entire repository in one
                                  directory, with tags and branches being "pointers" to different parts
                                  of the history tree)
                                  - Speed

                                  Which of these are 'dangerous'?

                                  I will grant that Git can be difficult to someone coming from a CVS or
                                  SVN background, just because the basic data models are so different.
                                  However, once you understand what's going on, actually working with
                                  the system is very easy. For lurkers who just want to watch the
                                  progress of a project without actively hacking, a handful of simple
                                  commands is all you need to get around.

                                  For documentation, I'll note that Git has far, far more complete
                                  documentation than many open-source projects. The biggest problem I've
                                  encountered is cross-referencing; for example git-log pretty-prints
                                  the list of revisions for you, and gets this list of revisions by
                                  calling the underlying command git-rev-list. Therefore some command-
                                  line options git-log accepts are actually documented on the git-rev-
                                  list manpage, but the git-log manpage tells you this right at the
                                  start[1].

                                  I'd encourage anyone interested in learning more about Git to read the
                                  User's Manual[2], which quite gently mixes theory with practical, and
                                  also to browse the online manpages[3] to get a feel for what commands
                                  are available.

                                  [1]: http://www.kernel.org/pub/software/scm/git/docs/git-log.html
                                  [2]: http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
                                  [3]: http://www.kernel.org/pub/software/scm/git/docs/


                                  --~--~---------~--~----~------------~-------~--~----~
                                  You received this message from the "vim_mac" maillist.
                                  For more information, visit http://www.vim.org/maillist.php
                                  -~----------~----~----~----~------~----~------~--~---
                                • Tim Allen
                                  On Oct 10, 10:19 am, Ben Schmidt ... Git is unashamedly POSIX-centred, but OS X is quite nicely POSIX, so it s fine. It s true
                                  Message 16 of 27 , Oct 9, 2007
                                  • 0 Attachment
                                    On Oct 10, 10:19 am, Ben Schmidt <mail_ben_schm...@...>
                                    wrote:
                                    > I also get the feeling that Git is prety Linux-centred, but Mercurial is more
                                    > cross platform and happy to play nice with Windows, Mac, etc., and of course, it's
                                    > Mac we're mainly interested in here!

                                    Git is unashamedly POSIX-centred, but OS X is quite nicely POSIX, so
                                    it's fine. It's true that Git happens to rely heavily on POSIX
                                    features that Linux happens to be especially efficient at (such as
                                    mmap()ing files) but it's not like they're esoteric or un-portable or
                                    grossly inefficient on other platforms; you just might have to put up
                                    with merely speedy performance rather than the eye-widening sub-second-
                                    timing-on-any-operation performance Linus claims on Linux.

                                    > That said, though, if other Vim development
                                    > ever also wants to move to a distributed VCS, Windows support would be a plus, as
                                    > would having a consistent VCS on different platforms! It would be undesirable in
                                    > my eyes to have the Mac stuff using Git, and Windows and Unix using Mercurial or
                                    > some other more cross-platform solution! If the Mac folks lead the way, I think it
                                    > would be wise to lead the way with a solution that could go cross platform if
                                    > other platform developers want to.

                                    This is the best argument I've heard for Mercurial so far. Granted,
                                    Bram doesn't seem to care much for version-control systems at all, but
                                    the Vim Subversion repository seems to be popular - having a Vim
                                    Mercurial repository might not be more popular (Subversion has more
                                    brand-recognition) but would probably be more useful (the advantage of
                                    DVCS).


                                    --~--~---------~--~----~------------~-------~--~----~
                                    You received this message from the "vim_mac" maillist.
                                    For more information, visit http://www.vim.org/maillist.php
                                    -~----------~----~----~----~------~----~------~--~---
                                  • Ben Schmidt
                                    ... Enough said! Git on Windows uses Cygwin. Already a big minus. One needn t worry about the lesser problem outlined in the rest of your post, vivacarlie!
                                    Message 17 of 27 , Oct 9, 2007
                                    • 0 Attachment
                                      > the only problem with git on windows is that the cygwin

                                      Enough said! Git on Windows uses Cygwin. Already a big minus. One needn't worry
                                      about the lesser problem outlined in the rest of your post, vivacarlie! Cygwin
                                      itself is already a big turn-off for many (including me, though it's grown on me a
                                      little recently).

                                      > and there is no problem
                                      > with git on mac, its as simple as "port git-core"

                                      Yes and no. I have no doubt that it will work fine in the terminal. But that
                                      wasn't my point. From what I can gather, there is less chance of truly Mac-like,
                                      as opposed to POSIX or Unix-like, features for Git than for Mercurial. E.g. XCode
                                      integration, or Finder integration. I note there exists TortoiseHG on Windows, but
                                      don't see an equivalent for Git. There seems to be more of a culture and
                                      commitment to cross-platform work for Mercurial than Git. That's the feeling I
                                      get, anyway. And given one of the main aims of MacVim is to be truly Mac-like, I
                                      would think Mercurial fits that philosophy better.

                                      You see, I don't use the Mac just because it's like Unix. I use the Mac
                                      because...it's like a Mac! Sure, the commandline is nice, but I also like being
                                      able to drag things around and so on when I want to. (And I'm also lazy and like
                                      the idea of a shallow learning curve from SVN.)

                                      Grins,

                                      Ben.


                                      Send instant messages to your online friends http://au.messenger.yahoo.com


                                      --~--~---------~--~----~------------~-------~--~----~
                                      You received this message from the "vim_mac" maillist.
                                      For more information, visit http://www.vim.org/maillist.php
                                      -~----------~----~----~----~------~----~------~--~---
                                    • Ben Schmidt
                                      ... From what I ve read, neither of these seem to be clear advantages of one over the other. My understanding is that Mercurial was developed partly because
                                      Message 18 of 27 , Oct 10, 2007
                                      • 0 Attachment
                                        > The advantages I feel Git has over Mercurial include:
                                        > - A better-designed basic data model (the entire repository in one
                                        > directory, with tags and branches being "pointers" to different parts
                                        > of the history tree)
                                        > - Speed

                                        From what I've read, neither of these seem to be clear advantages of one over the
                                        other. My understanding is that Mercurial was developed partly because the backend
                                        data model of Git was felt by some to be less than ideal. Being not too well
                                        optimised also leads to speed problems which Mercurial was trying to avoid. (The
                                        Mercurial manual[1] is interesting on its comments on Git in this regard.) It
                                        seems the response to this from the Git side is that Mercurial is 'over
                                        engineered'. By the look of it, it's a matter of opinion, and I'd hesitate to
                                        definitively say one is better than the other, as even the experts seem to be divided.

                                        [1] http://hgbook.red-bean.com/ section 1.6.2.

                                        > Which of these are 'dangerous'?

                                        From what I can gather, the main useful thing that Git has that Mercurial simply
                                        doesn't is the 'rebase' feature, which is what I was referring to. It's a pretty
                                        non-contentious advantage of Git, since it has it and Mercurial doesn't, and it
                                        needn't be measured by real world experience like speed needs to be (and
                                        apparently comes out pretty similarly for the two) nor does it just come down to
                                        opinion (as the data model issue seems to). But it can lead to problems
                                        comparing/synchronising repositories, as is documented.

                                        Having now had a look at documentation for both projects, the Git docs are far
                                        from bad. I suspect this was remedied fairly recently.

                                        Ben.




                                        Send instant messages to your online friends http://au.messenger.yahoo.com


                                        --~--~---------~--~----~------------~-------~--~----~
                                        You received this message from the "vim_mac" maillist.
                                        For more information, visit http://www.vim.org/maillist.php
                                        -~----------~----~----~----~------~----~------~--~---
                                      • Tim Allen
                                        ... I think you re referring to the on-disk repository format; I agree that there are both pros and cons to Git s and Mercurial s approaches here. I was
                                        Message 19 of 27 , Oct 10, 2007
                                        • 0 Attachment
                                          On Oct 10, 5:16 pm, Ben Schmidt <mail_ben_schm...@...> wrote:
                                          > > The advantages I feel Git has over Mercurial include:
                                          > > - A better-designed basic data model (the entire repository in one
                                          > > directory, with tags and branches being "pointers" to different parts
                                          > > of the history tree)
                                          > > - Speed
                                          >
                                          > From what I've read, neither of these seem to be clear advantages of one over the
                                          > other. My understanding is that Mercurial was developed partly because the backend
                                          > data model of Git was felt by some to be less than ideal. Being not too well
                                          > optimised also leads to speed problems which Mercurial was trying to avoid.

                                          I think you're referring to the on-disk repository format; I agree
                                          that there are both pros and cons to Git's and Mercurial's approaches
                                          here. I was thinking more of Mercurial's decision to track tags in a
                                          versioned file in the repository rather than Git's approach of tags
                                          being external to the repository history. This decision has some
                                          surprising consequences, whose workarounds have their own surprising
                                          consequences[3], none of which affect Git.

                                          > (The Mercurial manual[1] is interesting on its comments on Git in this regard.)

                                          Having read that section of the Mercurial manual[2], I'd have to say
                                          it's pretty fair except that (a) counting all the internal back-end-
                                          only commands and useful add-ons as part of the core command set is a
                                          bit inflammatory, and (b) Git *does* in fact have a nice User Manual,
                                          as I've linked elsewhere in this thread.

                                          > > Which of these are 'dangerous'?
                                          >
                                          > From what I can gather, the main useful thing that Git has that Mercurial simply
                                          > doesn't is the 'rebase' feature, which is what I was referring to. It's a pretty
                                          > non-contentious advantage of Git, since it has it and Mercurial doesn't, and it
                                          > needn't be measured by real world experience like speed needs to be (and
                                          > apparently comes out pretty similarly for the two) nor does it just come down to
                                          > opinion (as the data model issue seems to). But it can lead to problems
                                          > comparing/synchronising repositories, as is documented.

                                          Fair enough!

                                          [1] Not my footnote
                                          [2] Specifically here: http://hgbook.red-bean.com/hgbookch1.html#x5-200001.6.2
                                          [3] See http://hgbook.red-bean.com/hgbookch8.html#x12-1570008.1.1 and
                                          following.


                                          --~--~---------~--~----~------------~-------~--~----~
                                          You received this message from the "vim_mac" maillist.
                                          For more information, visit http://www.vim.org/maillist.php
                                          -~----------~----~----~----~------~----~------~--~---
                                        • Nico Weber
                                          ... At the moment, simply using git-svn is a bit cumbersome, because the MacVim google code project doesn t include the core vim source, but a diff between
                                          Message 20 of 27 , Oct 10, 2007
                                          • 0 Attachment
                                            > I would second the git-svn approach... git-svn allows for a
                                            > transparent
                                            > view of a Subversion repository and also can commit directly back
                                            > to it.
                                            > Done right, no one would know patches would be coming from git.
                                            > (However,
                                            > publishing the git repository would give that away :)

                                            At the moment, simply using git-svn is a bit cumbersome, because the
                                            MacVim google code project doesn't include the core vim source, but a
                                            diff between core vim and MacVim's modified core vim. This means:

                                            1. To create your local repo, you have to use git-svn to mirror the
                                            core vim source, and then use git-svn again to get the MacVim repo.
                                            After that, you have to get the core vim diff and apply it to your repo.

                                            2. To update your repo, you have to unapply the patch to vim core,
                                            update the two repos, get the new MacVim patch to vim core and
                                            reapply it.

                                            3. To send out diffs, you have to have a feature branch on vim core,
                                            so that the diff doesn't include the "official" MacVim diff

                                            I had the impression Bjorn wanted to make this a bit easier. What
                                            _would_ make this easier is if there was a single MacVim repo that
                                            included vim core with the MacVims modifications as well as MacVim
                                            proper, and if this repo was synced from the official vim core svn
                                            every now and then. Do I understand this correctly so far?


                                            The above is not easily possible with git-svn alone, because everyone
                                            would need to track several repos (except if the official MacVim svn
                                            repo would include core vim -- but that's about as much work as
                                            creating a new repo, so why now switch to a better alternative (dvcs)
                                            in the process).

                                            Now, it doesn't really matter _how_ this happens. Bjorn suggested git
                                            and Bram suggested git or hg. Bjorn said: "If you have any
                                            _constructive_ comments regarding this move ...". In my eyes this
                                            doesn't say "please suggest as many distributed version control
                                            systems as you can think of". I'm sure they're all cool programs, and
                                            nobody like to learn a different system than the one he already knows
                                            and loves, but that's not what this is about.


                                            The question really is: Are there any showstoppers for using git? As
                                            far as I see it, it _is_ a dvcs, and it has git-svn, which makes
                                            syncing vim core easy. It's well documented, and it Just Works on the
                                            mac (yeah, you have to use the terminal and it doesn't have XCode
                                            integration. Big deal. You need the terminal to build core vim
                                            anyways, and if you're hacking on vim, chances are that you edit your
                                            code in vim and use xcodebuild to compile ;-) ).


                                            About all the perceived advantages of other solutions: Speed
                                            differences don't really matter, vim's code base is quite small. I
                                            don't think we have to worry about that. And windows compatibility?
                                            This is the vim_mac list, and we're talking about something to make
                                            life easier for people who want to work on MacVim.

                                            </rant>
                                            Nico

                                            --~--~---------~--~----~------------~-------~--~----~
                                            You received this message from the "vim_mac" maillist.
                                            For more information, visit http://www.vim.org/maillist.php
                                            -~----------~----~----~----~------~----~------~--~---
                                          • björn
                                            ... Yes. My thought was that I create a git repo, let people pull from that and I ll take care of the nasty business of syncing with the MacVim svn repo as
                                            Message 21 of 27 , Oct 10, 2007
                                            • 0 Attachment
                                              > At the moment, simply using git-svn is a bit cumbersome, because the
                                              > MacVim google code project doesn't include the core vim source, but a
                                              > diff between core vim and MacVim's modified core vim. This means:
                                              >
                                              > 1. To create your local repo, you have to use git-svn to mirror the
                                              > core vim source, and then use git-svn again to get the MacVim repo.
                                              > After that, you have to get the core vim diff and apply it to your repo.
                                              >
                                              > 2. To update your repo, you have to unapply the patch to vim core,
                                              > update the two repos, get the new MacVim patch to vim core and
                                              > reapply it.
                                              >
                                              > 3. To send out diffs, you have to have a feature branch on vim core,
                                              > so that the diff doesn't include the "official" MacVim diff
                                              >
                                              > I had the impression Bjorn wanted to make this a bit easier. What
                                              > _would_ make this easier is if there was a single MacVim repo that
                                              > included vim core with the MacVims modifications as well as MacVim
                                              > proper, and if this repo was synced from the official vim core svn
                                              > every now and then. Do I understand this correctly so far?

                                              Yes. My thought was that I create a git repo, let people pull from
                                              that and I'll take care of the nasty business of syncing with the
                                              MacVim svn repo as well as creating patches for the Vim repo. I was
                                              hoping there would be some kind of functionality in Git that would
                                              make this easy (or not too hard) for me. But the main point is to
                                              make it easier for contributors (for me it would eventually become
                                              routine anyway).

                                              > The above is not easily possible with git-svn alone, because everyone
                                              > would need to track several repos (except if the official MacVim svn
                                              > repo would include core vim -- but that's about as much work as
                                              > creating a new repo, so why now switch to a better alternative (dvcs)
                                              > in the process).

                                              Exactly.

                                              > Now, it doesn't really matter _how_ this happens. Bjorn suggested git
                                              > and Bram suggested git or hg. Bjorn said: "If you have any
                                              > _constructive_ comments regarding this move ...". In my eyes this
                                              > doesn't say "please suggest as many distributed version control
                                              > systems as you can think of". I'm sure they're all cool programs, and
                                              > nobody like to learn a different system than the one he already knows
                                              > and loves, but that's not what this is about.

                                              Thank you Nico. At least you and I are speaking the same language.

                                              > The question really is: Are there any showstoppers for using git? As
                                              > far as I see it, it _is_ a dvcs, and it has git-svn, which makes
                                              > syncing vim core easy. It's well documented, and it Just Works on the
                                              > mac (yeah, you have to use the terminal and it doesn't have XCode
                                              > integration. Big deal. You need the terminal to build core vim
                                              > anyways, and if you're hacking on vim, chances are that you edit your
                                              > code in vim and use xcodebuild to compile ;-) ).

                                              Again, I agree. The point here is not to create a repo to replace the
                                              Vim svn repo, it is to create a MacVim distributed repo which will
                                              enable people to hack away on MacVim. At the moment this is just way
                                              too difficult. Which tool to use is not important as long as it does
                                              the job.

                                              > About all the perceived advantages of other solutions: Speed
                                              > differences don't really matter, vim's code base is quite small. I
                                              > don't think we have to worry about that. And windows compatibility?
                                              > This is the vim_mac list, and we're talking about something to make
                                              > life easier for people who want to work on MacVim.

                                              Not to mention the fact that Bram is the maintainer of Vim, not me.
                                              He already has his routine in place for dealing with Vim patches. He
                                              doesn't need me to set up another repo or anything. This talk about
                                              Git for MacVim is exactly that, and nothing more (e.g. Windows is
                                              irrelevant).

                                              At the moment I am reading up on Git and it looks promising. These
                                              are the kind of things I need to be able to do:

                                              1. import the Vim and MacVim svn repos
                                              2. give others access to my repo so that contributors can pull from it
                                              3. pull contributors work to my branch
                                              4. make patches for the Vim svn repo
                                              5. update the MacVim svn repo with my branch

                                              Also, I am trying to figure out the typical work-flow for somebody
                                              wishing to contribute once I have a Git repo set up.

                                              I also intend to read about Mercurial, but at the moment I doubt that
                                              I can be bothered looking around much more.


                                              /Björn

                                              --~--~---------~--~----~------------~-------~--~----~
                                              You received this message from the "vim_mac" maillist.
                                              For more information, visit http://www.vim.org/maillist.php
                                              -~----------~----~----~----~------~----~------~--~---
                                            • björn
                                              ... I forgot something essential: 2.5. merge updates from the Vim svn repo into my git repo So that people who pull from my git repo always gets the latest of
                                              Message 22 of 27 , Oct 10, 2007
                                              • 0 Attachment
                                                > At the moment I am reading up on Git and it looks promising. These
                                                > are the kind of things I need to be able to do:
                                                >
                                                > 1. import the Vim and MacVim svn repos
                                                > 2. give others access to my repo so that contributors can pull from it
                                                > 3. pull contributors work to my branch
                                                > 4. make patches for the Vim svn repo
                                                > 5. update the MacVim svn repo with my branch

                                                I forgot something essential:

                                                2.5. merge updates from the Vim svn repo into my git repo

                                                So that people who pull from my git repo always gets the latest of
                                                both the Vim source and the MacVim source.


                                                /Björn

                                                --~--~---------~--~----~------------~-------~--~----~
                                                You received this message from the "vim_mac" maillist.
                                                For more information, visit http://www.vim.org/maillist.php
                                                -~----------~----~----~----~------~----~------~--~---
                                              • björn
                                                ... Argh. I just re-read that last sentence only to realize that it sounded kind of arrogant. A lot of the responses were interesting (thanks for the links
                                                Message 23 of 27 , Oct 10, 2007
                                                • 0 Attachment
                                                  > > Now, it doesn't really matter _how_ this happens. Bjorn suggested git
                                                  > > and Bram suggested git or hg. Bjorn said: "If you have any
                                                  > > _constructive_ comments regarding this move ...". In my eyes this
                                                  > > doesn't say "please suggest as many distributed version control
                                                  > > systems as you can think of". I'm sure they're all cool programs, and
                                                  > > nobody like to learn a different system than the one he already knows
                                                  > > and loves, but that's not what this is about.
                                                  >
                                                  > Thank you Nico. At least you and I are speaking the same language.

                                                  Argh. I just re-read that last sentence only to realize that it
                                                  sounded kind of arrogant. A lot of the responses were interesting
                                                  (thanks for the links in particular) and I did not mean it to sound
                                                  like I thought all other posts were stupid. My apologies.

                                                  Anyway, lets try to focus on exactly how to set up some kind of VCS so
                                                  that it becomes easy to fool around with private branches. If anybody
                                                  has any actual experience with setting up and maintaining a
                                                  distributed VCS repository then maybe you can give me some pointers on
                                                  how best to handle this. Otherwise I'll just keep trudging through
                                                  the various docs and try to figure it out myself.


                                                  Thanks,
                                                  Björn


                                                  --~--~---------~--~----~------------~-------~--~----~
                                                  You received this message from the "vim_mac" maillist.
                                                  For more information, visit http://www.vim.org/maillist.php
                                                  -~----------~----~----~----~------~----~------~--~---
                                                • Tim Allen
                                                  ... I currently have on my hard-disk a Git repository that is set up to automatically pull updates from the Vim SVN repo and from the MacVim SVN repo, merge
                                                  Message 24 of 27 , Oct 11, 2007
                                                  • 0 Attachment
                                                    On Oct 11, 5:16 am, "björn" <bjorn.winck...@...> wrote:
                                                    > > 1. import the Vim and MacVim svn repos

                                                    I currently have on my hard-disk a Git repository that is set up to
                                                    automatically pull updates from the Vim SVN repo and from the MacVim
                                                    SVN repo, merge them, and keep the MacVim-patches-to-Vim intact.

                                                    Unfortunately, xcodebuild doesn't. There's no way to merge one branch
                                                    in as a subdirectory of another branch, so the MacVim build
                                                    instructions that say things like "copy ../Vim into the bundle" and
                                                    "copy ../../runtime into the bundle" don't work when the paths in
                                                    question are "./src/vim" and "./runtime".

                                                    I also wrote down what I did to set up that git-repository, so I have
                                                    instructions if somebody else wants to try (alternately, I can tar up
                                                    the 15MB repository I have and save people two hours of importing the
                                                    Vim SVN repo).

                                                    > > 2. give others access to my repo so that contributors can pull from it

                                                    I wonder if you need to do this *and* keep the MacVim SVN repository
                                                    up-to-date...

                                                    There are three main ways to share a Git repository:

                                                    - via ordinary HTTP (read-only), as long as you run git-update-server-
                                                    repo on the repository after each update.
                                                    - via ssh (read-only or ssh-authenticated read-write), as long as you
                                                    give people accounts on the server (you can use git-shell to make this
                                                    more secure, but they're still shell accounts)
                                                    - via git-daemon (read-only or unauthenticated read-write), as you
                                                    leave the correct port open in your firewall.

                                                    Probably the easiest thing is to get hosting from http://repo.or.cz,
                                                    who'll set you up with all three access methods (read-write ssh for
                                                    you, read-only git and http for everybody else) and a nifty web front-
                                                    end.

                                                    > 2.5. merge updates from the Vim svn repo into my git repo

                                                    My repository set up works like this:

                                                    $ git-svn fetch upstream-vim
                                                    $ git-svn fetch upstream-macvim
                                                    $ git-checkout master # or whatever your working branch is called
                                                    $ git-merge upstream-vim/trunk
                                                    $ git-merge upstream-macvim/trunk

                                                    > > 3. pull contributors work to my branch

                                                    If the contributor has a publicly-available Git repo:

                                                    $ git-remote add JoeContributor git://git.example.com/macvim/
                                                    $ git-remote update
                                                    $ git-checkout master # or whatever your working branch is called
                                                    $ git-merge JoeContributor/master # or whatever his working branch is
                                                    called

                                                    Note that the git project itself hardly ever does this - most
                                                    contributions are submitted in the form of patches emailed to the git
                                                    list. Git comes with tools to make this behaviour super efficient: git-
                                                    format-patch will take a set of changes, format them as emails and
                                                    (optionally) squirt them at your chosen email address, while git-am
                                                    takes an mbox- or Maildir-formatted mailbox of patches and
                                                    sequentially applies them to your current branch.

                                                    > > 4. make patches for the Vim svn repo
                                                    > > 5. update the MacVim svn repo with my branch

                                                    I think the trickiest bit will be filtering your local branch to
                                                    distinguish:
                                                    - Changes to MacVim that need to be sent to the MacVim SVN.
                                                    - Changes to Vim that need to be sent to Bram.
                                                    - Changes to Vim that need to *not* be sent to Bram.

                                                    Filtering on path-name would certainly help here (changes in src/ or
                                                    runtime/ are not MacVim changes) but distinguishing Vim changes that
                                                    should be sent upstream from changes that shouldn't be sent upstream
                                                    probably requires manual examination.


                                                    --~--~---------~--~----~------------~-------~--~----~
                                                    You received this message from the "vim_mac" maillist.
                                                    For more information, visit http://www.vim.org/maillist.php
                                                    -~----------~----~----~----~------~----~------~--~---
                                                  • björn
                                                    Hi Tim, Thanks for all that very useful information. ... Please send me your notes, that would be very helpful. ... Probably not, no. All I need to be able to
                                                    Message 25 of 27 , Oct 11, 2007
                                                    • 0 Attachment
                                                      Hi Tim,

                                                      Thanks for all that very useful information.

                                                      > I also wrote down what I did to set up that git-repository, so I have
                                                      > instructions if somebody else wants to try (alternately, I can tar up
                                                      > the 15MB repository I have and save people two hours of importing the
                                                      > Vim SVN repo).

                                                      Please send me your notes, that would be very helpful.


                                                      > > > 2. give others access to my repo so that contributors can pull from it
                                                      >
                                                      > I wonder if you need to do this *and* keep the MacVim SVN repository
                                                      > up-to-date...

                                                      Probably not, no. All I need to be able to do is to pull from the Vim
                                                      SVN repo...I could probably ditch the MacVim SVN repo.


                                                      > There are three main ways to share a Git repository:
                                                      >
                                                      > - via ordinary HTTP (read-only), as long as you run git-update-server-
                                                      > repo on the repository after each update.
                                                      > - via ssh (read-only or ssh-authenticated read-write), as long as you
                                                      > give people accounts on the server (you can use git-shell to make this
                                                      > more secure, but they're still shell accounts)
                                                      > - via git-daemon (read-only or unauthenticated read-write), as you
                                                      > leave the correct port open in your firewall.
                                                      >
                                                      > Probably the easiest thing is to get hosting from http://repo.or.cz,
                                                      > who'll set you up with all three access methods (read-write ssh for
                                                      > you, read-only git and http for everybody else) and a nifty web front-
                                                      > end.

                                                      Yes, that is what I thought as well. If I put my "official" git repo
                                                      there people could pull from it and we'll just retire the ole' svn
                                                      repo.


                                                      > > > 3. pull contributors work to my branch
                                                      >
                                                      > If the contributor has a publicly-available Git repo:
                                                      >
                                                      > $ git-remote add JoeContributor git://git.example.com/macvim/
                                                      > $ git-remote update
                                                      > $ git-checkout master # or whatever your working branch is called
                                                      > $ git-merge JoeContributor/master # or whatever his working branch is
                                                      > called
                                                      >
                                                      > Note that the git project itself hardly ever does this - most
                                                      > contributions are submitted in the form of patches emailed to the git
                                                      > list. Git comes with tools to make this behaviour super efficient: git-
                                                      > format-patch will take a set of changes, format them as emails and
                                                      > (optionally) squirt them at your chosen email address, while git-am
                                                      > takes an mbox- or Maildir-formatted mailbox of patches and
                                                      > sequentially applies them to your current branch.

                                                      I think we could probably employ the "patch-over-email" system as well.


                                                      > > > 4. make patches for the Vim svn repo
                                                      > > > 5. update the MacVim svn repo with my branch
                                                      >
                                                      > I think the trickiest bit will be filtering your local branch to
                                                      > distinguish:
                                                      > - Changes to MacVim that need to be sent to the MacVim SVN.
                                                      > - Changes to Vim that need to be sent to Bram.
                                                      > - Changes to Vim that need to *not* be sent to Bram.
                                                      >
                                                      > Filtering on path-name would certainly help here (changes in src/ or
                                                      > runtime/ are not MacVim changes) but distinguishing Vim changes that
                                                      > should be sent upstream from changes that shouldn't be sent upstream
                                                      > probably requires manual examination.

                                                      I'm not sure this works, but maybe I could have one branch with the
                                                      latest Vim SVN code unmodified and diff my working branch against
                                                      this. Hmmm...I'd probably still have to filter on path names. Ah
                                                      well.

                                                      Again, thanks a lot for the information.


                                                      /Björn

                                                      --~--~---------~--~----~------------~-------~--~----~
                                                      You received this message from the "vim_mac" maillist.
                                                      For more information, visit http://www.vim.org/maillist.php
                                                      -~----------~----~----~----~------~----~------~--~---
                                                    • vivacarlie
                                                      another host for git is savana.gnu.org. They also allow git as the scm but i don t know what services they offer in that respect.
                                                      Message 26 of 27 , Oct 11, 2007
                                                      • 0 Attachment
                                                        another host for git is savana.gnu.org. They also allow git as the scm
                                                        but i don't know what services they offer in that respect.


                                                        --~--~---------~--~----~------------~-------~--~----~
                                                        You received this message from the "vim_mac" maillist.
                                                        For more information, visit http://www.vim.org/maillist.php
                                                        -~----------~----~----~----~------~----~------~--~---
                                                      • Tim Allen
                                                        On 12/10/2007, björn wrote: I also wrote down what I did to set up that git-repository, so I have instructions if somebody
                                                        Message 27 of 27 , Oct 11, 2007
                                                        • 0 Attachment
                                                          On 12/10/2007, björn <bjorn.winckler@...> wrote:
                                                          > > I also wrote down what I did to set up that git-repository, so I have
                                                          > > instructions if somebody else wants to try (alternately, I can tar up
                                                          > > the 15MB repository I have and save people two hours of importing the
                                                          > > Vim SVN repo).
                                                          >
                                                          > Please send me your notes, that would be very helpful.

                                                          Attached. Note that the procedure is slightly more complicated than
                                                          strictly necessary, since it uses git-svn to import both the Vim and
                                                          MacVim repositories to enable pushing changes to both of them. If you
                                                          don't need to push changes to the MacVim repository, you could just
                                                          import it once with git-svnimport. I experimented with this a little
                                                          myself, but it seemed to be taking a lot longer than git-svn did.

                                                          > > I think the trickiest bit will be filtering your local branch to
                                                          > > distinguish:
                                                          > > - Changes to MacVim that need to be sent to the MacVim SVN.
                                                          > > - Changes to Vim that need to be sent to Bram.
                                                          > > - Changes to Vim that need to *not* be sent to Bram.
                                                          > >
                                                          > > Filtering on path-name would certainly help here (changes in src/ or
                                                          > > runtime/ are not MacVim changes) but distinguishing Vim changes that
                                                          > > should be sent upstream from changes that shouldn't be sent upstream
                                                          > > probably requires manual examination.
                                                          >
                                                          > I'm not sure this works, but maybe I could have one branch with the
                                                          > latest Vim SVN code unmodified and diff my working branch against
                                                          > this.

                                                          That's what my instructions set up, yes.

                                                          > Hmmm...I'd probably still have to filter on path names. Ah
                                                          > well.

                                                          I guess the most practical advice would be to get into the habit of
                                                          committing early and often while you code; that way you've got a
                                                          better chance of changes-destined-for-upstream being separate from
                                                          changes-only-for-MacVim.

                                                          > Again, thanks a lot for the information.

                                                          Glad to help!

                                                          --~--~---------~--~----~------------~-------~--~----~
                                                          You received this message from the "vim_mac" maillist.
                                                          For more information, visit http://www.vim.org/maillist.php
                                                          -~----------~----~----~----~------~----~------~--~---
                                                        Your message has been successfully submitted and would be delivered to recipients shortly.