Allow handling melding a sparse "files-from" like file subset into a destination source repo which is expensive (slow) to crawl looking for destination content not among the source subset.
Enhancement suggestion, allow handling melding a sparse "files-from" like file subset into a destination source repo which is expensive (slow) to crawl looking for destination content not among the source subset.
So I've got a DESTINATION as a megarepo of code as a destination of a desired meld merge; that repo mirror is non-local and lazily loaded (copied over network) when any directory/file is accessed which can be slow.
As a SOURCE of stuff I want to meld I've got a very sparse subset of scattered files / directories which were e.g. copied out of that mega-repo because they were modified using something like a selective tar or rsync with an explicit "files-from" list for just the interesting / changed files to be "stashed" / exported etc. There could be many different sparse parts of the megarepo tree included in the SOURCE files which I've copied out and want to meld FROM out TO the network repo mirror.
So if both the sparse source tree and the megarepo start with some path like ...something.../myrepo e.g SOURCE to meld: ~/mysubset_copy/myrepo/... DESTINATION to meld: /mnt/megarepo/myrepo/...
If just running meld ~/mysubset_copy/myrepo /mnt/megarepo/myrepo
I believe it'll basically crawl the /mnt/megarepo/myrepo
tree looking for different stuff not appearing in ~/mysubset_copy/myrepo
and conversely as well. But the former operation is far too slow to be considered (maybe millions of files over a slow network, think of something like AOSP or whatever) and is not necessarily desirable if the use case is a unidirectional meld
FROM SOURCE to DESTINATION.
So I don't know what UI/UX encapsulation might be interesting to the project to consider ameliorating this sort of use case but it feels like there might be some enhancement that could allow say omitting certain directories from consideration or more particularly constraining the differencing to ONLY files/directories listed on either the LHS (e.g. SOURCE) or RHS (e.g. destination) and maybe their children (selectively?) and NOT a bilateral difference.
I guess this sounds like a somewhat niche case relating to huge repos that are expensive to crawl but I think maybe there could be much more general utility in some possible enhancements which could address this as a sub use case, for instance a way to label one side of the meld as immutable so it'd be uninteresting / impossible to meld anything from the right side to the left side so no point necessarily to crawl the right side if files / directories appear there not already on the left etc.
Just sharing an idea; thanks for the great tool / work!