On Wed, Dec 07, 2011 at 10:35:00PM -0500, Nicolas Pitre wrote: > And I don't think this particular case is interesting anyway as the > reflogs for the various branches alre already involved. I was thinking > more about the "git fetch git://some.random.repo foobar" case where the > summary also explicitly shows: > > From: git://some.random.repo > ...... foobar -> FETCH_HEAD > > In that case the only reference to the fetched branch is stored in > FETCH_HEAD and that is what might be worthwile for a reflog. I agree that is the interesting case. Perhaps we could just not bother writing the other case into the reflog at all. So the reflog would be sensible and contain only the set of things they had fetched or pulled explicitly by URL. If they really want to do a multi-ref one-off fetch from some URL, then we write multiple reflog entries. But at least the user is very aware of what they've done, so they're not surprised by the reflog advancing by more than 1 entry. -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