Excerpts from Mike Williams's message of Mon Jun 03 18:11:34 +0200 2013: > o remotes and tracking anonymous branches > The equivalent to remotes would be to add new path aliases to the repo's > .hgrc file under [paths]. See `hg help paths` for more details on that.
Example: me: having branches A,B,C him: having branches A,B,C using path aliases, what exactly happens if pull from "him"? If I use git I get new branches: git remote add him git:/// git fetch him him/A him/B him/C its not required to create bookmarks. How would the mercurial workflow look like for this example ? Is it still that hard to "remove temporary branches" again requiring login etc - talking about bitbucket - does somebody know? > The simplest approach to track new heads introduced by remotes is to add > a bookmark to the new tip head after the pull. So its me having to to bookmark him/A him/B him/C ? and if he is happening to have 30 branchees, I have to bookmark 30 branches? > o patches by email > The advantage of patches being provided by email is that list members > can review them before loading them into their local repo first. I don't want to change this. I want developpers to tell the list about their changes - so that they get reviewed. The difference is that a mail to the mailinglist would eventualy no longer contain a patch file, but an url to a git pull requset Eg you can get the patch by appending ".patch" to a pull request url: https://github.com/MarcWeber/vim-addon-manager/pull/120.patch Now drop the '.patch' and you'll get to the web interface. It'll tell you that that pull request has been closed, my last comment was "pushed upstream". If you comment on such a pull request you'll get notified if additional comments happen. This way involved people will always know what's going on. We still want to send important comments to the mailinglist. > Patches can be easily imported into a repo. If the patch is not an > output from `hg diff` (which identifies the parent changeset) then you > can use the patch queue extension to quickly try it out and remove it > again without littering your repo with incomplete work. Using that patch queue extension, how can I get updates from that "incomplete work"? Using git remotes I'd do git fetch him > There is nothing stopping a group of developers working on area by > themselves with their own repos, and then when they have got what they > believe is a good improvement submitting one or more patches. If would > be up to them to handle and collapsing or rebasing as required to get it > accepted by Bram. This is an early step towards possibly having a > trusted lieutenants workflow ;-) Yes, but to find out whether somebody else is working on a similar feature, github, bitbucket might make it easier to do an initial research. But you're right, I'd like to see a wiki page listing all "work being done" so people can look it up easily. However in practise this doesn't work, but pull requests like implementations do more often :/ > (I'm not talking about changing the > official repository. I'm only talking about preparing patches) Me too. Well - finally it'll be Bram reviewing and merging patches. No doubt. Everything else would be a fork of Vim. 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
