Hi Francois-Xavier, On Thu, 15 Oct 2015, Francois-Xavier Le Bail wrote: > On 13/10/2015 15:29, Philip Oakley wrote: > > > Thus the only sha1 numbers that could be used are those that are > > within the (possibly implied) instruction sheet (which will list the > > current sha1s that will be converted by rebase to new sha1's). > > Yes. So what happens for commits that are in the pick list but then end up not being rewritten at all, e.g. when a patch has been applied upstream (and the --cherry logic did not detect that) and then you end up with a "No changes to commit"? And what if a patch ends up in merge conflicts and the user just skips it? And what if the referenced commit is to be picked *afterwards* due to the commits being reordered? It would appear that the strategy you propose is still too ill-defined to make for a robust feature. Ciao, Johannes P.S.: The recommended way to refer to a commit is not only using the SHA-1 but also mentioning the one-line, and even the date. That way, even rebased commits can found most of the time. This is not fool-proof, by far, of course, but still better than trying to rewrite a SHA-1 and failing. -- 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