On 02/06/2013 20:44, Marc Weber wrote:
How to continue?
Submit ideas here:
http://vim-wiki.mawercer.de/wiki/vim74/devs-workflows.html
Some comments on your notes:
o git staging area.
Yep, there is no equivalent to that in mercurial, but recent versions of
mercurial have `hg commit --amend` that provides similar functionality -
it picks up subsequent changes and rolling them into the working
directory's parent changeset.
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.
The simplest approach to track new heads introduced by remotes is to add
a bookmark to the new tip head after the pull. See `hg help bookmark`
for more details. There is also a nice introduction to them here -
http://mercurial.aragost.com/kick-start/en/bookmarks/ Bookmarks are to
mercurial as branches are to git, mercurial named branches are something
else and you don't want to use them for patch development.
o github pull requests just work.
As they do with mercurial repos in bitbucket or kiln. The workflow is
more a function of the supporting ecosystem than because it is using
git. And the reverse holds, using git does not require you to do the
clone, update, push, pull request dance.
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.
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.
And like git you can get mercurial to generate patch emails from a line
of changesets off the mainline of development, as some have started to do.
o centralised distribution
Using any dvcs (git, mercurial, bzr, fossil, etc.) usually requires one
repo to be deemed the master. There may be a few mirrors, or ones with
known good mainline development heads that can be fallen back on. The
fact that anyone uses mercurial for development work on vim means they
are using the d in dvcs. They are creating local branches and merging
their local head back into default to pick up latest applied patches and
so on. That is the definition of DVCS.
Whether changesets are communicated as pulls, bundles, or generated
diffs, they are all ways of updating other distributed repos easily.
There is nothing to stop anyone to get their clone hosted somewhere and
send links around - you don't even have to pull into your local repo to
see the changes, `hg incoming --patch` will generate a diff you can
review first.
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 ;-)
mercurial lovers speak up and tell why you'd prefer keep using
mercurial for exchanging patches. (I'm not talking about changing the
official repository. I'm only talking about preparing patches)
I'd like to document whatever the result will be in about 2 weeks and
make it official if nobody objects.
This will not be a "you must follow this" - it will just be a
recommendation which we document officially.
Marc Weber
Mike
--
I have got to stop bouncing those reality checks.
--
--
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.
