one useful side effect of writing a git clone is I can make it write deliberate malformed commits and see how git handles them. some findings: - commits must have a `tree` field - commits may lack an `author` or `committer` field
-
Show this thread
-
i.e. lacking a `tree` field will crash git when trying read your logs, do checkouts, perform merges -- a commit with no tree is meaningless a commit with no `author`/`committer` will simply display without those fields in the logs
1 reply 0 retweets 1 likeShow this thread -
one behavioural element is that rev-list and merge-base use the committer field's timestamp to prioritise commits when searching the graph -- these commands still work with missing `committer` fields
1 reply 0 retweets 1 likeShow this thread -
in the case of rev-list, it might result in commits changing order, or in particularly bad cases, in some parts of the graph not being reached merge-base uses timestamps as an optimisation, not as a halting condition, so is unaffected in terms of correctness
1 reply 0 retweets 0 likesShow this thread -
tangent: rewriting in rust has shown me that making the data models namespaced under Database was possibly a mistake, though you need to bridge code to serialise/deserialise them
1 reply 0 retweets 3 likesShow this thread -
(this is a reason I'm mad about how Ord works: commits have multiple senses in which they're ordered -- you can order by their timestamp (total order), or by their causal position in the history graph (partial order))
3 replies 0 retweets 1 likeShow this thread
That seems like a fundamentally different thing than what `Ord` represents though. If you want to use something as a key for a BTreeMap, there needs to be one canonical ordering. Business logic doesn't have to conform to a generic trait
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.