Ludovic, greetings -- On Sun, Dec 9, 2012 at 7:19 AM, Ludovic Rousseau <ludovic.rouss...@gmail.com> wrote: > > 2012/12/8 Anthony Foiani <anthony.foi...@gmail.com>: > > Greetings -- > > > > I have two small patches which you might want to consider integrating. > > > > (And given that I can't get git to do what I want, you probably want > > to just cherry-pick these, as I suspect I've completely destroyed my > > repo history...) > > You should rebase your patches above OpenSC/OpenSC master.
Ok, but pardon my git ignorance: I thought that one should never rebase a tree that will be published and pulled from? Or only if it's published and someone tries to *base a new tree* off of it? > > > https://github.com/tkil/OpenSC/commit/0c4a2e0c4063f31bc41c34e45869b9a9e7ca41d7 > > This uses "dir local" settings to configure Emacs indentation correctly. > > I don't think that an Emacs configuration file should be added to the > OpenSC source code. Hm. Why not? It would ensure that emacs users have their style set appropriately for this project, and shouldn't affect anyone else in any way. In my own use case, I work on 3-4 projects in the same emacs session, and each one has different indentation settings. dir-local settings seem the easiest way to assign a style per directory (tree). > You should keep this change in your own branch. And for my second question of git ignorance: how can I maintain "my own branch", when merging upstream into a branch is discouraged? Or do I misunderstand the tone of the log comments when trying to check in such a merge? > > > https://github.com/tkil/OpenSC/commit/599bd1e6c906af63eb379c866076f98a91654cb2 > > I spotted an inconsistency in how the option argument pointers were > > initialized; this fixes it (to make it more consistent). > > Not a bug but the code would be nicer. For whatever it's worth, my understanding is that uninitialized global variables are actually allocated as a part of program runtime, and are initialized to zero at that point. *Initialized* global variables, however, are stored in the binary itself, even if the initializer is zero. So as a matter of style, it might be better to leave all those pointers uninitialized. (This was a big stink on the linux-kernel mailing list a few years back.) On the other hand, I don't know if this behavior is true across all platforms, and the space/time cost in this case is trivial. > Can you create a branch from OpenSC/OpenSC master with only this patch > and ask for a Pull Request? I'll try. :) Every time I try to use git for anything fancier than an svn-replacement, I seem to get burned... In this case, it looks like I'll have to fork the OpenSC version (instead of the CardContact version), then branch in my new fork, commit this change, and then request a pull of my new branch on the new fork? (Not complaining about amount of work, just trying to make sure I have the flow correct.) Many thanks, Anthony Foiani _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
