[jgit-dev] Grafts/replace design

[Robin Rosenberg <robin.rosenberg@xxxxxxxxxx>]

This list is way too silent...

I want to discuss design issue that pops up in adding the grafts/replace mechanism. Unfortunately Gerrit
is not ideal and the audience is perhaps too narrow.

Usually you want the default behavior, i.e. apply grafts, replace the content of objects everywhere from peeling refs to checkout. The obvious exceptions are fsck, gc, push, fetch where content and refs should be handled the way the Creator formed them.

The core classes involved in the actual replacement are ObjectReader, RevWalk and ObjectWalk. We can do grafts within the latter two. We just need to pass the grafting info and only a few interfaces need to change, e.g. we can add a parameter to the constructor, or add getter/setters.

For replacement of content, the ObjectReader is the core class. It does not always know about which repository or even object database it is working on so we need to pass information around from the caller so it knows what to replace.

That's an extra parameter that needs to be added to any entry point from the user to the possible creation of an ObjectReader. 

The next step is tricker.

The Repository knows about grafts and replacements, so we can just ask it, but then we actually share instances, for efficiency and smoothness within the application. Since
the Repositories are shared we cannot just flip a flag to turn off the replacement map.

We can add parameter to most methods in Repository and pass it around, all the way down to the instantiation of ObjectReaders. That's a lot of changed calls, some of which can probably be kept in their old form, with replacing behavior, and the new form allows the caller to choose the behavior.

The other option I see is to create a new Repository instance working with the same git repository, but with a different opinion on what to replace. The caller can create that new instance or the callee (e.g. the Push task can decide that what it got isn't good enough). Back to the sharing. Just newing a Repository with the same parameters might not be optimal in a multithreaded world. An alternative is to create a delegating implementation that shares the original instance, but has a different behavior when asked about object replacement.

The refactoring of Repository for delegation is in https://git.eclipse.org/r/#/c/7428/2. The depending patch that uses this is gone bad, so don't look there.

-- robin