From: Junio C Hamano Date: Fri, 29 Jul 2016 17:15:26 GMT Subject: Re: Small trivial annoyance with the nice new builtin "git am" Message-ID: In-Reply-To: <20160729155012.GA29773@sigill.intra.peff.net> Jeff King 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.