Interactive staging of changed contents

[ytoporovskyy]

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.

[calbzam]

Hi,

Sorry for the delay. After reading your explanation, I still don't fully understand the use case.

Could you include some example so we can fully understand your workflow?

In Plastic, you can use Xlinks, if you want to link an external library/repo into your project. The Xlink will be pointing to a specific version of the library/repo https://docs.plasticscm.com/xlinks/plastic-scm-version-control-xlinks-guide

It's possible even to share the same library/repo between different projects: https://blog.plasticscm.com/2014/08/how-to-share-engine-repository-between.html

Regards,

Carlos.

[ytoporovskyy]

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).

 

[calbzam]

So basically, you would like to apply individual shelved file revisions but not applying the whole shelve that includes multiple changes you don't want to apply at that moment?

Regards,

Carlos.

[ytoporovskyy]

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.

[calbzam]

I will share your feedback with the product team.

Regards,

Carlos.