On Fri, Jul 29, 2016 at 2:32 AM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Jul 28, 2016 at 5:21 PM, Jeff King <peff@xxxxxxxx> wrote: >> >> I do wonder if you would be happier giving each commit a "fake" >> monotonically increasing time, so they are correctly ordered by commit >> date. > > No, that would be nasty, partly for the corner case you mention, but > partly because I just think it's wrong to try to lie about reality. > > The reason I noticed this in the first place was actually that I just > wanted to take a look whether things had gotten slower or faster over > time, and see how many patches per second I get from the patch-bombs > Andrew sends me. > > So getting real time was what I was looking for. Great! > Also, before somebody asks: the reason git has always cached the > "default time" string is because there's a reverse annoying thing, > which is looking up time twice, and getting a difference of a second > between author times and committer times just because of bad luck. > That makes no sense either, and is actually why we have that > "ident_default_date()" cache thing going on. > > So we do want to cache things for a single commit, it's just that for > things like "git am" (or, like Junio wondered, "git rebase" - I didn't > check) we probabyl just just flush the cache in between commits. When Junio wrote: > I have a suspicion that we would see more and more breakages like > this in the near future, as there are folks trying to redo multi-commit > commands in a single process. he was maybe talking about my patch series to libify `git apply` and use that in `git am` (which is itself used by `git rebase` when not in interactive mode): https://public-inbox.org/git/20160627182429.31550-1-chriscool%40tuxfamily.org/ that will likely mean more patches with the same real time anyway especially with split-index on (see "Performance numbers" in that email). -- 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