suggestion: add a cherry pick without link option / or allow delete of cherry pick links

[epeleg]

It happens from time to time that you think you are working on some branch when actually you are on another.

If you have already checked in something on the wrong branch. [otherwise you can use the dropdown near the checkin button to check in to a different branch]

What I usually do in such a scenario is:

1. switch to correct branch.

2. cherry pick from wrong to correct branch.

3. copy the merged file(s)

4. delete new change set created on correct branch created by cherrypick.

5. copy the files back to the workspace (or just paste from clipboard if it was a single file).

6. check in the changes (now properly set in the correct branch).

7. delete the unwanted changeset that was created on the wrong branch.

If I could do the chery pick without leaving a link or if I could delete the link after performing the cherry-pick I could then just delete the miss-placed changeset and that's it.

Currently this is not possible because the existence of this link prevents me from deleting the changeset that was miss-placed in the wrong branch.

I added the suggestion here:

http://plasticscm.us...tion-or-allow-d

feel free to go and vote for it.

Eyal

[manu]

Hello Eyal,

we are thinking a a "move changesets to a new branch" feature. But thanks for inserting the suggestion!

[carpediemevive]

Is there any functionality to allow me to remove a changeset and turn it into a shelf instead? In other words, I revert my workspace to the point right before I checked in that changeset and instead of checking it in, I turn it into a shelf? That would allow me to remove the changeset, keep the changes, reapply them where they belong, and not have a link that potentially misrepresents the situation.

[manu]

I'll speak with Pablo about the "promote to shelve" feature, I really like it.

Thanks for the idea!

[Gerard Murphy]

As a workaround, what I do in this situation is to:-

 

1. Start a cherrypick on to the correct branch.

2. Process the merges, but do not commit.

3. Shelve the changes and undo them in the workspace. This drops the merge link introduced by the cherrypick.

4. Apply the shelf on the correct branch - I can also selectively revert the uncommitted changes, so I can cherrypick in space across the file system as well as in time across changesets.

5. Commit when I'm satisfied with the results.

6. Delete the original source changeset on the source branch. (See following commentary below)

 

This leads to pretty much the same functionality as say, 'graft / transplant' in Mercurial, which seems to be what is wanted here. Like the Mercurial functionality, the transplant is not tracked by the merge system, so if you don't delete the original source changeset, it will be reconsidered by any subsequent 'genuine' merge (which is a good thing if you transplanted partially and want to pick up all the changeset's changes the next time round - you just have to be careful when i it comes to seeing duplicated changes).

[calbzam]

Thanks @Gerard for sharing your workaround!

 

Regards,

Carlos

[Gerard Murphy]

1. I've got an update on this - having just tried my own suggested procedure today, what I find is that once the original changeset is deleted (in step #6), this will damage the shelf created in step #3.

 

2. Furthermore, I'm fairly sure that the changeset created in step #5 (which is good at that point) will be retroactively damaged in step #6. The workspace also gets into a strange state where changes to a file referenced in the deleted changeset can't be committed (and the diffs claim that the file has been created from new).

 

I don't want to repeat the verification of claim #2, as it's quite tricky to recover from.

 

I think that Plastic shares the 'base' of the deltas somehow between the two changesets and the shelf - once step #6 is done, that shared information is no longer valid.

 

I've seen this once before doing the same thing and put it down to a glitch / user error, but this is the second time, so I'd caution against using this procedure - or if you must do, don't carry out step #6, keep the redundant changeset instead.

 

I'm on Plastic Cloud, version 5.4.16.756.

[Gerard Murphy]

Arrgh! I've just been hit by this problem again - forgot my own advice not to delete the original redundant changeset and lo! - ended up with a corrupt commit, only this time the commit was a few behind the latest commit on the new branch. I was lucky this time in that although the changeset was corrupt in the repository, I still had local copies of the files in the correct state for that changeset in my local workspace. I couldn't fix this in Plastic at all, but as I sync with GitHub, I was able to rebuild a correct history using file copying and Git's interactive rebase, force push it to GitHub, delete the recent commits on the corrupted branch in Plastic and resync from GitHub. Not a fun experience.

This is the third time I've been bitten by this bug; can somebody please fix this?

Alternatively, I can live with the workaround that if there is a changeset that is invisibly linked with an older one, then any attempt to delete the older one is blocked. I've noticed that Plastic does do this check for when a shelf is based off a changeset - you can't delete the changeset until the shelf is deleted first. This could be extended to checking dependent changesets created by applying a shelf; that would at least stop me from losing commits. I'd rather that applying a shelf made a genuinely independent commit, though - nicer behaviour without surprises.

I'm using Plastic 7.0.16.1889 - Smashing Pumpkins - Cherub Rock.

[calbzam]

Hello,

Are you aware of the following feature?

http://blog.plasticscm.com/2016/11/move-changesets-to-different-branch.html

Regards,

Carlos.

 

[Gerard Murphy]

Hi Carlos - yes, I am - but I thought this only permits you to move a changeset from a branch head to a brand new branch.

You can't move a changeset on to an existing branch that already has commits of its own. The latter has been my use-case for the three instances of this problem.

(EDIT: ah - but I've realised now that you can make a brand new branch from the target branch the commit needs to be cherry picked on to - then you can merge the new branch back on to the original target branch. A bit roundabout, but it will do nicely.)

Regards,

Gerard

 

 

[calbzam]

Hi Gerard,

You are right that this feature only works for empty branches but I think your proposed workaround should work pretty good

Regards,

Carlos.