On Mon, Aug 01, 2016 at 10:49:12AM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > >> So maybe we would have to put reset_ident_date() at the end of the > >> function instead, at least after git_committer_info() is called. > > > > Yes, although "reset and end" still feels a bit weird to me. > > > > I'd almost prefer to just have long-running programs insert resets at > > strategic points. > > Certainly "reset at the end" feels weird but it can be explained as > "for a one-shot thing we use the first time of the default date and > it gives a consistent timestamp; conceptually, things that make > multiple commits are like doing that one-shot thing multiple times > in a row." > > When viewed that way, it is not _too_ bad, I would guess. I think what bothers me is that you could use similar logic for "reset at the beginning". The problem is that we don't know when "the beginning" is. I thought it was inside commit_tree_extended(), but for some operations, it's not, as Paul showed. So when is "the end"? Is it at the end of commit_tree_extended()? I'm not sure. Already we know it depends on whether you consider the ref update part of the same operation. Whether that matters is debatable. Are there other cases (an obvious one would be the human-readable bits printed by git-commit, but it looks like those are done beforehand)? Even if we do check every case, though, it seems like a fragile assumption to be making. So at this point I think I'd lean towards programs which have multiple logical commit operations explicitly saying "I am starting a new operation". It may be that we end up attaching more to that in the long run than just timestamp resets, too (i.e., what other cached data might there be that used to happen in separate sub-processes?). -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