On Tue, Jun 14, 2016 at 04:36:59PM +0700, Duy Nguyen wrote: > On Tue, Jun 14, 2016 at 6:58 AM, Jeff King <peff@xxxxxxxx> wrote: > > This was changed in 10a6cc8 (fetch --prune: Run prune before > > fetching, 2014-01-02), but it seems that nobody in that > > discussion realized we were advertising the "after" > > explicitly. > > Ah... ok. Good to know it's moved up top on purpose because I almost > tried to move it down :) It's irritating that current output looks > like this > > <delete ref> > <delete ref> > <delete ref> > remote: <random progress lines> > <update ref> > <update ref> > <update ref> > > It probably looks better if we can move the <delete ref> part after > "remote: ..." lines (iow still _after_ fetch, but _before_ ref > updates), e.g. > > remote: <random progress lines> > <delete ref> > <delete ref> > <delete ref> > <update ref> > <update ref> > <update ref> I don't think it would be hard to do the deletion separate from the status-printing (in the worst case, you could simply queue the list of deleted refs and then print them later). That might put the status lines for the deletions farther from any errors or warnings we print when doing the actual deletions, but in theory the error lines are self-contained and can stand on their own. > If we do so, there's no need to update document. But I don't know, > maybe it's not worth doing. I think the documentation should be updated either way. This is not about the ordering in the status table, but rather about the order of the real operations. The user may care about that ordering if they want to know what races are possible, or what would happen if the packfile fetch failed (we'd already have deleted the old refs, but wouldn't fetch the new ones). -Peff -- 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