|Managing patches - proposal||MarcWeber||6/1/13 3:07 PM|
I've been thinking about what's causing trouble to me.
Lack of workflows - lack of documentation.
http://vim.sourceforge.net/ -> download -> patch
No hint about how patches should be submitted.
No hinting about release cycles
NO hinting about how to manage vim source and patches.
I'm used to git. So let me explain how I do it for git(hub) based
1) submitting patches
2) create topgit based branch which basically means having a command
to merge upstream changes automatically. I can export this branch as a
single patch when I feel ready. mercurial has the [pbranch] extension
which also works perfectly fine
3) push my patch to github, create pull request
If I have an updated patch I just "push -f" overriding history,
and github will tell show to the rest of world "this patch has an
outdated version people already commented on. Click here to read all
about the older patch
This way its easy to react to comments (which on github can be placed
nearby lines) as well as below the pull request description
2) reviewing patches, applying them
way 1): curl 'patch' | git am
way 2): add a remote location
git add remote contributor github://the-url
This way works like "hg pull other-repo-url"
However there is one big difference:
All branches coming from that repo are prefixed by that repo name,
in this example contributor/master contributor/feature-X
Thus its not me having to worry about importing foreign commits into
my repository - because I can always can identify and drop them again,
and distinguish them from my own branches
People can vote for patches by commenting by "+1" (yes, it sucks, but at
least you can vote). And for release managers it is important to see
how many people want a patch/feature because resourcese are altways
limited. This way it can be made transparent.
Patches even can be labeled such as
Then people know what to do.
This all can be documented nicely, eg that's what we did for nixos:
So let me compare this to Vim:
Even the [developing] page stops at "how to get latest version of Vim"
not talking about how to
- design new proposals
- submitting them
Summary: Almost all problems would be gone by providing an official
github based mirror using git. Patches which are ready could still be
applied to mercurial.
I know there are many mercurial users on this list, please helsp my mind
change, and tell me how the I can setup a mercurial based workflow which
doesn't get into my way - which is as easy as the git based is I
If there is no alternative, would other people join and help maintaining
a git based mirror? Bram, would you even eventually consider looking
there for most up to date patches? We could still announce them on the
People like ZyX should not spend their time on repating lists of patches
which should be included. Such behaviour might be a sign of lack of
infrastructure - and that infrastructure is there, we just have to use
Yes, I know that you can clone repositories on google code, too.
However there is no way for people telling "I'm ready with a patch and I
want that other people discuss and comment on it", thus something like
Thus how many people would be interested in a github based workflow,
because it just solves quite a lot of problem getting out of the way of
devs letting them do what they should do: write code, comment code and
get things done?
So what about using an github based mirror? Who else would be interested
The mailinglist is not appropriate, because its hard to keep track of
- to be discussed
- to be reviewed
- closed (merged, rejected?)
|Re: Managing patches - proposal||Josh Hoff||6/1/13 6:58 PM|
> 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+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
+1 maybe we can get vim on GH and travis-ci!
(Ps please let me know if I'm posting incorrectly to the ml)
|Re: Managing patches - proposal||Chiel92||6/2/13 3:04 AM|
+1 for GH
|Re: Managing patches - proposal||LCD 47||6/2/13 4:56 AM|
On 2 June 2013, Marc Weber <marco-...@gmx.de> wrote:[...]
> Summary: Almost all problems would be gone by providing an official[...]
> People like ZyX should not spend their time on repating lists of[...]
Are you trying to solve your own problem, or (your perception of)
somebody else's problem? If the former, may I suggest the following
(1) Get this file, bridging Mercurial to Git:
Rename it git-remote-hg, make it executable, and copy it to your
$PATH; see also:
(2) Clone the sources, then go make some coffee:
git clone hg::https://vim.googlecode.com/hg/ vim
(3) Create a branch for each feature you're working on, then patch,
test, push to GitHub, whatever;
(4) Update master, then rebase your branches, or merge master to them;
(5) When you have something to show, run
git diff -r master
and post the output to the list.
Would that work for you?
|Re: Managing patches - proposal||Bram Moolenaar||6/2/13 5:27 AM|
Marc Weber wrote:
I have two important reasons to want patches to be emailed to me as a
1. It shows explicit intent to have the patches included with Vim. When
I download something from the internet I have no idea about copyright or
even who wrote it. It would require going the way of having the author
or authors sign a form (on paper, email won't do!). That gets messy.
2. With an emailed diff we both know (the sender and I) what I'm
including exactly. When pulling from some repository I never know what
state the change is in. I sometimes get an email with "try now", but
it's not clear what "now" is.
The current method worked very well for me, I don't see a reason to
Note that if people want to distribute (experimental) patches to share
with other users, then using something like github works very well.
Never overestimate a man's ability to underestimate a woman.
/// Bram Moolenaar -- Bram@Moolenaar.net -- 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 ///
|Re: Managing patches - proposal||依云||6/2/13 6:22 AM|
On Sun, Jun 02, 2013 at 02:56:42PM +0300, LCD 47 wrote:
FYI, I find there is already a git repo here: https://github.com/b4winckler/vim
Linux Vim Python 我的博客:
A: Because it obfuscates the reading.
Q: Why is top posting so bad?
|Re: Managing patches - proposal||ZyX||6/2/13 7:23 AM|
> I have two important reasons to want patches to be emailed to me as aPull request on bitbucket also has an author attached. One also won’t launch a PR if he does not think patch is ready.
(Note: I am assuming vim is moved to bitbucket and managed as usual, not what @Marc Weber suggests.)
If you receive a PR it means author thinks the patch is ready. There is no difference between this and emailing a patch except for the former is harder to do.
Bitbucket also allows reviewing both specific merges (by checking out specific commit URL) and the overall difference: like this https://bitbucket.org/marcinkuzminski/rhodecode/pull-request/111/pam-authentication-on-linux/diff (repository was chosen randomly).
There are reasons:
1. For me it would be easier to merge: 1 button + some text; I hope bitbucket does allow writing custom text in merge commits (it is not popular enough for me to have experience with incoming bitbucket PR’s). I do not know how you apply patches from emails, but as they are non-standardized it is hard to impossible to create script that works under all circumstances. With PR merging is the only option with the only command which may do this.
2. Merging in mercurial is smarter then patching in patch program.
3. Contributors waste less time on sending PR’s.
4. You keep history as it was created, not the refined version which looses context in which patch was written thus making it sometimes impossible to say why the code looks like it looks.
5. Even though you have to invent message attached to a specific merge commit, author commit messages are left untouched. It is significant as I sometimes see things like in patch 7.3.1003 where you claimed I solved the problems which were listed as the only problems I have *not* solved.
6. (bitbucket) You can discuss specific lines in the patch. It is more convenient then copy-pasting some line and responding with it in the message.
7. (bitbucket) There is fine issue tracker here which allows marking bugs as fixed in commit messages, assigning priorities, searching *and keeping all the related things in one place*. When using todo.txt one has to search mailing list for the item described there.
8. (bitbucket) If patches are replaced with PR’s all you need to check whether patch is up-to-date is the total diff which also shows which files have conflicts and the conflicts themselves. You don’t need to download patch and try to apply it just to find out that patch is outdated. And conflict markers are better when doing conflict resolution then .rej file with failed-to-apply hunks.
AFAIR by the time this is not the only and definitely not the last attempt to convince you to use DVCS in the same fashion other people expect. Most recent I remember: https://groups.google.com/forum/?fromgroups=#!searchin/vim_dev/abuse/vim_dev/78RMC7ajGfE/pewnv_kEjJIJ (“Issue 83 in vim: the changelog indicates that bram is abusing hg making the history a pain to deal with.”).
|Re: Managing patches - proposal||MarcWeber||6/2/13 10:03 AM|
Dear Bram & list,
I've tried summarizing the important points and options here:
thanks for clarifying. Eventually consider adding such notes along with
your notes about how to format code to the src/README.txt reference it
somewhere at vim.sf.net -> developping or such.
Or allow me to add such a page / lines.
Yes - but quite often it happens that others find that some aspects of a
patch should be improved before it should be included.
Why do you know when recievinig an email? You can fake the sender.
I could easily send this message so that it looks like having been
written by you, unless you require emails to be signed or encrypted.
I'm not sure about how lawyers think about this. Technically there is
not a big difference.
That's exactly the point. Using git you know
- against which revision a patch was written for
- whether it still applies cleanly to latest master/tip
I think that vim-dev is the only way to make others aware of a patch.
So why may using a web interface benefical ?
Its because people can comment lines in source code.o
Its because whenever you send a patch to the mailinglist, others may
think your patch may be rewritten, thus they comment on your patch
If this happens, then its no longer clear which state a patch has.
Worse - to find out, you have to read a therad, and then you still don't
know. Let me show you an example, how this looks like in practise:
Due to using a template I submitted a superfluous line, and also didn't
capitalize another. After getting told I sent an updated patch.
The really important thing is:
- you and others see exactly which bugs exist (no patch attached)
and which patches exist (called pull requests) (code attached).
And patches may not only be outdated just because somebody else
commented, but also because you comitted some other patches upstream.
Updating a pull request is as much work as:
git merge master
git push my-github-account my-branch --force
to get the results shown at [x]
Also as I said, I just don't understand how to use mercurial to
efficiently have a look at patches others have written - or how to keep
track and include it
Let's have a second look at the pythonx patch history:
- I was told that idea existed
- I was old others like the idea - givenv that it prooves correct that
you can use python 2.6+ and 3.0 and the same code if you take little
- I was told that plugin/*.py is bad (ZyX)
From that I asked whether it makes sense to introduce
startup/ directory which then could be used for ruby, perl, python,
... in the future?
- I was told that polluting the global namespace is no option (ZyX)
So I came up with the idea loading files as module giving them a name.
- The patch broke because updates to the documentation were submitted
Which is the status of the patch - where to get the latest version?
- You said feature requests would be accepted till last Friday
- Is the feature ready? I'm not sure.
- So even though we used the mailinglist we know nothing.
Even if I resubmitted an up to date patch - it would be harder for
others to keep track of it IMHO.
And of course it looks like only me having those problems - and those
knowing github having replied with "+1" (I think)
|Re: Managing patches - proposal||MarcWeber||6/2/13 12:44 PM|
How to continue?
Submit ideas here:
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.
|Re: Managing patches - proposal||UncleBill||6/2/13 7:56 PM|
Git/Github will be the perfect dev workflow for Vim and make more developers join ontribution.
|Re: Managing patches - proposal||Ben Fritz||6/2/13 8:12 PM|
I don't know whether it's common, but mailing "bundles" around might be better than patches. You can actually pull from a bundle as a source, so that not just the changes but the parent they are based off of is in there. Then Bram could rebase and collapse changesets if he wanted to, or just merge. It's not as nice as a pull request, but pretty close, and it can be done by email without Bram's worry about what "now" means because the source is attached to email.
|Re: Managing patches - proposal||LCD 47||6/3/13 4:25 AM|
On 2 June 2013, Marc Weber <marco-...@gmx.de> wrote:
> How to continue?[...]
You mix up a number of mostly unrelated things.
(1) Mercurial and Git are virtually identical to one another in terms of
features. There are, of course, differences, but they are largely
irrelevant to this discussion.
(2) GitHub is not Git, but rather a centralized Git server, plus a bug
tracker, plus a number of nice "social" tools (other features are,
again, irrelevant to this discussion). Bitbucket is essentially the
same, the main differences being that its "social" tools are less
polished, it ofers Mercurial along with Git, and at this point it
seems to have fewer scaling problems than GitHub:
(3) Currently, Mercurial is not used as a DVCS for Vim development, but
rather as a central distribution point for the latest Vim sources,
with the additional convenience of keeping a history of patches. It
could well have been CVS instead with Bram as the only commiter, and
I beleve this is the gist of your gripe, not Mercurial itself.
So what you ask for is not a new workflow, but a complete overhaul
of the development process. You do try to solve somebody else's problem
after all. :)
About GitHub now. GitHub project started in ~2008. Back then, some
of us have been writing code for ~20 years, and we were generally doing
fine in our unenlightened ways. :) Back then GitHub was a Rails app that
shelled out to Git, and, while they do have a number of brilliant people
working at the site now, I'd humbly submit that some of that initial
architecture is still showing through. It's social features are really
nice these days, yes. But is it wise to start _depending_ on them?
So, to answer your initial question: I'd personally like to see
Mercurial (or Git) used as a real DVCS (that is, people would start
submitting pull requests from their own repos). I'd also like to see a
more functional issue tracker in place, and people actually using it.
For the social features, I don't really care though. Things can be
coordinated just fine over a mailing list, like other projects do: see
f.i. Linux kernel, KDE, *BSD.
As for solving the "this patch" problem, I'd say "please merge my
commit 31bed2d" is pretty much equivalent to "please include the
Then again, all this rant is just my opinion, and I haven't
contributed anything useful to Vim in a while. Not sure why you (or
anybody else) would care about it, but since you asked... *shrug*
|Re: Managing patches - proposal||LCD 47||6/3/13 4:57 AM|
|Re: Managing patches - proposal||Chiel92||6/3/13 5:03 AM|
|Re: Managing patches - proposal||Josh||6/3/13 5:21 AM|
I wouldn't say they're completely irrelevant to this discussion. If we're discussing a shift in how development works, discussing a new dcvs might be a good idea too. +1 to git
What social features are you talking about depending on? Issues? Pages? Something else?
Not quite. If you push a commit up I can find it on the web ui, and send people links to it, or I can pull it from your remote repo and play with it by knowing your username and the sha/branch name. However I'd guess finding and using things through the ml would be a bit less elegant, though this is probably my inexperience with mailing lists showing through.
|Re: Managing patches - proposal||LCD 47||6/3/13 7:18 AM|
On 3 June 2013, Chiel92 <ctenb...@gmail.com> wrote:
> > Things can be coordinated just fine over a mailing list, like otherSure, but out of all GitHub's features only the Git server is used.
Patches, bugs, features, etc. are still discussed on the list.
|Re: Managing patches - proposal||Ben Fritz||6/3/13 7:41 AM|
On Monday, June 3, 2013 7:21:04 AM UTC-5, Josh wrote:
> > (1) Mercurial and Git are virtually identical to one another in terms of
Mercurial has an extension (hg-git) that allows it to push-pull git repositories as well as native Hg repositories. Git probably has something similar. Anybody who wants to use Git can. But I think moving the official repository to a new DVCS because some developers like it better, this soon after adopting Mercurial, would be silly at best.
|Re: Managing patches - proposal||LCD 47||6/3/13 7:42 AM|
On 3 June 2013, Josh Hoff <random...@gmail.com> wrote:[...]
> > About GitHub now. GitHub project started in ~2008. Back then, someI'm referring to the beginning of this thread: issues, web-based
merges, commenting on particular lines from files, automatically marking
patches as obsolete. These are all nice and well thought-out. Some of
them have good equivalents outside GitHub (issues f.i. can be handled
with a bug tracker), others don't (say, commenting on a line from a
patch). The ones that don't are ultimately locking users to GitHub.
What I'm suggesting is something like this: I push a change to some
publicly available repo (on my own server, or GitHub, or whatever), then
send the link to the list, and also to Bram personally if he prefers so.
This keeps the repo decentralised, as opposed to tied to a central
GitHub / BitBucket. But yes, the price you have to pay for this is that
in order to find my patch you'll have to read the list (or search the
|Re: Managing patches - proposal||LCD 47||6/3/13 7:48 AM|
On 3 June 2013, Ben Fritz <fritzo...@gmail.com> wrote:Yup, there are bridges both ways. They do have a few quirks, but
they generally work well.
Absolutely. As I said, the main problem is not that Mercurial
doesn't have enough feature, but rather that right now Mercurial's
features are not used.
|Re: Managing patches - proposal||ZyX||6/3/13 7:50 AM|
There are line comments in bitbucket.
|Re: Managing patches - proposal||Mike Williams||6/3/13 9:11 AM|
On 02/06/2013 20:44, Marc Weber wrote: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
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 ;-)
I have got to stop bouncing those reality checks.
|Re: Managing patches - proposal||MarcWeber||6/3/13 10:42 AM|
Excerpts from Mike Williams's message of Mon Jun 03 18:11:34 +0200 2013:
> o remotes and tracking anonymous branchesExample:
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
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?
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
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:
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
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.
Using that patch queue extension, how can I get updates from that
"incomplete work"? Using git remotes I'd do
git fetch him
Yes, but to find out whether somebody else is working on a similar
feature, github, bitbucket might make it easier to do an initial
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 :/
Me too. Well - finally it'll be Bram reviewing and merging patches.
No doubt. Everything else would be a fork of Vim.
|Re: Managing patches - proposal||Josh||6/3/13 11:04 AM|
On Monday, June 3, 2013 7:21:04 AM UTC-5, Josh wrote:> On Jun 3, 2013, at 6:25 AM, LCD 47 <email@example.com> wrote:
I think because we're discussing a change in workflow, discussing a new dcvs is a good discussion to have, as it might affect our choice of hosting.
--To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
|Re: Managing patches - proposal||Mike Williams||6/4/13 2:23 AM|
On 03/06/2013 18:42, Marc Weber wrote:A quick 10 mins creating some example repos with divergent bookmarked
branches shows the following:
<example repo creation, bookmarking, committing and path setting elided>
F:\hg\bookmarks\marc>hg pull him
pulling from F:\hg\bookmarks\him
searching for changes
adding file changes
added 3 changesets with 3 changes to 3 files (+3 heads)
divergent bookmark A stored as A@him
divergent bookmark B stored as B@him
divergent bookmark C stored as C@him
(run 'hg heads .' to see heads, 'hg merge' to merge)
* C 3:826395aa207d
That is a git thing - git is happy to have history rewritten. The
mercurial approach is to not support this out of the box, but it can be
done. To help with managing history modification mercurial supports
phases which tracks changeset visibility. (There is ongoing development
to further simplify history rewriting but it is not available by default
yet - for those interested see
git is very much into feature branches and rebasing or deleting to keep
the history "nice". Mercurial is more into preserving development
history with merges of feature branches back into the main line.
Bookmarks can be deleted so the namespace is kept clean (this is why you
don't use named branches for bug fixes/feature development in mercurial
- branch names are forever).
With recent versions of mercurial bookmarks are included in repo updates
using pull and push. If he is not using bookmarks then yes you would
have to bookmark them yourself if you want to track them using bookmarks
rather than trying to work out which head to use.
Makes no difference whether using mercurial or git, it's just
bike-shedding on the process. Pros and cons for both github and
bitbucket (and kiln, and rhodecode, ...)
However you are now asking developers to do multiple steps to review a
patch. A patch in an email means it is front and centre. It can still
include a URL to whatever since that can make subsequent integration and
tracking in the local clone straightforward if you decide you want to
actually try the patch.
At a stab (not tested):
hg incoming --patch | hg qimport
Patch queues have pros and cons at the moment. If you are more
confident then just normally pulling and using strip later to remove
again would work. There are many ways to solving this problem, you just
have to know the tool.
Yep the main problem is a social organisation one, not a tool one.
Mercurial and git are both very flexible on workflows, once you have
worked out how you want to organise yourself.
I can do what you do, you just do it better.
|Re: Managing patches - proposal||Josh||6/5/13 6:43 AM|
Right. What would be really great would if we could support both workflows completely, and even better if we could transparently mix the two. I bet we could with some clever use of hooks and the GitHub/bit bucket Apis. I'll give it a shot with GitHub and post back with my findings. Anyone willing to try the same with emailing patches/integrating the bit bicker issue tracker and mercurial?
> --> To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
|Re: Managing patches - proposal||MarcWeber||6/5/13 2:29 PM|
I've written a summary here:
At this page you can tell others about ideas and that you're working on
I hope hat this somewhat reflects the important points about this
About git mirrors: I don't know which to prefer. jp seems to be more "up
to date" - at least today - but b4winckler mirrors all branches.
Is anybody interested in maintaining / using the bitbucket mirror?
The github mirrors will do it for me at the moment. However if others
would use it I'd try starting such mirror.