Jeff King <p...@peff.net> writes: > On Thu, Jul 28, 2016 at 05:37:08PM -0700, Linus Torvalds wrote: > >> > and then to sprinkle calls liberally through builtin-ified programs when >> > they move from one unit of work to the next. >> >> Maybe we can just add it to the end of commit_tree_extended(), and >> just say "the cache is reset between commits". >> >> That way there is no sprinking in random places. > > Hmm, yeah, that might work. As you mentioned, there are cases where we > really do want the timestamps to match (especially between author and > committer). So we would not want this reset to kick in where callers > would not want it. > > So I'm trying to play devil's advocate and think of a case where > somebody would not want the time reset after creating a commit. > > One obvious impact would be reflog entries, since we would reset the > time between the object creation and the ref write (so your reflog entry > would sometimes be a second or more after the commit time it writes). > I'm not sure how much anybody _cares_ about that; they're much less > intimate than author/committer times.
As long as it is understood that a commit object is created and then a ref is updated to point at it in this order, I do not think there is any confusion on the party who reads the reflog, I would think. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
