Kike

A post for context on problems caused by these ligatures (I could not find it this morning): https://practicaltypography.com/ligatures-in-programming-fonts-hell-no.html As a user of some weird text and localization libraries heavy on UTF-8 filtering, I don't like the chances of confusing code syntax with Unicode characters.

Thanks for the tip. At least it's reversible. Still, having that as default is not a good idea. Few programmers know that font feature (ligature characters), and even less like it, having sampled some time ago among my peers.

On November I opened an issue with the Plastic team regarding this. I provided a couple of reproduction paths, and explained the problems they caused (for our team, in particular). The problems are empty changesets in the xlinked repo, and updated xlink changeset ids when merging unrelated changes into main turning things into a spiraling chaos of empty merges and incremented changeset values. I was told the issue has been communicated to the development team, I was asked for some more info, and things should be moving along. I don't know what the final solution will be, or whether there will be one at all, but I'll try to remember posting here any updates I get. For completeness sake, I'll say that this matching of changesets between xlink and the parent repo was considered a feature, as the Plastic team thought keeping a clear history matching both repos to be important. However, that's because they see xlinks as a way to develop sub-features of a complete system. For me, however, xlinks are a way to maintain common libraries between different projects, and for that use case, matching the histories of different projects 1-to-1 in the library repository makes no sense. The library history is unreadable, as it gets cluttered over time with meaningless empty changesets [edit: or changesets and branches that are irrelevant for the library history].

In case having extra votes behind a feature request helps, I also liked having the last view pane I used remembered. In my case, I usually leave the Pending changes section open to check any TODOs I left in the code to help me getting up to speed.

Hi In the new GUI version, I've noticed that Plastic has started displaying != as a unified character (=/=) by default. That's pretty confusing for a program focused on telling people what changed in a text file. Doing character replacements like that can mislead users or obscure weird problems (what if a program actually inserted that symbol as a special Unicode character?). In my opinion, text should be displayed as is in the file, char per char. If a user wanted to do this, it should be a preference, but certainly not a default behaviour. Can this be reversed? If it cannot, can it be toggled off somewhere?

In our project, one user merged by mistake a task branch (br1) into an unrelated one (br2). When they noticed the mistake, they performed a subtractive merge from the undesired merge changeset (br1 -> br2), which resulted in a changeset (!br1 -> br2) full of br1 files deletions and additions. They kept working as usual, until recently we noticed a lot of files for a specific level are missing on main. After investigating the history, we've seen the following sequence: br1 -> main: files added in br1 are now in main br2 -> main: many of the files added from br1 are deleted from main, some files that were deleted in br1 reappear in main It looks like the br2 -> main merge took the changes from the subtractive changeset and applied them. This is not the desired nor expected behaviour we want from a subtractive merge. The fact that a link is created lead us to believe that it meant "all operations should ignore the changeset this is coming from". But it is, however, a complete changeset in itself, leading to our issue. Is there any way to prevent this from happening? What's the alternative to subtractive merges, given that deleting non-head changesets is cumbersome and we cannot select several files from a changeset and say "revert to this/previous version" in bulk? Are there plans to fix this behaviour of subtractive merge? We'll try to figure out a way to recover the files deleted and remove the ones added unintentionally. And, from now on and until subtractive changesets behaviour changes, we'll forbid anyone from using them.