On Wed, Mar 04, 2015 at 12:41:57PM -0800, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > > On Wed, Mar 04, 2015 at 04:06:17PM +0100, Michael J Gruber wrote: > > > >> Complexity: Was that due to replace refs? Other than that, it seemed to > >> be simple: max(parent generation numbers)+1. > > > > Calculating them is simple. Caching and storage is the bigger question. > > Yes, also having to handle the ones whose generation numbers haven't > been computed yet adds to the complexity. > > This one, and $gmane/264101, are a few instances of this known issue > raised here recently. I have been wondering if we can do something > along the following (these are not alternatives) as a cheaper > workaround: > > (1) Introduce '--skewed-timestamps[=(allow|warn|reject)' to all > commands that create new commit objects. If the committer > timestamp being used is older than any of the parent commits, > "warn" or "reject" depending on the setting. > > Make 'reject' the default for commands that are purely local > (i.e. recording your own progress by cherry-picking, > committing, rebasing, reverting, etc.) and 'warn' the default > for commands that merge other peoples' history that you may > lack the power to rewind and correct (e.g. 'pull' and 'merge' > from remote tracking refs).
Please note that a common cause (for me, at least) of skewed timestamps is importing from a foreign VCS. Mike -- 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
