Hi Thiago, Thiago Farina wrote: > I see that no one commentted in the patch, but I can't see it on > http://git.kernel.org/?p=git/git.git;a=summary, so I'm not sure if it > was accepted. > > What is the easiest way to verify if the patch was committed? Good question. When no one comments on a patch, that is usually a bad sign. In this case, I think the patch is good and I was too lazy to comment on it (sorry). | $ git log --oneline --author=Thiago origin/pu | 183113a string_list: Add STRING_LIST_INIT macro and make use of it. | [...] | $ git branch tf/string-list-init 183113a | $ git branch -r --contains tf/string-list-init | origin/pu | $ So it has been queued in "pu" but not graduated to "next" yet. Side note. From the description of the "pu" branch in origin/todo:MaintNotes The "pu" branch, and topic branches that are only in "pu", are subject to rebasing in general. By the above definition of how "next" works, you can tell that this branch will contain quite experimental and obviously broken stuff. it might sound like Junio thinks your patch is obviously broken! I suspect that description of "pu" is intended for testers (meaning: try this branch only if you found "next" too boring and like writing bug reports) rather than patch authors[1]. Especially during a release candidate period (which this is), promising new features are often queued to "pu" and only merged to "next" when Junio has had time to look them over again. HTH, Jonathan [1] Maybe it could be clarified: how about inserting "sometimes" before "contain"? ... you can tell that this branch will sometimes contain quite experimental and obviously broken stuff. -- 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