On Fri, 28 Oct 2005, Junio C Hamano wrote: > > Sorry you lost me. I am not sure what you mean by "without > actually doing anything" part. The input to patch-id command in > the above pipe is (commit-object-name patch)*. The command > reads such a stream, and transforms it to a (patch-id > commit-object-name)* stream. In other words, the input > identifies each patch with a commit-object-name, and the command > condenses each patch to a patch-id, and spits them out, labelled > with commit-object-name. Note that git-patch-id will happily take a patch without the commit ID at the head, it just won't have a commit ID to match it up with. For such patches it will just spit it out with an all-zero commit-object-name. And that's very much by design. The point is that you can match up your (perhaps non-git) patches with what has been accepted. Which is why git-patch-id should always take non-git patches too, and then you can match them up by sorting by patch ID and doing "join -1" to match up duplicates. So git-patch-id will work with or without the commit ID, but the commit ID is then later needed to figure out _which_ commit you matched up. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Sat Oct 29 13:09:51 2005
This archive was generated by hypermail 2.1.8 : 2005-10-29 13:09:54 EST