OK, Just to elaborate, I'd rather you don't merge the changes right now, as we're dealing with the WinCE integration, and I told Toby earlier that I would keep mainline frozen until we were through with it.
Now if Toby is okay with rebasing off your changes, I don't really mind if you push them, but from having been at the other end of the spectrum a few times, I know that spending time on rebasing, even when it's supposed to be trivial, is not always for the best. This being said, I have no problem with someone else than me applying patches. On the contrary, especially since I have plenty to keep me away from libusbx these days, I'd like to encourage it... as long as it isn't done through the oh-so-tempting github "Merge pull request" feature. The reason is that using github's merge (or a regular git commit/merge if pre-commit [1], post-rewrite [2] aren't used) will screw up our versioning (libusb/version_nano.h being increased for each commit), and, in case I didn't make myself clear, I will remain adamant about having a "distance to origin" part in our versions, that can help us identify both a commits and its chronological order. So that means extra work for whoever wants to apply a commit to mainline, which I guess is the main reason I've been pushing most of the commits so far, though, IMO, the process is very straightforward once you've done it a few times (and before anyone complains about this whole thing not being as intuitive as could be, consider that this is aimed at 4 people tops - we're not designing an Apple UI here), but let me detail it again. The first thing you need to ensure is that your /.git/hooks/pre-commit and /.git/hooks/post-rewrite reference the relevant scripts from /private. See the commends in the .sh for details on how to do that. A) regular commits (i.e. a patch you've created from scratch against your repo) - Nothing to be done. The versioning update will be done automatically for you, as long as you have the hooks set B) amend of a commit (or: oops, I screwed up my previous commit and need to change it before a push) - in the root of libusbx, you must manually create a .amend file and then run the git amend command. This is the only way I found to make sure git could detect an amend and not increase the nano again. Note however that the scripts are smart enough to tell you if you forgot to create a .amend file on an amend, so provide you pay attention to the messages spewed by git, even if you forget to create one you should still be OK. The scripts will even create the .amend for you, so if you wanted, you could just run git amend twice to get everything sorted. C) merge of a commit that you didn't create, such as a pull request from github or a patch you got off the mailing list. - Well, if it's a pull request from github, the first thing you'll need is a patch file you can merge. The one thing you want to know is that github can easily provide such a thing. Say I want to merge Ludovic's 11071c87245423b71ac1b37fd1452005cef605d7 from github. If I go to https://github.com/LudovicRousseau/libusbx/commit/11071c87245423b71ac1b37fd1452005cef605d7 I get the github web formatted patch, but lo and behold, add ".patch" at the end, to have https://github.com/LudovicRousseau/libusbx/commit/11071c87245423b71ac1b37fd1452005cef605d7.patch, and you have exactly what you want to use to work with your local tree. - Most of the time, once I have the .patch in my repo, I tend to use apply patch serial, for each individual patch. Of course, you can also choose to merge, or use any other method of your choice that will produce the commit you'd like to eventually push to mainline. - Now, the operation above will not increase the nano, so after each patch you want to apply, you need to create a .amend, as per B, and amend the previous commit. And yeah, if you apply a bunch of patches at once, having to do an amend on every individual patch can be a bit tedious. On the other hand, most of the time you actually want to amend a patch so that the messages are consistent, or updated, and it gives you greater opportunity to ensure that was you get into mainline has been inspected closely, so I don't see it as that much of a drawback. So there you have it: if you, Hans or Xiaofan want to push stuff into mainline, this is how I'd like to see it done (I'll try to copy paste some of that to the maintainer's corner page later on, so that you don't have to dig through e-mail). Also if you do it, I'd tend to prefer if you kept the "Subsystem: " prefixing I tend to use for the commit title (and I also tend to prefer avoiding myriads of similar patches) but that last part is really up to you. NB: this is something only libusbx mainline needs to bother with. People creating branches or submitting patches should not bother with nano versioning. Finally, a couple more notes: - Did you advertise for the pull request on the mailing list (in which case I probably didn't pay attention to it, so my bad). If not, be mindful that, alas, we no longer have a notification system for new github issue, so you should consider that anything that only appeas in the github issue list is likely to be ignored by most for weeks. - Since I can't usually post to this list during daytime, I'll appreciate if at least 24 hours elapse between the moment a notice is posted and the time it is being acted on. Regards, /Pete [1] https://github.com/libusbx/libusbx/blob/master/.private/pre-commit.sh [2] https://github.com/libusbx/libusbx/blob/master/.private/post-rewrite.sh ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
