Hi Be, On Tue, Jun 18, 2013 at 09:44:42PM +0100, Ben Hutchings wrote: > Currently there are 3 different formats used for backports of a single > commit, which are: > > gregkh: commit $HASH upstream. > davem: [ Upstream commit $HASH ] > git-cherry-pick: (cherry-picked from commit $HASH) plus one : what results of the commit messages we have to adjust an in which we sometimes do mistakes (eg I found some missing "." after upstream in some of mine). > For backports that correspond to multiple upstream commits, the format > varies a bit. I haven't attempted to parse those messages > automatically. I did. that resulted in soem people complaining in 2.6.32.60 that some commit IDs were missing and others incorrect, just because my scripts failed to catch all the relevant cases and I could not notice this with my eyes. Francis, the most reliable I could propose to you is to look for a string of 40 consecutive hex digits. But even then there is a risk : older kernels tend to pick from newer ones and sometimes double IDs slip through. Revert commits can as well induce you in error. > > > Don't you think that this link to the upstream commit is an important > > > information ? > > > > I do, which is why I have been putting it in the commits for the past 8 > > years. > > > > You are asking me to guarantee a specific pattern of words will always > > be used in the future, which is an impossible request, as I'm sure you > > will agree, as no one can predict the future. > > I think we should specify a format that everyone should use. I did > draft some new wording for stable_kernel_rules.txt which I should send > out... I'm not convinced it will be *that* useful, because there will always be a small number of backporting issues causing us not to have an exact upstream commit ID anyway. So if the process is not 100% reliable, I'm not sure that trying to make it more rigid to get close to 100% success without ever reaching it is worth the effort. Cheers, Willy -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html