Re: Small trivial annoyance with the nice new builtin "git am"
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 29, 2016, 17:15 UTC
- Message-ID
- <xmqq7fc4pdqp.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20160729155012.GA29773@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 23 quoted lines
> 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.