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

Re: Vim development process is utterly broken (Was: Re: [patch] test98 stops when using gvim)

Expand Messages
  • ZyX
    I would vote against any development process that uses patches, be it current one, suggested two-eye system or anything else. The two-eye system looks
    Message 1 of 27 , Jul 15, 2013
    • 0 Attachment
      I would vote against any development process that uses patches, be it current one, suggested two-eye system or anything else.

      The two-eye system looks reasonable, but it should be applied to PR’s (commit series requested for inclusion as a whole) and not patches:


      This is how we can protect from partial application of the patch and any possible problems with encoding, empty files or whatever which may happen on reviewers machines. Pulling is more predictable, mercurial is known to pull or, in rare cases, not to pull (e.g. when there are problems with plugins, enabled on server, but not on client or too old mercurial version on one side) without any possible states in between.

      This is how we can protect from false commit messages (like the one where I was blamed for fixing some two problems in python tests while I actually said the opposite: these two problems are the only ones that are still not fixed). Patches do not have messages attached. Messages from Bram are also known to constantly include bits of information which seem not essential for me and omitting essential ones. It does not mean they are always inessential and Bram is completely wrong: e.g. pyeval() has proved to be more useful then I though when writing it, though vim.bindeval seemed more essential. But I have more details for this reason and they are always omitted.

      Word about keeping context and seeing whether patch can be automatically merged was already said.

      This also enables normal annotate and log: with current commit messages format almost every bit of useful data is stripped from annotate and log (without -v) output: no user, shortened commit message is useless as it says only about vim version. Problem/solution is too verbose, no summary in the first line. Most developers will write this in their messages thus these features will work regardless of what is written in the merge message.

      This is also how one can easily see which parts were included by Bram unmodified and which ones were modified (e.g. to fit coding style). This makes me learn about what should I be aware of when writing patches.


      I cannot say what are the advantages for Bram regarding simplicity of the process without knowing how he does his job, but with PR’s at least problems with omitting parts of the patches and noise about wrong commit messages will go away. In addition to noise about not using DVCS as DVCS and broken development process. I cannot think of any sanely written script that may modify my patch to leave one parenthesis as-is (like it was done recently), thus I assume 1. job of applying patches is done manually and 2. manually taking patches out of the messages is hard enough to apply smaller ones by hand. Do not know about bitbucket (did not ever received PR’s here), but with github (assuming Bram does not want to switch context from mailer to browser) merging basically is “copy command from email message to shell and run it”. Reviewing the diff is “open URL (under ‘Patch links’ section) in Vim and review” (since vim is capable for opening https:// links). I hope bitbucket has something like this.

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Ben Fritz
      ... Since we re using Mercurial, and Bram wants to allow email submissions, a developer can email a bundle if he/she doesn t have/want access to a public
      Message 2 of 27 , Jul 15, 2013
      • 0 Attachment
        On Monday, July 15, 2013 9:31:00 AM UTC-5, ZyX wrote:
        > I would vote against any development process that uses patches, be it current one, suggested two-eye system or anything else.
        >
        >
        >
        > The two-eye system looks reasonable, but it should be applied to PR’s (commit series requested for inclusion as a whole) and not patches:
        >
        >
        >
        >
        >
        > This is how we can protect from partial application of the patch and any possible problems with encoding, empty files or whatever which may happen on reviewers machines.

        Since we're using Mercurial, and Bram wants to allow email submissions, a developer can email a "bundle" if he/she doesn't have/want access to a public repository. Then just the commits required for the fix (with some commit also in Bram's repository as a parent) need to be emailed, and he can import or pull from the bundle.

        I'm not altogether opposed to using patches for an initial solution, but at some point the patch needs to go into a real commit so people can review it BEFORE it gets released officially.

        I think using rebase risks some of the same problems that patches have, so a completely linear history may be harder to keep. But, Bram can at least keep using a linear set of tagged revisions with nothing in between, by updating the version.c version number and applying a tag after every merge he intends to publish.

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • George V. Reilly
        ... (It s been a while since I ve been an active contributor, but I still lurk here and read some of the threads.) Using a proper DVCS workflow is far superior
        Message 3 of 27 , Jul 15, 2013
        • 0 Attachment
          On Mon, Jul 15, 2013 at 7:31 AM, ZyX <zyx.vim@...> wrote:
          > I would vote against any development process that uses patches, be it
          > current one, suggested two-eye system or anything else.
          >
          > The two-eye system looks reasonable, but it should be applied to PR’s
          > (commit series requested for inclusion as a whole) and not patches:
          >
          > This is how we can protect from partial application of the patch and
          > any possible problems with encoding, empty files or whatever which may
          > happen on reviewers machines. Pulling is more predictable, mercurial
          > is known to pull or, in rare cases, not to pull (e.g. when there are
          > problems with plugins, enabled on server, but not on client or too old
          > mercurial version on one side) without any possible states in between.
          >
          > This is how we can protect from false commit messages (like the one
          > where I was blamed for fixing some two problems in python tests while
          > I actually said the opposite: these two problems are the only ones
          > that are still not fixed). Patches do not have messages attached.
          > Messages from Bram are also known to constantly include bits of
          > information which seem not essential for me and omitting essential
          > ones. It does not mean they are always inessential and Bram is
          > completely wrong: e.g. pyeval() has proved to be more useful then I
          > though when writing it, though vim.bindeval seemed more essential. But
          > I have more details for this reason and they are always omitted.
          >
          > Word about keeping context and seeing whether patch can be
          > automatically merged was already said.
          >
          > This also enables normal annotate and log: with current commit
          > messages format almost every bit of useful data is stripped from
          > annotate and log (without -v) output: no user, shortened commit
          > message is useless as it says only about vim version. Problem/solution
          > is too verbose, no summary in the first line. Most developers will
          > write this in their messages thus these features will work regardless
          > of what is written in the merge message.
          >
          > This is also how one can easily see which parts were included by Bram
          > unmodified and which ones were modified (e.g. to fit coding style).
          > This makes me learn about what should I be aware of when writing
          > patches.
          >
          > I cannot say what are the advantages for Bram regarding simplicity of
          > the process without knowing how he does his job, but with PR’s at
          > least problems with omitting parts of the patches and noise about
          > wrong commit messages will go away. In addition to noise about not
          > using DVCS as DVCS and broken development process. I cannot think of
          > any sanely written script that may modify my patch to leave one
          > parenthesis as-is (like it was done recently), thus I assume 1. job of
          > applying patches is done manually and 2. manually taking patches out
          > of the messages is hard enough to apply smaller ones by hand. Do not
          > know about bitbucket (did not ever received PR’s here), but with
          > github (assuming Bram does not want to switch context from mailer to
          > browser) merging basically is “copy command from email message to
          > shell and run it”. Reviewing the diff is “open URL (under ‘Patch
          > links’ section) in Vim and review” (since vim is capable for opening
          > https:// links). I hope bitbucket has something like this.

          (It's been a while since I've been an active contributor, but I still
          lurk here and read some of the threads.)

          Using a proper DVCS workflow is far superior to having one BDFL manually
          apply patches. That was the best we could do in the 1990s; we have
          better choices now. For more than a year at the day job, we've been
          using Github Pull Requests to manage how features are merged onto the
          master branch of our various repositories. We get an easy way of code
          reviewing, automated test results from our continuous integration
          server, an audit trail, and a rarely-needed mechanism for reverting.
          Between our various repos, our team of 15 engineers has opened (and
          closed) almost 1,000 pull requests. It's a successful workflow.

          Bitbucket also has Pull Requests [1], though I haven't worked with them.
          Google Code does not [2].

          1: https://confluence.atlassian.com/display/BITBUCKET/Work+with+pull+requests
          2: https://code.google.com/p/support/issues/detail?id=4753
          --
          /George V. Reilly george@... Twitter: @georgevreilly
          http://www.georgevreilly.com/blog http://blogs.cozi.com/tech

          --
          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • ZyX
          ... Bundles solve exactly one problem: they avoid problems with applying patches. They do introduce another problem: now it is tricky to see the diff (any
          Message 4 of 27 , Jul 15, 2013
          • 0 Attachment
            > Since we're using Mercurial, and Bram wants to allow email submissions, a developer can email a "bundle" if he/she doesn't have/want access to a public repository. Then just the commits required for the fix (with some commit also in Bram's repository as a parent) need to be emailed, and he can import or pull from the bundle.

            Bundles solve exactly one problem: they avoid problems with applying patches. They do introduce another problem: now it is tricky to see the diff (any discussion around PR’s assumes having web interface for them). With bundles one still needs to repost each time he has an update (common for emailed bundles and diff).

            > I'm not altogether opposed to using patches for an initial solution, but at some point the patch needs to go into a real commit so people can review it BEFORE it gets released officially.
            >
            > I think using rebase risks some of the same problems that patches have, so a completely linear history may be harder to keep. But, Bram can at least keep using a linear set of tagged revisions with nothing in between, by updating the version.c version number and applying a tag after every merge he intends to publish.

            It is part of what (a successful) git-flow model suggests. As far as I see git-flow suits perfectly for mercurial as well.

            Note that rebasing of a commit from third-party source is tricky because mercurial uses phases for preventing you from doing such mistake.

            --
            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • glts
            I recently had an encounter with the dev process used for Go. They use Mercurial with the Rietveld code review extension. Every change must be submitted for
            Message 5 of 27 , Jul 15, 2013
            • 0 Attachment
              I recently had an encounter with the dev process used for Go. They use
              Mercurial with the Rietveld code review extension. Every change must be
              submitted for public review first and needs explicit approval from the
              devs/community before receiving an LGTM ("looks good to me") and commit.

              I found it pretty impressive, might be worth a look?
              https://groups.google.com/forum/#!forum/golang-dev
              https://codereview.appspot.com/

              Best,

              --
              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php

              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Ben Fritz
              ... No, the discussion only assumes that everyone can see the same changes. It s easy enough to get the changes into a personal clone on your system to view
              Message 6 of 27 , Jul 15, 2013
              • 0 Attachment
                On Monday, July 15, 2013 11:33:55 AM UTC-5, ZyX wrote:
                > > Since we're using Mercurial, and Bram wants to allow email submissions, a developer can email a "bundle" if he/she doesn't have/want access to a public repository. Then just the commits required for the fix (with some commit also in Bram's repository as a parent) need to be emailed, and he can import or pull from the bundle.
                >
                >
                >
                > Bundles solve exactly one problem: they avoid problems with applying patches. They do introduce another problem: now it is tricky to see the diff (any discussion around PR’s assumes having web interface for them).

                No, the discussion only assumes that everyone can see the same changes. It's easy enough to get the changes into a personal clone on your system to view them. That is an early step in merging and applying them anyway. I assume any changes merged in from pull requests must be tested before publishing.

                > With bundles one still needs to repost each time he has an update (common for emailed bundles and diff).
                >

                I view that as a good thing. You'll need to post anyway when you make an update, otherwise nobody knows about it unless they are following your repository very closely. If Bram has 12 pull requests, he probably won't want to monitor each repository to see if anything changes. So the pull requester must post to say "updated to fix XYZ". If the changes are immediately available in the email, the maintainer has less work left to do to get them.

                That said, I'd probably prefer to just pull from a public repository myself, if I knew the correct revision to pull in.

                --
                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php

                ---
                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • ZyX
                ... Before pulling into my clone I normally view diff to check out that it is worth pulling at all. Some problems do not need pulling to be discovered. ... ?!
                Message 7 of 27 , Jul 15, 2013
                • 0 Attachment
                  > > Bundles solve exactly one problem: they avoid problems with applying patches. They do introduce another problem: now it is tricky to see the diff (any discussion around PR’s assumes having web interface for them).
                  >

                  > No, the discussion only assumes that everyone can see the same changes. It's easy enough to get the changes into a personal clone on your system to view them. That is an early step in merging and applying them anyway. I assume any changes merged in from pull requests must be tested before publishing.

                  Before pulling into my clone I normally view diff to check out that it is worth pulling at all. Some problems do not need pulling to be discovered.

                  > > With bundles one still needs to repost each time he has an update (common for emailed bundles and diff).
                  >
                  > I view that as a good thing. You'll need to post anyway when you make an update, otherwise nobody knows about it unless they are following your repository very closely. If Bram has 12 pull requests, he probably won't want to monitor each repository to see if anything changes. So the pull requester must post to say "updated to fix XYZ". If the changes are immediately available in the email, the maintainer has less work left to do to get them.

                  ?! You don’t need to post, you need to push to a proper branch and it will appear in PR automatically. AFAIR github does not bother notifying in this case, dunno about bitbucket, but it would be good thing to do (I mean, notify about push into PR).

                  > That said, I'd probably prefer to just pull from a public repository myself, if I knew the correct revision to pull in.

                  Github mails you with a correct command to pull. Anybody here has an experience with bitbucket regarding pull requests?

                  --
                  --
                  You received this message from the "vim_dev" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php

                  ---
                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • Marc Weber
                  ... Link? I d like to add it to http://vim-wiki.mawercer.de/wiki/vim-development/recent-work.html If you come up with something know consider adding it to:
                  Message 8 of 27 , Jul 15, 2013
                  • 0 Attachment
                    > of contributors to vim-extended.
                    Link? I'd like to add it to
                    http://vim-wiki.mawercer.de/wiki/vim-development/recent-work.html

                    If you come up with something know consider adding it to:
                    http://vim-wiki.mawercer.de/wiki/vim-development/development.html

                    Should we start fund raising for development? Would this improve
                    anything?

                    Marc Weber

                    --
                    --
                    You received this message from the "vim_dev" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php

                    ---
                    You received this message because you are subscribed to the Google Groups "vim_dev" group.
                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                    For more options, visit https://groups.google.com/groups/opt_out.
                  • ZyX
                    ... ?! Where is my description on the main project page? -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below
                    Message 9 of 27 , Jul 15, 2013
                    • 0 Attachment
                      > Is heavily working on improving the Python API. His description about the changes: https://code.google.com/p/vim/

                      ?! Where is my description on the main project page?

                      --
                      --
                      You received this message from the "vim_dev" maillist.
                      Do not top-post! Type your reply below the text you are replying to.
                      For more information, visit http://www.vim.org/maillist.php

                      ---
                      You received this message because you are subscribed to the Google Groups "vim_dev" group.
                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                      For more options, visit https://groups.google.com/groups/opt_out.
                    • Marc Weber
                      ... Sry, fixed to: https://gist.github.com/ZyX-I/5561409 -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below
                      Message 10 of 27 , Jul 15, 2013
                      • 0 Attachment
                        > ?! Where is my description on the main project page?
                        Sry, fixed to: https://gist.github.com/ZyX-I/5561409

                        --
                        --
                        You received this message from the "vim_dev" maillist.
                        Do not top-post! Type your reply below the text you are replying to.
                        For more information, visit http://www.vim.org/maillist.php

                        ---
                        You received this message because you are subscribed to the Google Groups "vim_dev" group.
                        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                        For more options, visit https://groups.google.com/groups/opt_out.
                      • Ben Fritz
                        ... I have so far not been active enough in any open-source project to use the web-based tools for pull requests, so I admit ignorance in regard to how that
                        Message 11 of 27 , Jul 15, 2013
                        • 0 Attachment
                          On Monday, July 15, 2013 12:27:03 PM UTC-5, ZyX wrote:
                          > > > With bundles one still needs to repost each time he has an update (common for emailed bundles and diff).
                          > >
                          > > I view that as a good thing. You'll need to post anyway when you make an update, otherwise nobody knows about it unless they are following your repository very closely. If Bram has 12 pull requests, he probably won't want to monitor each repository to see if anything changes. So the pull requester must post to say "updated to fix XYZ". If the changes are immediately available in the email, the maintainer has less work left to do to get them.
                          >
                          > ?! You don’t need to post, you need to push to a proper branch and it will appear in PR automatically. AFAIR github does not bother notifying in this case, dunno about bitbucket, but it would be good thing to do (I mean, notify about push into PR).
                          >

                          I have so far not been active enough in any open-source project to use the web-based tools for pull requests, so I admit ignorance in regard to how that works. I have so far assumed it is mostly a streamlined way (with a nice interface) to do "please pull revision abc123 from my public repository at example.com/repo to get my changes for feature X". I.e. this is something that COULD be done manually but is more efficient with the GitHub/BitBucket interface.

                          I may have overlooked the idea that the maintainer should be looking at their own repository frequently enough to see that there is a pending pull request.

                          Nevertheless, I do NOT want to pull a PR which I assume has been reviewed completely, only to have a few recently-pushed changes "sneak in" without review. I do NOT want to monitor for updates to the pull request to know when a fix I request is complete, I want to be told "hey, I fixed that issue you found in review, try again". I do NOT want to do the pull request, then go to publish the result, only to discover that some last-minute changes were made after my pull and need to pull again.

                          Maybe it is just my ignorance showing; maybe the GitHub/BitBucket pull request concept is good enough to handle all that, but it seems like a good way to accomplish these things is a simple email to the list or maintainer saying "I updated pull request with revision abc123def to fix Jane Doe's review findings, it should be ready again".

                          And not everybody has or wants a GitHub account. I think email submissions are still good, for small changes at the very least.

                          My point was that it should be just as easy to say "I updated to fix Jane Doe's review findings, see attached bundle". Or even "see attached patch based off version 123fe56 in the main repo". With the bundle there is less opportunity for error than the patch.

                          --
                          --
                          You received this message from the "vim_dev" maillist.
                          Do not top-post! Type your reply below the text you are replying to.
                          For more information, visit http://www.vim.org/maillist.php

                          ---
                          You received this message because you are subscribed to the Google Groups "vim_dev" group.
                          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                          For more options, visit https://groups.google.com/groups/opt_out.
                        • Nikolay Pavlov
                          ... (common for emailed bundles and diff). ... an update, otherwise nobody knows about it unless they are following your repository very closely. If Bram has
                          Message 12 of 27 , Jul 15, 2013
                          • 0 Attachment


                            On Jul 15, 2013 11:22 PM, "Ben Fritz" <fritzophrenic@...> wrote:
                            >
                            > On Monday, July 15, 2013 12:27:03 PM UTC-5, ZyX wrote:
                            > > > > With bundles one still needs to repost each time he has an update (common for emailed bundles and diff).
                            > > >
                            > > > I view that as a good thing. You'll need to post anyway when you make an update, otherwise nobody knows about it unless they are following your repository very closely. If Bram has 12 pull requests, he probably won't want to monitor each repository to see if anything changes. So the pull requester must post to say "updated to fix XYZ". If the changes are immediately available in the email, the maintainer has less work left to do to get them.
                            > >
                            > > ?! You don’t need to post, you need to push to a proper branch and it will appear in PR automatically. AFAIR github does not bother notifying in this case, dunno about bitbucket, but it would be good thing to do (I mean, notify about push into PR).
                            > >
                            >
                            > I have so far not been active enough in any open-source project to use the web-based tools for pull requests, so I admit ignorance in regard to how that works. I have so far assumed it is mostly a streamlined way (with a nice interface) to do "please pull revision abc123 from my public repository at example.com/repo to get my changes for feature X". I.e. this is something that COULD be done manually but is more efficient with the GitHub/BitBucket interface.
                            >
                            > I may have overlooked the idea that the maintainer should be looking at their own repository frequently enough to see that there is a pending pull request.
                            >
                            > Nevertheless, I do NOT want to pull a PR which I assume has been reviewed completely, only to have a few recently-pushed changes "sneak in" without review. I do NOT want to monitor for updates to the pull request to know when a fix I request is complete, I want to be told "hey, I fixed that issue you found in review, try again". I do NOT want to do the pull request, then go to publish the result, only to discover that some last-minute changes were made after my pull and need to pull again.

                            Normally on both sides are reasonable people. One does not say PR is finished and add a new commit after this without notification unless he knows for sure when review is done. Though there also is a problem in github: I have same reasons to expect it to notify about changes, but it does not. Hope bitbucket does, but this needs to be tested.

                            > Maybe it is just my ignorance showing; maybe the GitHub/BitBucket pull request concept is good enough to handle all that, but it seems like a good way to accomplish these things is a simple email to the list or maintainer saying "I updated pull request with revision abc123def to fix Jane Doe's review findings, it should be ready again".

                            I did the same by posting to PR if I expected other side to miss changes (normally always after review had happened due to lack of notification). There now seems to be no advantage with github.

                            Bitbucket has approve button in PR, but pushing new changeset does not alter approval status. It also does not notify about any changes as I run PR from one my repository to the other and as I approve myself and also push changes by myself the actual problem may be that it tries to be smart and thus changes pushed by approver just do not alter approval status. Second person is needed for the test. It did not automatically add changes to PR in my simple test though.

                            Github does not have support for approving PRs.

                            > And not everybody has or wants a GitHub account. I think email submissions are still good, for small changes at the very least.

                            I actually do not want it on github, I would want it on bitbucket assuming it has comparable features. But as it being not so popular I have no experience with collaborative development there and cannot evaluate pros and cons for sure. Issue tracker is much better on bitbucket.

                            > My point was that it should be just as easy to say "I updated to fix Jane Doe's review findings, see attached bundle". Or even "see attached patch based off version 123fe56 in the main repo". With the bundle there is less opportunity for error than the patch.
                            >
                            > --
                            > --
                            > You received this message from the "vim_dev" maillist.
                            > Do not top-post! Type your reply below the text you are replying to.
                            > For more information, visit http://www.vim.org/maillist.php
                            >
                            > ---
                            > You received this message because you are subscribed to the Google Groups "vim_dev" group.
                            > To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                            > For more options, visit https://groups.google.com/groups/opt_out.
                            >
                            >

                            --
                            --
                            You received this message from the "vim_dev" maillist.
                            Do not top-post! Type your reply below the text you are replying to.
                            For more information, visit http://www.vim.org/maillist.php
                             
                            ---
                            You received this message because you are subscribed to the Google Groups "vim_dev" group.
                            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                            For more options, visit https://groups.google.com/groups/opt_out.
                             
                             
                          • Bram Moolenaar
                            ... Wasn t there a reason these commands were in a separate file? As mentioned before, we should have a test for the tests... -- Back off man, I m a scientist.
                            Message 13 of 27 , Jul 15, 2013
                            • 0 Attachment
                              Yukihiro Nakadaira wrote:

                              > How about this?
                              >
                              > I guess the key is ":setl scb | wincmd p", executing these two command
                              > in one normal_cmd() session.

                              Wasn't there a reason these commands were in a separate file?

                              As mentioned before, we should have a test for the tests...


                              --
                              Back off man, I'm a scientist.
                              -- Peter, Ghostbusters

                              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                              \\\ an exciting new programming language -- http://www.Zimbu.org ///
                              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                              --
                              --
                              You received this message from the "vim_dev" maillist.
                              Do not top-post! Type your reply below the text you are replying to.
                              For more information, visit http://www.vim.org/maillist.php

                              ---
                              You received this message because you are subscribed to the Google Groups "vim_dev" group.
                              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                              For more options, visit https://groups.google.com/groups/opt_out.
                            • Yukihiro Nakadaira
                              ... I think that the separate file was used for same purpose. -- Yukihiro Nakadaira - yukihiro.nakadaira@gmail.com -- -- You received this message from the
                              Message 14 of 27 , Jul 16, 2013
                              • 0 Attachment
                                On Tue, Jul 16, 2013 at 5:17 AM, Bram Moolenaar <Bram@...> wrote:

                                Yukihiro Nakadaira wrote:

                                > How about this?
                                >
                                > I guess the key is ":setl scb | wincmd p", executing these two command
                                > in one normal_cmd() session.

                                Wasn't there a reason these commands were in a separate file?

                                As mentioned before, we should have a test for the tests...

                                I think that the separate file was used for same purpose.

                                --
                                Yukihiro Nakadaira - yukihiro.nakadaira@...

                                --
                                --
                                You received this message from the "vim_dev" maillist.
                                Do not top-post! Type your reply below the text you are replying to.
                                For more information, visit http://www.vim.org/maillist.php
                                 
                                ---
                                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                For more options, visit https://groups.google.com/groups/opt_out.
                                 
                                 
                              • Bram Moolenaar
                                ... Sorry, I don t understand what you mean with same purpose . -- For large projects, Team Leaders use sophisticated project management software to keep
                                Message 15 of 27 , Jul 16, 2013
                                • 0 Attachment
                                  Yukihiro Nakadaira wrote:

                                  > On Tue, Jul 16, 2013 at 5:17 AM, Bram Moolenaar <Bram@...> wrote:
                                  >
                                  > >
                                  > > Yukihiro Nakadaira wrote:
                                  > >
                                  > > > How about this?
                                  > > >
                                  > > > I guess the key is ":setl scb | wincmd p", executing these two command
                                  > > > in one normal_cmd() session.
                                  > >
                                  > > Wasn't there a reason these commands were in a separate file?
                                  > >
                                  > > As mentioned before, we should have a test for the tests...
                                  >
                                  > I think that the separate file was used for same purpose.

                                  Sorry, I don't understand what you mean with "same purpose".

                                  --
                                  For large projects, Team Leaders use sophisticated project management software
                                  to keep track of who's doing what. The software collects the lies and guesses
                                  of the project team and organizes them in to instantly outdated charts that
                                  are too boring to look at closely. This is called "planning".
                                  (Scott Adams - The Dilbert principle)

                                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                                  /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                                  \\\ an exciting new programming language -- http://www.Zimbu.org ///
                                  \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                                  --
                                  --
                                  You received this message from the "vim_dev" maillist.
                                  Do not top-post! Type your reply below the text you are replying to.
                                  For more information, visit http://www.vim.org/maillist.php

                                  ---
                                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                  For more options, visit https://groups.google.com/groups/opt_out.
                                • Tony Mechelynck
                                  ... By a patch I mean what can serve as input to one run of the patch program, or what can become one new Mercurial changeset. In my mind, one patch can
                                  Message 16 of 27 , Jul 16, 2013
                                  • 0 Attachment
                                    On 07/15/13 16:31, ZyX wrote:
                                    > I would vote against any development process that uses patches, be it current one, suggested two-eye system or anything else.
                                    >
                                    > The two-eye system looks reasonable, but it should be applied to PR’s (commit series requested for inclusion as a whole) and not patches:

                                    By "a patch" I mean what can serve as input to one run of the "patch"
                                    program, or what can become one new Mercurial changeset. In my mind, one
                                    "patch" can include several (related) changes to different files, meant
                                    to be pushed together. See for example most patch-type attachments to
                                    bug reports at bugzilla.mozilla.org. Every patchlevel of Vim
                                    (corresponding currently to one line each after line 28 of
                                    ftp://ftp.vim.org/pub/vim/unstable/patches/7.4a/README ) is what I call
                                    "one patch".
                                    This is not like what you can do online at github, where it is not
                                    possible to modify several files in one commit, except by doing it in a
                                    clone on your HD then pushing over SSL (requiring a GPG passphrase, and
                                    I've forgotten mine), and where future bugfixes are committed as real
                                    changesets into "side branches" ("branches" in the git sense) of an
                                    online clone. At Mozilla, each patch (a diff of one or more files as
                                    kept in .hg/patch* by the mq extension) gets attached as a unified diff
                                    in git format to the concerned bug. A later version of a patch (in diff
                                    format) may "obsolete" a previous one; then when the final version of a
                                    patch has received the necessary reviews (and possibly superreview,
                                    approval, etc.) the patch author (who is often not a member of the
                                    select group of people which push access to the Mercurial repo) sets the
                                    "checkin-needed" keyword on the bug, and someone else, maybe a Mozilla
                                    employee or volunteer, but with push access, who periodically runs a
                                    search for open bugs having that keyword, will import that patch into
                                    his own clone (using the mq extension), check that it applies cleanly,
                                    that it has the necessary metadata (e.g. an author name, a Subject
                                    starting with a bug number, the names or IRC nicks of who gave the r+
                                    (review) and maybe ui-r+ (UI review), sr+ (superreview) and/or a+
                                    (approval) checks, etc. Then if the patch is OK he will commit it, for
                                    SeaMonkey or Thunderbird to the comm-central repo, for Firefox often to
                                    the mozilla-inbound repo, which gets merged into the mozilla-central
                                    repo maybe once a day or so, when "the tree is green", i.e., the code
                                    currently committed not only compiles and links, but passes all
                                    automatic tests on all platforms (Win32, Lin32, Lin64 and Mac-Universal).

                                    >
                                    >
                                    > This is how we can protect from partial application of the patch and any possible problems with encoding, empty files or whatever which may happen on reviewers machines. Pulling is more predictable, mercurial is known to pull or, in rare cases, not to pull (e.g. when there are problems with plugins, enabled on server, but not on client or too old mercurial version on one side) without any possible states in between.

                                    To address the possibility of bit-rot, the patch author should refresh
                                    his clone before every change, as well as when requesting
                                    checkin-needed. Use of the mq extension to Mercurial is IMHO strongly
                                    recommended, so that a patch can be developed, compiled, tested, and yet
                                    popped off the clone when desired (e.g. while pulling updates from the
                                    master repo).

                                    I also use the mq extension to import patches written by others which I
                                    want to test, so that no patch pollutes my clone's history before I've
                                    decided that I like it enough to commit it onto my unnamed side branch
                                    (in the Mercurial sense, of course; a "branch" in the git sense would be
                                    a "bookmark" on Mercurial) of local changes (as I did for "extended"
                                    floating-point behaviour before it finally became part of Bram's Vim).
                                    At the moment my only local changes are a few additions to .hgignore
                                    (for instance my shadow directories, my cscope.out, and anything ending
                                    in .log) and a couple of changes to src/feature.h (in order to compile
                                    with -tag_old_static and +xterm_save, as there is no configure setting
                                    about these).

                                    >
                                    > This is how we can protect from false commit messages (like the one where I was blamed for fixing some two problems in python tests while I actually said the opposite: these two problems are the only ones that are still not fixed). Patches do not have messages attached. Messages from Bram are also known to constantly include bits of information which seem not essential for me and omitting essential ones. It does not mean they are always inessential and Bram is completely wrong: e.g. pyeval() has proved to be more useful then I though when writing it, though vim.bindeval seemed more essential. But I have more details for this reason and they are always omitted.

                                    Since the mq extension places the commit message at the top of the patch
                                    (in what the manual for the patch program calls the "leading garbage"),
                                    the text of the message can be checked by eyeballing the patch text, and
                                    if necessary corrected by hg qrefresh -m 'new text' before the patch is
                                    committed into the repo, and frozen in bronze as one more changeset.

                                    >
                                    > Word about keeping context and seeing whether patch can be automatically merged was already said.
                                    >
                                    > This also enables normal annotate and log: with current commit messages format almost every bit of useful data is stripped from annotate and log (without -v) output: no user, shortened commit message is useless as it says only about vim version. Problem/solution is too verbose, no summary in the first line. Most developers will write this in their messages thus these features will work regardless of what is written in the merge message.

                                    I wouldn't know; I have verbose=true in the [ui] section of my ~/.hgrc.
                                    I have also set "log" and "annotate" (among other hg commands) to
                                    default to being paged (using the pager extension) and BTW my default
                                    pager for hg output is 'view -'. ;-)

                                    >
                                    > This is also how one can easily see which parts were included by Bram unmodified and which ones were modified (e.g. to fit coding style). This makes me learn about what should I be aware of when writing patches.
                                    >
                                    >
                                    > I cannot say what are the advantages for Bram regarding simplicity of the process without knowing how he does his job, but with PR’s at least problems with omitting parts of the patches and noise about wrong commit messages will go away. In addition to noise about not using DVCS as DVCS and broken development process. I cannot think of any sanely written script that may modify my patch to leave one parenthesis as-is (like it was done recently), thus I assume 1. job of applying patches is done manually and 2. manually taking patches out of the messages is hard enough to apply smaller ones by hand. Do not know about bitbucket (did not ever received PR’s here), but with github (assuming Bram does not want to switch context from mailer to browser) merging basically is “copy command from email message to shell and run it”. Reviewing the diff is “open URL (under ‘Patch links’ section) in Vim and review” (since vim is capable for opening https:// links). I hope bitbucket ha
                                    s something like this.
                                    >

                                    Best regards,
                                    Tony.
                                    --
                                    BLACK KNIGHT: I'm invincible!
                                    ARTHUR: You're a looney.
                                    "Monty Python and the Holy Grail" PYTHON (MONTY)
                                    PICTURES LTD

                                    --
                                    --
                                    You received this message from the "vim_dev" maillist.
                                    Do not top-post! Type your reply below the text you are replying to.
                                    For more information, visit http://www.vim.org/maillist.php

                                    ---
                                    You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                    For more options, visit https://groups.google.com/groups/opt_out.
                                  • Marc Weber
                                    ... http://vim-wiki.mawercer.de/wiki/vim-development/development.html - keeping your own work up to date talks about topgit and PatchBranchExtension (hg)
                                    Message 17 of 27 , Jul 16, 2013
                                    • 0 Attachment
                                      > checkin-needed. Use of the mq extension to Mercurial is IMHO strongly
                                      > recommended, so that a patch can be developed, compiled, tested, and yet
                                      > popped off the clone when desired (e.g. while pulling updates from the
                                      > master repo).
                                      http://vim-wiki.mawercer.de/wiki/vim-development/development.html
                                      -> "keeping your own work up to date" talks about topgit and
                                      PatchBranchExtension (hg) which are alternatives to mq.

                                      They allow exporting a final commit based on the history of a topic
                                      branch into which master/head got merged multiple times.

                                      Well - at least its my preferred way :)

                                      Marc Weber

                                      --
                                      --
                                      You received this message from the "vim_dev" maillist.
                                      Do not top-post! Type your reply below the text you are replying to.
                                      For more information, visit http://www.vim.org/maillist.php

                                      ---
                                      You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                      For more options, visit https://groups.google.com/groups/opt_out.
                                    • Yukihiro Nakadaira
                                      ... To execute :setl scb and :wincmd p in one normal_cmd() session. It can be :source, :function, or bar. -- Yukihiro Nakadaira -
                                      Message 18 of 27 , Jul 16, 2013
                                      • 0 Attachment
                                        On Wed, Jul 17, 2013 at 5:29 AM, Bram Moolenaar <Bram@...> wrote:

                                        Yukihiro Nakadaira wrote:

                                        > On Tue, Jul 16, 2013 at 5:17 AM, Bram Moolenaar <Bram@...> wrote:
                                        >
                                        > >
                                        > > Yukihiro Nakadaira wrote:
                                        > >
                                        > > > How about this?
                                        > > >
                                        > > > I guess the key is ":setl scb | wincmd p", executing these two command
                                        > > > in one normal_cmd() session.
                                        > >
                                        > > Wasn't there a reason these commands were in a separate file?
                                        > >
                                        > > As mentioned before, we should have a test for the tests...
                                        >
                                        > I think that the separate file was used for same purpose.

                                        Sorry, I don't understand what you mean with "same purpose".

                                        To execute ":setl scb" and ":wincmd p" in one normal_cmd() session.
                                        It can be :source, :function, or bar.

                                        --
                                        Yukihiro Nakadaira - yukihiro.nakadaira@...

                                        --
                                        --
                                        You received this message from the "vim_dev" maillist.
                                        Do not top-post! Type your reply below the text you are replying to.
                                        For more information, visit http://www.vim.org/maillist.php
                                         
                                        ---
                                        You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                        For more options, visit https://groups.google.com/groups/opt_out.
                                         
                                         
                                      • Tony Mechelynck
                                        ... I guess you came to Mercurial from git (correct me if I m wrong): this merged multiple times business sounds like what happens at github. Me, on the
                                        Message 19 of 27 , Jul 16, 2013
                                        • 0 Attachment
                                          On 07/17/13 00:07, Marc Weber wrote:
                                          >> checkin-needed. Use of the mq extension to Mercurial is IMHO strongly
                                          >> recommended, so that a patch can be developed, compiled, tested, and yet
                                          >> popped off the clone when desired (e.g. while pulling updates from the
                                          >> master repo).
                                          > http://vim-wiki.mawercer.de/wiki/vim-development/development.html
                                          > -> "keeping your own work up to date" talks about topgit and
                                          > PatchBranchExtension (hg) which are alternatives to mq.
                                          >
                                          > They allow exporting a final commit based on the history of a topic
                                          > branch into which master/head got merged multiple times.
                                          >
                                          > Well - at least its my preferred way :)
                                          >
                                          > Marc Weber
                                          >
                                          I guess you came to Mercurial from git (correct me if I'm wrong): this
                                          "merged multiple times" business sounds like what happens at github. Me,
                                          on the contrary, I've come to master Mercurial fairly well, but git,
                                          when I have to use it (e.g. for projects whose source is held at github)
                                          always seems foreign to me. With mq, you qpush a diff-format patch (on
                                          top of the current changeset, usually the tip) when you're working on
                                          it, you qrefresh and qpop it when you temporarily aren't, and anything
                                          that you pull -u from the master repo in the meantime doesn't need to be
                                          "merged" with it: the next time you qpush, the patch will be pushed onto
                                          the new tip (and I'm not sure what happens in case of bit-rot since I've
                                          never had the case).

                                          Well, /de gustibus and coloribus non est disputandum/ — one shouldn't
                                          quarrel about differences in taste. In Vim also, different people will
                                          use different commands, or sequences of them, to achieve a given result.


                                          Best regards,
                                          Tony.
                                          --
                                          "If I believed in a god, which I do not, I would like to
                                          communicate with him on the same intellectual level.
                                          Therefore, I would have to teach him a few things."
                                          [Aaron Erwin]

                                          --
                                          --
                                          You received this message from the "vim_dev" maillist.
                                          Do not top-post! Type your reply below the text you are replying to.
                                          For more information, visit http://www.vim.org/maillist.php

                                          ---
                                          You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                          For more options, visit https://groups.google.com/groups/opt_out.
                                        • Marc Weber
                                          You can share topic branches or PatchBranchExtension . mq patches are your personal stack of patches only AFAIK. mq allows to reorder patches, pop/push
                                          Message 20 of 27 , Jul 16, 2013
                                          • 0 Attachment
                                            You can share "topic branches" or "PatchBranchExtension". mq patches are
                                            "your personal stack of patches" only AFAIK.

                                            mq allows to reorder patches, pop/push them.
                                            PatchBranchExtension is about managing patches which may depend on each
                                            other and sharing them, right?

                                            I've added this to the wiki.

                                            > [..]
                                            > use different commands, or sequences of them, to achieve a given result.
                                            Yes - but there is :h to document and talk about all of them :) So its
                                            not bad doing the same for Vim development workflows.

                                            Marc Weber

                                            --
                                            --
                                            You received this message from the "vim_dev" maillist.
                                            Do not top-post! Type your reply below the text you are replying to.
                                            For more information, visit http://www.vim.org/maillist.php

                                            ---
                                            You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                            For more options, visit https://groups.google.com/groups/opt_out.
                                          • Tony Mechelynck
                                            ... You can share them in diff format, just like the patches that I see on vim_dev. ... I don t know PatchBranchExtension. In mq, when patches depend on each
                                            Message 21 of 27 , Jul 16, 2013
                                            • 0 Attachment
                                              On 07/17/13 00:59, Marc Weber wrote:
                                              > You can share "topic branches" or "PatchBranchExtension". mq patches are
                                              > "your personal stack of patches" only AFAIK.

                                              You can share them in diff format, just like the patches that I see on
                                              vim_dev.

                                              >
                                              > mq allows to reorder patches, pop/push them.
                                              > PatchBranchExtension is about managing patches which may depend on each
                                              > other and sharing them, right?

                                              I don't know PatchBranchExtension. In mq, when patches depend on each
                                              other, you keep them in one "queue" which is pushed and popped like a
                                              stack. When they don't, you can put them in separate queues (with the hg
                                              qqueue command) and push/pop them independently of each other. So far,
                                              the Mozilla bugs I've fixed didn't require much coding (maybe a handful
                                              of lines in up to three files) so I never felt the need to divide the
                                              fixes for a single bug into several interdependent patches: typically my
                                              "queues" are of one patch each; you're making me remember that I can
                                              delete any of them which has made it into the official source. But I've
                                              seen bigger fixes written by others, with (rarely) up to 8
                                              interdependent patches that had to be pushed in a certain order.

                                              >
                                              > I've added this to the wiki.

                                              URL?

                                              >
                                              >> [..]
                                              >> use different commands, or sequences of them, to achieve a given result.
                                              > Yes - but there is :h to document and talk about all of them :) So its
                                              > not bad doing the same for Vim development workflows.

                                              Yes indeed: Vim is the only piece of software with a help worth its name
                                              that I've met since (when? in the eighties, maybe) I stopped working on
                                              mainframes where the documentation (for software that came with the
                                              machine) was a set of paper books (in quarto or US letter format, I
                                              think, and meant to be kept in three-ring binders) and where the source
                                              (in assembly language on half-inch 2400 ft tapes, and sometimes on
                                              assembly listings on zigzag paper 132 characters wide by 11 or 12
                                              inches, similar to "ledger" from what I see under :help popt-option) was
                                              there for anyone interested in it — most people weren't.

                                              I remember getting an interim job once after going to an "examination"
                                              where we had to write a COBOL program about a given problem. I went with
                                              the COBOL manual for my former computer, opened it in front of me on the
                                              table, and stuck to the "standard" (non-machine-specific) language as
                                              described in it. Some other examinees rebuked me for “cheating”, but I
                                              got the job. (“Cheating?” I said, “Aren't you /supposed/ to have the
                                              compiler manual at hand when writing a program?”).

                                              >
                                              > Marc Weber
                                              >
                                              Best regards,
                                              Tony.
                                              --
                                              The UNIX philosophy basically involves giving you enough rope to
                                              hang yourself. And then a couple of feet more, just to be sure.

                                              --
                                              --
                                              You received this message from the "vim_dev" maillist.
                                              Do not top-post! Type your reply below the text you are replying to.
                                              For more information, visit http://www.vim.org/maillist.php

                                              ---
                                              You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                              For more options, visit https://groups.google.com/groups/opt_out.
                                            • Marc Weber
                                              ... I m talking about hg pull like sharing. ... still the same: http://vim-wiki.mawercer.de/wiki/vim-development/development.html The script below shows how
                                              Message 22 of 27 , Jul 16, 2013
                                              • 0 Attachment
                                                Excerpts from Tony Mechelynck's message of Wed Jul 17 03:45:35 +0200 2013:
                                                > You can share them in diff format, just like the patches that I see on
                                                > vim_dev.
                                                I'm talking about "hg pull" like sharing.

                                                > URL?
                                                still the same: http://vim-wiki.mawercer.de/wiki/vim-development/development.html


                                                The script below shows how you can have a topic branch, merge "default"
                                                into it by "hg pmerge", and still pull/push it. Try the same with mq,
                                                you'll end up in a mess (with distributed development)

                                                That's the main difference. Person B can fix bugs in the topic branch of
                                                Person A. Person C can develop a feature on top of that topic branch
                                                etc. Whether this is useful depneds on the use case - but you can push
                                                to bitbucket or the like.

                                                Marc Weber

                                                rm -fr test
                                                (
                                                set -x
                                                set -e
                                                mkdir -p test/source

                                                add_commit(){
                                                echo $1 > $1
                                                hg add $1
                                                hg commit -m $1
                                                }

                                                (
                                                cd test/source
                                                hg init .
                                                add_commit a
                                                hg pnew -t topic-msg topic

                                                # this will not show up, because its committed upstream below, see [up]
                                                add_commit topic-commit-1
                                                # these will end up in the topic diff
                                                add_commit topic-commit-2
                                                )

                                                # clone topic
                                                hg clone test/source test/clone


                                                (
                                                cd test/source
                                                hg update -C default
                                                add_commit upstream-change

                                                # let's make it more complicated, feed topic-commit upstream [up]
                                                add_commit topic-commit-1


                                                # add a third topic change:
                                                hg update -C topic
                                                add_commit topic-commit-3
                                                )

                                                (
                                                cd test/clone
                                                # now get updates of the topic branch by pull
                                                # and this is what I don't like, you cannot "preview" using mercurial ..
                                                # best you could do is make a backup of this repo before pulling ..
                                                # so this should get topic-commit-3 into the clone
                                                hg pull -u

                                                hg update -C default
                                                add_commit last
                                                hg update -C topic
                                                # merge this patch upstream
                                                hg pmerge

                                                # and this is the cool thing, you can just push the updated topic without
                                                # "diff" formats:
                                                hg push -b topic ../source
                                                )


                                                (
                                                # export (we don't have deps, but this would export topics on which this topic depneds, too)
                                                cd test/source
                                                hg update -C topic
                                                hg pexport -U 10
                                                )

                                                )

                                                --
                                                --
                                                You received this message from the "vim_dev" maillist.
                                                Do not top-post! Type your reply below the text you are replying to.
                                                For more information, visit http://www.vim.org/maillist.php

                                                ---
                                                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                                For more options, visit https://groups.google.com/groups/opt_out.
                                              • Ben Fritz
                                                ... Can you elaborate a little on the remotes feature you list on that page as being better in git? IIUC I *think* that is basically the same as the paths
                                                Message 23 of 27 , Jul 17, 2013
                                                • 0 Attachment
                                                  On Tuesday, July 16, 2013 9:16:09 PM UTC-5, MarcWeber wrote:
                                                  > Excerpts from Tony Mechelynck's message of Wed Jul 17 03:45:35 +0200 2013:
                                                  >
                                                  > > You can share them in diff format, just like the patches that I see on
                                                  >
                                                  > > vim_dev.
                                                  >
                                                  > I'm talking about "hg pull" like sharing.
                                                  >
                                                  >
                                                  >
                                                  > > URL?
                                                  >
                                                  > still the same: http://vim-wiki.mawercer.de/wiki/vim-development/development.html
                                                  >

                                                  Can you elaborate a little on the "remotes" feature you list on that page as being better in git?

                                                  IIUC I *think* that is basically the same as the "paths" section in the hgrc, but with an interface to modify it.

                                                  http://stackoverflow.com/questions/4956346/how-can-i-add-remote-repositories-in-mercurial

                                                  TortoiseHg provides a GUI to add paths, but I don't know of any built-in command-line tools to do it.

                                                  --
                                                  --
                                                  You received this message from the "vim_dev" maillist.
                                                  Do not top-post! Type your reply below the text you are replying to.
                                                  For more information, visit http://www.vim.org/maillist.php

                                                  ---
                                                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                                                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                                                  For more options, visit https://groups.google.com/groups/opt_out.
                                                Your message has been successfully submitted and would be delivered to recipients shortly.