Jeff King <p...@peff.net>:
> 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.
That's a good point - a repeatable real-world case in which we can
expect that behavior.
This case could be solved, though, with a slight tweak to the commit generator
in git (given subsecond timestamps). It could keep the time of last commit
and stall by an arbitrary small amount, enough to show up as a timestamp
difference.
Action stamps work pretty well inside reposurgeon because they're
mainly used to identify commits from older VCSes that can't run that
fast. Collisions are theoretically possible but I'm never seen one in
the wild.
> You can
> use the author timestamp instead, but it also collides (try "%at %ae" in
> the above command instead).
Yes, obviously for the same reason.
> > 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.
Right...but the *same person* submitting operations from *different
machines* within the time window required to be caught by these effects
is at worst fantastically unlikely. That case is exactly why action
stamps have an email part.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
