2012/12/10 Anthony Foiani <anthony.foi...@gmail.com>: > 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?
That is what I thought also. But it is far easier to review a patch when the history is clean. >> > 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? Or just keep the file.dir-locals.el out of git. I have no objection to add this file. I do not use Emacs myself. I see it can help code quality so unless someone objects I will merge it upstream. Please submit a pull request. >> > 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.) Now merged upstream. Merging a pull request from github adds a "merge pull request" commit. The history is then not very nice (linear) but I don't know a better way using the github web interface. Thanks -- Dr. Ludovic Rousseau _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
