On Fri, Jul 29, 2016 at 11:15:39AM -0700, Junio C Hamano wrote:
> > It does feel a little backwards to cache by default, and then try to
> > catch all the places that want to reset. Another way of thinking about
> > it would be to almost _never_ cache, but let a few callsites like (the
> > commit object creation) explicitly ask for a stable timestamp between
> > the author and committer.
>
> ... and the reflog?
I left that part out. I can't decide if it is a bug or a feature that
the reflog retains the same timestamp.
I.e., I'm not sure it would be wrong to do:
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 12290d2..465cfc5 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2886,6 +2886,8 @@ static int log_ref_write_1(const char *refname, const
unsigned char *old_sha1,
logfd = open(logfile->buf, oflags);
if (logfd < 0)
return 0;
+
+ reset_ident_date();
result = log_ref_write_fd(logfd, old_sha1, new_sha1,
git_committer_info(0), msg);
if (result) {
on top. If somebody writes a lot of refs without updating any commit
objects, should those all have a stable timestamp or not?
On the one hand, moving the timestamp reflects reality.
On the other, I have done dirty things in the past like "undoing" the
results of somebody's mistaken:
git clone ...
git push --mirror ;# oops, this deletes everything except master!
by grouping ref updates according to their reflog mtimes.
So I kind of punted by not changing it but also not making any claims
either way. :)
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
