Hello team, Is there a way for me to know the root commit of a branch ? The use case would be for me to be able to know the age of a branch based on the default branch (main). I would take creation_date of the first commit

What do you mean by a "root commit of a branch"? If for example, I have this tree:

A---B---C----D-----R---N---X  branch "main"
          \              /
            \           /
             ---L---M--          branch "branch-a"

What would you consider as the root commit of branch-a? A/C or maybe L? If the answer is A, the answer is simple- since it is the first commit in the repository, it should be identical to the repository age so you can get the creation_date of the repository using the getRepository API.

For me, for branch-a it would be L. And if L does not exist, then Void.

L means you are looking for the first commit you pushed to the new branch after creating it? Because when branch a created it was firstly pointed to commit C

Indeed the root itself would be C But the closest to what I need for my use case (which is essentially to determine the age of a branch) is L.

Neither C nor L will be helpful for you, as you can create commit C on Monday, then create branch-a on Tuesday, and finally push a new commit L to branch-a on Wednesday. One feature that might be helpful for you is Auditing- you might use it to check when you created your branch.

L would still be helpful in that case, as what really matters is the first piece of extra data added to the branch (compared to the source commit). In that case it is L. The branch creation_date is just a "good enough proxy". I didn't mention it yet but we are trying to ensure that branches older than one month that contain PII are automatically deleted.

I'm not sure your process is valid, deleting a branch, doesn't mean the data is deleted. The commits that contain the PII might still exist. Have you considered using lakeFS' Garbage Collection?

Yes, we are aware of this, but before the GC runs properly, we understand that the branch (or the related objects) must at least be declared as deleted ?

In the above example, objects will be retained for 14 days after deletion by default

That is true. GC deletes three kinds of objects- 1. Uncommitted objects 2. Committed objects that were already deleted or replaced 3. Objects that are part of dangling commits (commits that aren't directly linked to by any child commit, branch, tag, or other reference) So if your branch's HEAD doesn't point to the objects with the PII (and also no other branch's HEAD does), the GC will remove it by the retention policy you defined

Do we agree that the problem remains to determine whether the age of the branch is higher than a certain threshold, and that it is impossible to do without the audit log ?

Not necessarily, dangling commits delete immediately by GC without any connection to the branch's age

But if the branch is not deleted, the commits will not be dangling ?

And the age of the branch is not what important here, the age of the object does! 🙂

But how am I able to determine which objects have been touched - relative to the main branch ?

I'm not 100% sure what you are trying to achieve. If you want an object with a PII to be deleted, you should make sure there's no branch that points to a commit that contains this object. There's is nothing to do with the branch's age.