Matthew L Foster wrote:
--- Theodore Tso <tytso@xxxxxxx> wrote:
In git, we believe that all repositories are equal, and that any sense
that a particular repository is the "master" or the "mainline" is
strictly speaking, a matter of convention. What Matthew I think is
asking for is direct support in git for that notion.
No. I merely think git should try harder to ensure that commit order is consistent with time
order, it really should (somehow) be impossible for git and gitweb.cgi to have commit dates ~2
days in the future. I think replication is a separate issue. In a distributed system the only
"time" that makes any sense or is the most relevant in many situations and most importantly is the
only thing that can be semi-trusted is local time. "Creation date" is basically just random text
someone entered, there is no guarantee and you are tempting inconsistent time order. And git
shouldn't be so fragile as to need each and every git server to have time set semi-correctly, but
I guess it's a bigger deal to non-developers as we actually use time and also believe even web
interfaces should have consistency and integrity.
-Matt
See, the confusion here seems to be that you think that not caring about
the time attached to a commit for anything more than a heuristic makes
git fragile.
I think that the rest of the git developers prefer to see this as a
feature that makes git more robust in the face of something that they
might not have any control over (or desire to control).
That said, if *you* are managing a repository, it shouldn't be difficult
to enforce the kind of rule that you are asking for. Simply implement a
pre-commit hook that checks all commits that will be added to *your*
repo to make sure that time is monotonically increasing from the last
commit, and that it does not pass "now".
So if you receive a commit from a developer that violates this rule, you
can send the commit back to them with a request to fix their system
time, and recreate the patch/series.
I just don't think that any of the kernel developers feel the need to
police any one else's clocks . . . they're more interested in the
contents of the patch.
Regards,
Rogan
-
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