531 results found

1. Check out from "Checkin changes" tab (Gluon)

   If you have a file in your Checkin changes tab that is Changed but not checked out, you currently have to switch to the Explore workspace tab and navigate to the file, then check it out.

   I would like to be able to bring up the context menu for the file under the Checkin changes tab and choose Check out.

   3 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   2 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. [gmaster] Support for git-worktree

   Would be great if Gmaster would support git-worktree
   It could be solved in similar way as in PlasticSCM - creation of different workspaces for same repository

   3 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Pending changes checkboxes need to be half filled if you haven't selected every child item

   •  

   3 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Revert a changeset option in context menu

   In Git UI I used to be able to do a simple task of reverting a selected commit locally. I saw an option to delete a changeset in Plastic, but sometimes you don't have a permission but you need to revert all the changes without opening any Diff windows and selecting any individual files.

   3 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   2 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Open file in file system

   When I view file changes in the Compare Revisions window, I often want to know the current state of the file or change it. Add an option to locate the file in local workspace if it exists locally. It's not the same as current option to open that revision in a temp. directory.

   3 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   2 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Default ignore settings for Unity projects

   When starting a new project, allow the user to indicate that it is a Unity project, and enact default ignore file settings based on best practices. Allow the user to see which files will be ignored, and override them.

   3 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. Add an option to not merge formatting automatically

   I could not find an option to merge files manually when source has formatting and whitespace changes. These changes are lost after an auto-merge.

   3 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. Improve merge changes context menu descriptions

   It would be nice if the context menu descriptions when resolving a merge conflict would be more informative.

   I'm referring to "Merge keeping source changes" and "Merge keeping workspace changes". The user has to know exactly which one is which, making this very error-prone.

   I suggest using "mine" and "theirs", as is common in other tools, or if possible, the name of the branch of each version.

   So "Merge keeping changes from 'main'" and "Merge keeping changes from 'main/fix-163'" would be much more informative.

   •  

   3 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

9. Maintain/Display the change comments for Rename function

   Hi,
   We've recently had to rename a bunch of our files, and we were applying comments at check-in (because it was required), but have noticed that after the Check-In, the History will show the Move action, but no longer display the comment attached.

   This would have been useful for us, as the comments kept track of some important information around why the renaming was happening, but this info is either lost/not displayed.

   Cheers.

   3 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

10. 1D history

    I often need to look up the history of a file, but I only care about its changes on the /main branch. From the regular history view, when the file got changed on a branch, it is unclear whether that branch made it back to /main or not. The current history view is fairly pointless because there is no way to tell which changes are relevant and which ones have been abandoned.

    The 2D history view on the other hand is way too cluttered and cumbersome to navigate for any non-trivial project. Especially as it includes changesets where the file was merge from /main to another branch, which is exactly the opposite of what I want to know.

    What I really want is a way to filter the regular history view to a single branch, but show all changeset affecting the file, including merges. The table format is good, I just need a way to filter out all the irrelevant changes that never made it back to /main.

    I often need to look up the history of a file, but I only care about its changes on the /main branch. From the regular history view, when the file got changed on a branch, it is unclear whether that branch made it back to /main or not. The current history view is fairly pointless because there is no way to tell which changes are relevant and which ones have been abandoned.

    The 2D history view on the other hand is way too cluttered and cumbersome to navigate for any non-trivial project. Especially as it includes changesets where the file… more

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    1 comment  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

11. Add C++17 support to SemanticMerge

    SemanticMerge doesn't understand e.g. nested namespace definitions, which means it can't semantically merge C++17 files.

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

12. One button switch to changeset

    I often find myself needing to restore workspaces to the exact state of some changeset. I don't care about the branch or changeset I'm currently on. I don't care about pending changes, added files, deleted files, private files. All I want is for my workspace to be 100% identical to the changeset I'm switching to. Right now, both in the GUI and CLI, doing so involves multiple potentially long running steps which may or may not require user interaction.
    Please give me the nuclear option to get my workspace into pristine state again!

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    2 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

13. Allow "Move Changeset" to move to regular branches

    Currently, with "Move Changeset" I can only move to a new branch or an empty one.

    But often I find myself quickly fixing a small bug or tweak a value, and switching to a different branch is something I don't think about at that moment. But the changeset does not belong on the branch that I committed it to.

    It would save an incredible amount of time if "Move Changeset" would do the following, when selecting a non empty branch:
    - Cherry Pick the full changeset from the target branch, including the comment
    - Delete the changeset in question

    Now I understand that deleting a changeset anywhere on a branch creates a sort of "Tower of Hanoi" challenge, of having to shelve all the commits on top of it, delete the changeset in question, and stack them back on. For now it would already be useful if I could do this with the latest changeset (no further dependencies).
    But being able to delete changesets with dependencies (instead of messy reverse commits) would be very useful in it's own right.

    Currently, with "Move Changeset" I can only move to a new branch or an empty one.

    But often I find myself quickly fixing a small bug or tweak a value, and switching to a different branch is something I don't think about at that moment. But the changeset does not belong on the branch that I committed it to.

    It would save an incredible amount of time if "Move Changeset" would do the following, when selecting a non empty branch:
    - Cherry Pick the full changeset from the target branch, including the comment
    - Delete the changeset in question

    Now… more

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    2 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

