Michael Haggerty wrote: > On 11/20/2014 12:22 AM, Stefan Beller wrote: >> 3. Delete the reflog when the corresponding reference is deleted [1]. >> >> also as one transaction? > > It would be a side-effect of committing a transaction that contains a > reference deletion. The deletion of the reflog would be done at the same > time that the rest of the transaction is committed, and again the > calling code wouldn't have to explicitly worry about the reflogs. There is "git reflog delete <ref>", for when you have logallrefupdates disabled and had explicitly enabled reflogs for a particular ref and now want to turn it off. [...] > So this design has the caller serializing all reflog entries into > separate ref_update structs (which implies that they are held in RAM!) > only for ref_transaction_commit() to scan through all ref_updates > looking for reflog updates that go together so that they can be > processed as a whole. In other words, the caller picks the reflog apart > and then ref_transaction_commit() glues it back together. It's all very > contrived. I think there is a simpler and more efficient way to implement this. transaction_update_reflog() can append to a .lock file. transaction_commit() then would rename it into place. There is some fuss about naming the .lock file to avoid D/F conflicts, which is a topic for a separate message. > I suggest that the caller only be responsible for deciding which reflog > entries to keep (by supplying a callback function), That could be handy. The basic operations described before would still be needed, though: create a new reflog with one entry, for new refs append an entry to a reflog, for ref updates (and the associated symref reflog update) copy (or rename --- that's a more minor detail) a reflog, for renaming refs delete a reflog, for "git reflog delete" And the "filter reflog" operation you are describing is implementable using those four operations, with no performance hit when dealing with reflogs stored in the files backend. Providing these operations doesn't prevent adding "filter reflog using callback" later if it turns out to be the right operation for other backends. It could turn out that some other primitive operations that are easy as an SQL operation is more useful, like "delete reflog entry" (without iterating over the others) or "expire entries older than <date>". The nice thing is that adding those wouldn't break any code using the initial four operations described above. So this seems like a good starting point. [...] > I would love to work on this but unfortunately have way too much on my > plate right now. Of course code is always an easy way to change my mind, when the time comes. ;-) Thanks, Jonathan -- 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