From: Junio C Hamano Date: Mon, 26 Mar 2012 20:05:52 GMT Subject: Re: [PATCH v3] push: Provide situational hints for non-fast-forward errors Message-ID: <7vk427nn4v.fsf@alter.siamese.dyndns.org> In-Reply-To: <20120326195150.GA13098@sigill.intra.peff.net> Jeff King 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.