Jeff King <peff@xxxxxxxx> writes: > Generally I would try to keep their definition near the function > interface which uses them (i.e., transport_push). But I don't feel that > strongly about it. I think that advice makes sense. > Your patch is already in 'next', so we will have to build on top rather > than squashing. So here it is with an actual commit message: If the patch were already in 'next', we would have to build on top, but I thought I kept it out of 'next' because I knew this deserved a bit more review time. Perhaps I screwed up, or you are reading the history incorrectly? ... goes and looks ... > -- >8 -- > Subject: [PATCH] clean up struct ref's nonfastforward field > > Each ref structure contains a "nonfastforward" field which > is set during push to show whether the ref rewound history. > Originally this was a single bit, but it was changed in > f25950f (push: Provide situational hints for non-fast-forward Whew. "git log remotes/ko/next..f25950f" says we are OK. I'm however tempted to keep this follow-up patch as separate without squashing. -- 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