Why it is not allowed to undo or revert a file during merges?

[Anton]

Why it is allowed to introduce new changes while merging but it is not allowed to undo existing changes from the source branch? Isn't it a non sense?

I often want to revert some occasional changes while merging but I am lazy to switch branches for this.

[calbzam]

Hi,

In Plastic, the basic unit is the changeset (not the file).

When you are running a merge, you are merging the whole changeset (not a subset of individual files). That's why you can't avoid to merge a specific file change during a merge.

We do that to keep the merge tracking. 

Regards,

Carlos.

 

[Anton]

23 hours ago, calbzam said:

In Plastic, the basic unit is the changeset (not the file).

When you are running a merge, you are merging the whole changeset (not a subset of individual files). That's why you can't avoid to merge a specific file change during a merge.

We do that to keep the merge tracking.

Thank you Carlos!

But this is a matter of UX (behind the scenes you can do anything you have to to comply requirements of your server).

And it is still not clear why I can introduce new changes to the merge. I mean I can copy-paste old content of a file doing a manual revert, right? Why cannot you allow us to do the same thing in a straight forward way through undo?

[calbzam]

Hi,

This behavior is a core thing. In Plastic 3 (very old Plastic version) the merges were handled per file. It was a pain. In terms of performance and simplicity for the merge tracking the merges are currently handled per changeset (the changeset is the basic unit). 

I the following thread we also handled this topic:

 

Quote

Changesets are atomic, you can't cherry pick individual files from them, because then the merge tracking would fall apart.  We went from a non-atomic system (Clearcase) to Plastic and it took a while for people to grasp the concept. 

Regards,

Carlos.

[Anton]

On 1/15/2021 at 2:57 PM, calbzam said:

Hi,

This behavior is a core thing. In Plastic 3 (very old Plastic version) the merges were handled per file. It was a pain. In terms of performance and simplicity for the merge tracking the merges are currently handled per changeset (the changeset is the basic unit). 

I the following thread we also handled this topic:

Yeah, thank you Carlos.

And this guys needs exactly what I need. Some people commited a trash (maybe some unintentional changes) I would like to do a cleanup or to ignore (undo) wrong things before I will do a check-in. I did that all the time when I worked with Git. 

 

 

[calbzam]

Hi @Anton, yo mean that you would line not to merge some specific revisions from a task branch? You can integrate only some specific changesets via cherry pick but you cannot avoid to merge somespecific file revisions inside a changeset.

Could you let us know more details of your integration workflow? Do you pass tests in the task branch to be sure the task is ready to merged into main?

Regards,

Carlos.

[Anton]

Assume someone worked in a branch and did some commits (created changesets).

Then I am responsible for merging this branch into the /main. I do this merge and what I have is a lot of pending changes what is the sum of all changes in this branch. Right?

I should review those changes and checking them what completes the merge and pushes everything to the server. Right?

Now the common thing which happens is that I find some minor errors and (not to delay everything) I want to fix them by myself before I checking the reviewed branch. Sometimes I see that people commit something that should not be changed like an artist committing a change in a unity scene file. Do you understand? Maybe he was testing something I do not know but he should not touch scene files. So I do not want to dig deeper, what I want is to exclude the entire file from the merge. What I want is to do a single file undo from this pending changes and I do not care if this was changed in a branch.

So when I worked with Git the process was the same. I have a local merge-commit and before I pull it to the server I can amend its content easily.

[calbzam]

Hi @Anton, why don't you perform the task branch code review begore running the merge? it's the more natural way to do it in Plastic. This way, you will merging a branch only when it's reviewed, the tests are ok and it's ready to be integrated. If the code review finds some issues that need to be fixed, they can be addressed in the task branch before the merge.

http://blog.plasticscm.com/2019/10/improving-new-plastic-code-review-system-part-i.html

Plastic doesn't support any operation that invoves rewritting the branch history (rebase, ammend, merge fast forward...) and you cannot partially merge a branch

We were considering supporting something similar in the past but it's not a trivial change, spacially for not Plastic experts where they could end up in scenarios of missing changes/files.

Let me share an example with added files:

- A user adds the "foo.txt" file in the "/main/tas001" branch (he also adds some other files and perform multiple changes in this task branch).
- This user merges "/main/task001" into "/main" but he decides not integrating the changes of the added file: "foo.txt".
- Sometime later, the user decides to merge some new changes this time from "/main" to his task branch: "/main/task001". At this point, the "foo.txt" disappears in his "/main/task001" branch.
- It's not trivial for the user to understand that the reason why the "foo.txt" disappeared after the last merge. And this is because during a previous merge to "/main" the added "foo.txt" change was discarded.

Regards,

Carlos.

[Anton]

4 hours ago, calbzam said:

Hi @Anton, why don't you perform the task branch code review begore running the merge? it's the more natural way to do it in Plastic. This way, you will merging a branch only when it's reviewed, the tests are ok and it's ready to be integrated. If the code review finds some issues that need to be fixed, they can be addressed in the task branch before the merge.

Hi Carlos,

1. If you want to have stable /main you should test AFTER the merge but BEFORE you checkin the merge because merging can introduce some regressions or other errors even if the branch tests pass. 

2. Thank you for your example. But now consider that I am merging "/main/task001" and before checking-in I delete the "foo.txt" this is allowed isn't it? I think so. So it can lead to some misunderstandings later as you describe but this is my decision. So the question is if I can do any changes manually while preparing the merge why you do not want to assist me (I mean allow to Undo specific file changes)?

 

I think this thread leads us nowhere so I guess I should adopt to this behaviour.

[calbzam]

Hi,

Quote

1. If you want to have stable /main you should test AFTER the merge but BEFORE you checkin the merge because merging can introduce some regressions or other errors even if the branch tests pass. 

I agree, but if the problem is the tests are not ok after the merge, what we normally recommend is to rebase/merge from main to the task branch, fix the problem on the task branch and finally merge it back to main. Does it help?

By the way, not sure if you are aware of our mergebots feature for automatize the branch integration: https://www.plasticscm.com/mergebot-devops

Quote

2. Thank you for your example. But now consider that I am merging "/main/task001" and before checking-in I delete the "foo.txt" this is allowed isn't it? I think so. So it can lead to some misunderstandings later as you describe but this is my decision. So the question is if I can do any changes manually while preparing the merge why you do not want to assist me (I mean allow to Undo specific file changes)?

You can manually peform any change after the merge before checkin the changes. But for the Plastic merge tracking, the branch is already integrated. For instance, if you try to merge the same branch again, Plastic will report that there is nothing pending to be merged. 

The problem is if the merge opeartion would allow not to merge some specific revisions. It could end up in situations like the one I previous described.

Long time ago (Plastic 3) the Plastic merge was handled per file (so you were not merging the full changeset but individual file revisions). it was a pain in terms of performance and simplicity for merges involving multiple revisons.

Regards,

Carlos.

[Anton]

56 minutes ago, calbzam said:

By the way, not sure if you are aware of our mergebots feature for automatize the branch integration: https://www.plasticscm.com/mergebot-devops

Thank you.

Quote

You can manually peform any change after the merge before checkin the changes. But for the Plastic merge tracking, the branch is already integrated. For instance, if you try to merge the same branch again, Plastic will report that there is nothing pending to be merged. 

The problem is if the merge opeartion would allow not to merge some specific revisions. It could end up in situations like the one I previous described.

Yes I understand. When I asked about allowing file Undo I talked about reverting file changes within merge changeset. I am not talking about excluding file revision from the merge or something like that. As a user I want a friendly button to cancel file changes quickly to save my time. But of course I can do it with my IDE and some copy-pasting.