Hello,
I did ask this by irc recently, unfortunately I ended up being disconnected for a long while immediately afterwards so my apologies if someone has already answered my questions.
How do you pull patches from a source repository into the destination repository and have them act upon their files in a specific sub-directory of the destination?
Basically mounting the result of the source repository’s patches within the destination.
For example something like the following:
#mkdir repo_unified
#cd repo_unified
#pijul init
#pijul pull …/repo_client --into-directory ./client
#pijul pull …/repo_server --into-directory ./server
#tree …/
…/
–repo_client
– --f0
– --f1
–repo_server
– --f0
– --f2
–repo_unified
– --client
– -- --f0
– -- --f1
– --server
– -- --f0
– -- --f2
To me this seems like there is an implicit ‘pijul mv’ after the last pijul add or mv of a directory/file.
Ideally there would be some way to make sure any subsequent pulls from those repositories got automatically directed down into the appropriate sub-directory.
Pulling each repository one at a time and then individually 'pijul mv’ing each file into the appropriate sub-directory works but is a bit nasty. Any newly added files at the sources have to be noticed and given the same treatment, and they are open to conflict as would be seen with files f0 in the above example.
I’m sure there are complexities with an automated solution though… definitely don’t want to push the mv patches back to the sources, but what about when just a sub-directory of the unified repo is pulled? Either seems fine.
What about when the entirety of the unified repo is pulled? Including the mvs seems necessary to keep things sane.
The whole situation suggests to me that things would be simpler if all repositories were created like so:
#tree …/
…/
–repo_convenient_for_mounting
– --.pijul
– -- --etc etc etc
– --a_root_dir_which_contains_absolutely_everything_recorded
– -- --f1
– -- --f2
Perhaps I should start doing that but it doesn’t solve the problem with other repositories.
A related question is: how do you ‘unify’ two conflicting sets of patches, operating on two different files according to pijul’s idea of identity, when you know that the two files are conceptually the same thing?
For (a slightly contrived) example:
#mkdir repo_proto_impl
#cd repo_proto_impl
#pijul init
#pijul pull …/repo_client
#pijul pull …/repo_server
#tree …/
…/
–repo_client
– --client
– --protocol_info
–repo_server
– --server
– --protocol_info
–repo_proto_impl
– --client
– --server
– --protocol_info.
– --protocol_info.
I want to be able to do something like:
#pijul unify protocol_info. protocol_info.
and have the protocol_info be the result of the merged sets of patches, and any future patches pulled from the client and server repos, without any (unnecessary) conflicts.
Maybe it doesn’t make sense it pijul terms, but it does seem sensible conceptually.
The only solution I currently see is a little dance of patch making in the downstream followed by pushing a patch upstream to at least one repository, which will conflict, and having them merge it in the correct way so that the identity of the two files in pijul terms is unified. I could be wrong though, given how little I know about pijul.
At first I thought this would be a very unusual occurrence, but now I’m not so sure. The split identity extends to directories and it seems plausible that, even within a single company, it will happen quite a lot as utility code is moved between repositories and has to be maintained for a while.
The Motivation: I started looking into pijul, as an alternative to darcs, in an exploration of using a patch-based monolithic repository. pijul seems pretty raw, with limited cli options and no machine-readable outputs, compared to darcs but it’s model seems much more suitable to a monolithic repository supporting multiple products all with long-lived branches… so it’s probably worth persevering.
It’s starting to seem a single monolithic repos might even be the correct way to structure a company’s code with pijul.
I also hoped that pijul might solve a particular problem I had with darcs… I would like to be able to go back to a patch, buried under many dependants and tags, and add some information. In one particular usage to mark a patch that introduced a bug. Then any repository that has the updated version of the patch propagated to it will be able to determine which products have the bug.
In darcs even with rebasing the identity of all patches dependant on the target will be changed… you have to try and get all the new history propagated and the old obliterated, everywhere.
Perhaps pijul has more flexible patch metadata to handle this situation? Perhaps the patching of patches I’ve heard mentioned could do it?
Sorry, a much longer message than originally intended, so…
Thanks!