Thanks for the feedback! I wonder if this feature of patch "ignoring" stuff it doesn't understand is a GNU feature or a POSIX feature, but I'm abusing your patience here. (Incidentally, I also saw that POSIX has no "unified" format, but this "ignoring" feature might apply in a wider sense). >> 4. some hints to use git for working on projects that do not use any >> other VCS, or for which one only wants to produce and send a quick >> patch starting from a tarball. > > You can use git/contrib/fast-import/import-tars.perl to import the > last few releases into git (possibly just the last release, if you > don't need the history) and then just build on that, and send patches > back to the project when you're done. > > When the project makes another release, use import-tars to import the > new tarball, and then rebase if you have any patches they haven't > accepted yet. Importing wasn't actually an issue, just a matter of init/add/commit. I was more scared about the patch production process, i.e. producing a patch that could be perfectly usable by the project's maintainers. But given what you kindly said, I think I can dismiss this as excess of caution by me. Thanks, Flavio. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