14. "Hidden changes" should not cause an error dialog when used properly

    Some configuration files & libraries etc. can need to be present, but customized/recompiled per-developer.

    We want to commit them to the repository (as they DO need to be present in at least a "default" state), but then once downloaded, we want developers to not have to worry about committing them ever. This feels like a very reasonable and common use case, and one for which "hidden_changes.conf" is made for.

    However, when we switch branches/changelist (which is very often!), we get the following error-looking dialog for any files we are locally changing but that ARE in "hidden_changes.conf" (see image).

    Ideally, if a file is in "hidden_changes" it wouldn't cause such an error and not put up any dialog. (e.g. I know it's a different use case but files that are cloaked don't put up a dialog) If there are any concerns about communication at the very least it should be a more friendly dialog such as "the following files are marked as HIDDEN CHANGES and have been changed and will NOT be updated to the new change list".

    Some configuration files & libraries etc. can need to be present, but customized/recompiled per-developer.

    We want to commit them to the repository (as they DO need to be present in at least a "default" state), but then once downloaded, we want developers to not have to worry about committing them ever. This feels like a very reasonable and common use case, and one for which "hidden_changes.conf" is made for.

    However, when we switch branches/changelist (which is very often!), we get the following error-looking dialog for any files we are locally changing but that ARE in "hidden_changes.conf" (see image).

    Ideally, if… more

    •  

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

15. Distribute the .NET Core server for Linux ARM

    It would be neat if you distributed you .NET Core server for ARM Linux so we can easily install it in embedded hardware such as a Raspberry Pi.

    Extra points for a package to install from apt / yum / zypper and so on!

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

16. Add Mac support for UE4 plugin

    Currently the plugin (https://github.com/SRombauts/UE4PlasticPlugin) is only working with windows, it would add value to your service if you could get it to support Mac as well.

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

17. Branch name in properties

    I'd like to see the branch name in the side panel > Properties view as well.

    •  

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

18. code review

    Code Reviews: when responding to a code review, rather than copying and pasting a magic UID into the changelist comment, it would be preferable to be able to browse and select an already submitted changelist that closes a particular comment in a code review.

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

19. Embedded Custom Diff

    When it comes to text files, the embedded diff viewer is extremely helpful, allowing me to quickly click between files and see what changed. While it is possible to specify external tools for diffing non-text files, it is currently not possible to do so with the same ease of use or convenience. Embedded Diff and Custom Diff are currently mutually exclusive.

    This request is to add an extensibility mechanism for the embedded diff viewer. I am thinking of this similarly to Windows' IFilter mechanism that allows custom preview renderers to be specified for any file type.

    For example, if I wanted to diff a custom binary serialization that my company uses, I could write a program that converts it to text. Perhaps the program outputs the text to std-out, perhaps to a temp file - either way, Plastic would take that output and feed it into the standard text diffing feature. Similarly, it would make sense to provide the same functionality for images. In order to see diffs for 3MF files, I would specify a program that converts 3MF to BMP.

    When it comes to text files, the embedded diff viewer is extremely helpful, allowing me to quickly click between files and see what changed. While it is possible to specify external tools for diffing non-text files, it is currently not possible to do so with the same ease of use or convenience. Embedded Diff and Custom Diff are currently mutually exclusive.

    This request is to add an extensibility mechanism for the embedded diff viewer. I am thinking of this similarly to Windows' IFilter mechanism that allows custom preview renderers to be specified for any file type.

    For example, if I… more

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

20. Don't create empty commits in xlink upon merge-to

    If I complete these steps:
    1. Create repos B and A
    2. Commit file foo to repo B (this becomes cs1)
    3. Create xlink /b in repo A as -> cs1@/main@B (writable)
    4. Create branch /main/task001@A
    5. Checkin several files without touching /b

    I can then complete my task branch like this:
    6. Switch workspace to /main@A
    7. Merge from /main/task001

    After this, B will still have only one branch and one changeset, because no changes were made inside of /b. Wonderful!

    Alternately, I can complete my task branch like this:
    6. Merge-To from /main/task001 into /main@A

    This is a better process. It has fewer steps. In fact, it is recommended by the Plastic Book. Unfortunately, while it should behave exactly the same, there's a small difference: This process has just created a new changeset #2 on repo B that is a merge from cs1 and contains nothing.

    This empty commit is dangerous, because Plastic doesn't support making empty changesets and therefore doesn't account for them in many of its behaviors. Just today, I had done the following:

    1. merge-to from /main/task123 to /main (xlink gets cs:N+1)
    2. merge from /main to /internal (this didn't change the xlink, it still points to cs:N, which is probably a bug)
    3. Modify contents of xlink
    4. Attempt to commit

    The result is that Plastic sees we are on cs:N but cs:N+1 exists, so it stops the commit and demands that N+1 is merged into N first. However, because N+1 contains no changes, the merge cannot take place. The checkin is impossible until I shelve the changes, change the xlink to point to N+1, reapply the changes, and try to commit again.

    It is also a problem that if you merge-to /main into /task003, for example, you will also get an empty changeset on a newly created /task003@B, which clutters the B repo. That's particularly bad if B is sync'd to a public Git repo.

    If I complete these steps:
    1. Create repos B and A
    2. Commit file foo to repo B (this becomes cs1)
    3. Create xlink /b in repo A as -> cs1@/main@B (writable)
    4. Create branch /main/task001@A
    5. Checkin several files without touching /b

    I can then complete my task branch like this:
    6. Switch workspace to /main@A
    7. Merge from /main/task001

    After this, B will still have only one branch and one changeset, because no changes were made inside of /b. Wonderful!

    Alternately, I can complete my task branch like this:
    6. Merge-To from /main/task001 into /main@A

    This is a… more

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close