> I have two important reasons to want patches to be emailed to me as a > diff: > > 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.
Pull 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.) > 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. 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). > The current method worked very well for me, I don't see a reason to > change. > > Note that if people want to distribute (experimental) patches to share > with other users, then using something like github works very well. 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.”). -- -- 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.
