Re: I have end-of-lifed cvsps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 18, 2013 at 11:27:10AM -0500, Eric S. Raymond wrote:

> For use in reposurgeon I have defined a generic cross-VCS reference to
> commit I call an "action stamp"; it consists of an RFC3339 date followed by 
> a committer email address. Here's an example:
> 
> 	 2013-02-06T09:35:10Z!esr@xxxxxxxxxxx
> 
> In any VCS with changesets (git, Subversion, bzr, Mercurial) this
> almost always suffices to uniquely identify a commit. The "almost" is
> because in these systems it is possible for a user to do multiple commits
> in the same second.

FWIW, this has quite a few collisions in git.git:

  $ git log --format='%ct %ce' | sort | uniq -c | sort -rn | head
     22 1172221032 normalperson@xxxxxxxx
     22 1172221031 normalperson@xxxxxxxx
     22 1172221029 normalperson@xxxxxxxx
     21 1190197351 gitster@xxxxxxxxx
     21 1172221030 normalperson@xxxxxxxx
     20 1190197350 gitster@xxxxxxxxx
     17 1172221033 normalperson@xxxxxxxx
     15 1263457676 gitster@xxxxxxxxx
     15 1193717011 gitster@xxxxxxxxx
     14 1367447590 gitster@xxxxxxxxx

In git, it may happen quite a bit during "git am" or "git rebase", in
which a large number of commits are replayed in a tight loop. You can
use the author timestamp instead, but it also collides (try "%at %ae" in
the above command instead).

> And now you know why I wish git had subsecond timestamp resolution!  If it
> did, uniqueness of these in a git stream could be guaranteed.

It's still not guaranteed. Even with sufficient resolution that no two
operations could possibly complete in the same time unit, clocks do not
always march forward. They get reset, they may skew from machine to
machine, the same operation may happen on different machines, etc. The
probability of such collisions is significantly reduced, though, if only
because the extra precision adds an essentially random factor.

But in some cases you might even see the same commit "replayed" on top
of different parts of the graph, or affecting different paths (e.g., by
filter-branch). I.e., no matter what your precision, multiple hacked-up
views of the changeset will still always have that same timestamp.

-Peff
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]