ytoporovskyy

I'm not sure what you mean. I believe this is exactly what I've done in the OP. Have you tried this from WSL and it works for you?

Running `cm repository list local` in WSL simply gives "Error: Connection refused". Note that it gives the same output for any ip/host which is definitely inaccessible, e.g. `cm repo list localhost:9001`. It seems my server definitely runs on port 8084. It also tried to disable any firewall which could prohibit traffic between WSL/Windows, but no luck. Far as I can tell every port should be accessbile from WSL.

If we could apply individual changes from a shelve, e.g. by bringing up the plastic merge tool, even when there are no conflicts, this would solve part of the problem. It would still have the problem that at the end of one 'step', the shelve would still contain all the changes, even the checked in ones, whereas with `git add -p` it would only contain changes which I did not check in during preceding steps. This would mean re-merging every change from the shelve during each step, which is usually trivial but not always.

Xlinks or the like don't work in this case, we can't make any assumptions about how 'external' repos are set up (or even that they exist, or are accessible for download to all our devs). I've since found a good workflow with works in git or plastic: Assume for the sake of simplicity that we recieved some code in the form of a .tar archive. We know that these changes should be applied to changeset 1234 on branch /upstream. We never make changes to the branch /upstream except when we get new updates from the 3rd party vendor. We replace the entire contents of the working tree at changeset 1234 with the new contents of the .tar archive and check it in. Then we merge the new tip of the /upstream branch into /main (or into whatever other branch where we typically work). I would still love to have some functionality like `git add -p' in plastic. It was my bread and butter working when in git and I sorely miss it. This situation is just one use case, and I have a workaround now, but more generally "interactive staging" would be incredibly useful. Currently what I do: 1. make a bunch of changes 2. shelve the changes (call this shelve changeset 123) 3. undo everything except one small isolated set of changes (look at diffs in plastic, switch text editor, navigate to the relevant file, edit file, jump back to plastic, check diff again, repeat for every change) 4. check in 5. unshelve the changes, which almost always creates conflicts. resolve those conflicts. 6. go to 3 (until all the desired changes are checked in) This is incredible tedious because I end up jumping around between applications a lot (thousands of times for a moderately complex set of changes?), with `git add -p` the workflow for rejecting/staging existing hunks is easy and keeps me in a single application. When I need to edit a hunk, `git add -p` gives me a very easy method to jump to my text editor (I don't have to navigate to files manually, it will open my editor viewing an appropriate file to edit the hunk directly).

Do you mean try the cm command with port 8087? This doesn't work ("Error: Connection refused") Or do you mean to run the plasticd server on port 8087? I'm not sure how to do that, but I know that I didn't change the default settings for the port when installing.

I'm using Plastic Cloud in distributed mode (so running a local server) on Windows. Everything works great. Now I want to also use the plastic command line client `cm` from WSL. This seems straightforward enough, installed CM as per Linux instructions. However I am unable to get `cm` to connect to the local server which is running on the Windows localhost. In a WINDOWS shell these all work: cm.exe repository list 127.0.0.1:8084 cm.exe repository list localhost:8084 cm.exe repository list local Now in the WSL shell this will fail: cm repository list "$(hostname).local:8084" with a timeout error Error: Failed to connect to DESKTOP-QC45BRD.local:8084 within the 3000 ms timeout. To increase the timeout, set SocketConnectTimeoutMillisec in client.conf. If the timeout happens during push/pull, configure server.conf. I've made sure that the native localhost is indeed accessible from WSL, for example, `ssh $(hostname).local` will work. Is there any way to get this working?

I'm often working with patches for 3rd party code which I need integrate into our plastic repo, along with our own (1st party) changes to this 3rd party code. With git this process was very straightforward. There are different methodologies for different situations: - copy the updated contents of the 3rd party library into the working tree, which naturally removed our own modifications, then use `git add -p' to recover our modifications as needed. - cherry pick any commits corresponding to our modifications (if those modifications represent a large "feature" which is easily lost in a sea of individual small patch hunks). - `git apply --reject' patch files and manually fix the rejected hunks. With plastic I have not really found a good way to replicate any of these workflows. The closest thing we have is the "diff changes" window but it doesn't let you apply/stage individual hunks. Plastic doesn't seem to have any concept of a staging area, so I'm doubtful that `git add -p' could even be supported (this single command is the workhorse of this entire process). Cherry picking in plastic does nothing if you're cherry picking an ancestor of your current branch tip (tells me "merge destination already contains source changes", yes I understand what this means and why plastic rejects it, but its exactly what I want to do in this case - integrate the same change *again*). I'm wondering if anyone has found some equivalent workflows to those above. At this point I've resorted to applying my changes manually (i.e. with a text editor); or creating a git repository temporarily with one commit (the current contents) so I can simply use those workflows above. But this is highly unsatisfactory, as I'm not able to work with the repo history directly, have to constantly use `cm blame` to track down origins of changes, although blame and the 2d revision tree in the GUI are pretty good, it gets quite tedious to constantly navigate back & forth for hundreds of changes.