4 ms·

I'm curious but not motivated enough to really search for it, but for ambiguous hash abbreviations, why not select the oldest, since presumably it was unique at

I'm curious but not motivated enough to really search for it, but for ambiguous hash abbreviations, why not select the oldest, since presumably it was unique at the time it was created? edit: I guess that information must not exist or I assume they'd be doing it.

emmelaich 10y ago
Yeah, I guess dates are only available for commits but not blobs or trees. This is suggested by the disambiguation listing; if there were dates they would be displayed I hope. I think approximate dates might be inferred, but since it might be misleading and costlier to determine it makes sense to leave it out - at least in this version of git.
- deleted 10y ago
  [deleted]
ludbb 10y ago
Dates are available for some objects, see http://stackoverflow.com/a/39930978/1832154 http://stackoverflow.com/a/39930978/1832154 for more details about what is/isn't available. The issue is a different one, I believe you're considering one specific situation while there are others to ponder. What would happen if someone copy & pasted part of the hash, or had some tool that always reduced that output to the first few digits, or other situations like these, how would you be able to tell that the user was actually after the oldest commit? It seems much easier to indicate there's a problem, a conflict, and let the user solve it.
teraflop 10y ago
That heuristic would work most of the time. But it rests on the assumption that "if commit A has an older timestamp than commit B, then any user who saw commit B must have also seen commit A", which is not reliable in a distributed version control system. It seems safer to just explicitly tell the user when they're trying to work with an ambiguous hash.
peff 10y ago
As others have noted, there's not always an unambiguous date for some object types (the best you can do for blobs is to find the first commit in which they appeared, and use its date). However, there'a more complicated issue with timestamps, with is that you care about what was in the repository of the person who generated the sha1, at the time of generation. So you could merge in history that includes older commits, and invalidate your sha1s with "older" objects. So the timestamp of interest is not the one in the objects themselves, but when they entered some particular repository (and not even some well-known repository; the local clone of whoever happened to generate the sha1). That being said, those two things correlate a lot in practice, and auto-picking the oldest commit might be a useful heuristic. It would be a fun project to implement as an option for `core.disambiguate`.

emmelaich 10y ago

Yeah, I guess dates are only available for commits but not blobs or trees. This is suggested by the disambiguation listing; if there were dates they would be displayed I hope. I think approximate dates might be inferred, but since it might be misleading and costlier to determine it makes sense to leave it out - at least in this version of git.

deleted 10y ago
[deleted]

ludbb 10y ago

Dates are available for some objects, see http://stackoverflow.com/a/39930978/1832154 http://stackoverflow.com/a/39930978/1832154 for more details about what is/isn't available. The issue is a different one, I believe you're considering one specific situation while there are others to ponder. What would happen if someone copy & pasted part of the hash, or had some tool that always reduced that output to the first few digits, or other situations like these, how would you be able to tell that the user was actually after the oldest commit? It seems much easier to indicate there's a problem, a conflict, and let the user solve it.

teraflop 10y ago

That heuristic would work most of the time. But it rests on the assumption that "if commit A has an older timestamp than commit B, then any user who saw commit B must have also seen commit A", which is not reliable in a distributed version control system. It seems safer to just explicitly tell the user when they're trying to work with an ambiguous hash.

peff 10y ago

As others have noted, there's not always an unambiguous date for some object types (the best you can do for blobs is to find the first commit in which they appeared, and use its date). However, there'a more complicated issue with timestamps, with is that you care about what was in the repository of the person who generated the sha1, at the time of generation. So you could merge in history that includes older commits, and invalidate your sha1s with "older" objects. So the timestamp of interest is not the one in the objects themselves, but when they entered some particular repository (and not even some well-known repository; the local clone of whoever happened to generate the sha1). That being said, those two things correlate a lot in practice, and auto-picking the oldest commit might be a useful heuristic. It would be a fun project to implement as an option for `core.disambiguate`.