Skip to content

Settings and activity

7 results found

  1. 170 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Gerard Murphy commented  · 

    Now that plugin is fairly well tested, so I expect the 164 other voters (at time of writing) to get busy downloading. :-) https://github.com/sageserpent-open/SemanticMergeScalaPlugin

    An error occurred while saving the comment
    Gerard Murphy commented  · 
    Gerard Murphy supported this idea  · 
    An error occurred while saving the comment
    Gerard Murphy commented  · 

    OK, I've produced an almost completely untested alpha plugin over at: https://github.com/sageserpent-open/SemanticMergeScalaPlugin . So if you're really keen to get Scala support in, how about pulling this project and filling out the missing pieces / doing some integration testing?

  2. 6 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  General  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Gerard Murphy commented  · 

    The crucial point I'm making is simply that if I see a line (or section) of code in an annotated file, I'd like to jump straight to the annotated revision where that line (or section) of code was last changed. What's more, if the change turns out to be irrelevant to whatever I'm looking for, I'd like to be able to repeat this process, jumping back to the previous change for the same line and so on...

    Tracking code motion is a very nice bonus on top of this feature request.

    An error occurred while saving the comment
    Gerard Murphy commented  · 

    That might work if I was using C# in Visual Studio - but I am using Scala in IntelliJ using the plugin and the Plastic GUI in standalone mode.

    I'm looking for something that is available in the Plastic GUI. Also, my focus tends to be on lines of code rather than entire methods, so picking up all the history for a given method would result in a lot of noise - but the idea of using Semantic Merge to track the code motion of a line of code via its enclosing method would definitely help.

    An error occurred while saving the comment
    Gerard Murphy commented  · 

    As a note, it is currently possible to manually note down the changeset from the annotations view, jump to that changeset and re-annotate - but this is fiddly!

    Gerard Murphy shared this idea  · 
  3. 93 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  General  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Gerard Murphy commented  · 

    I've found another other feature request in User Voice: Support merging across files

    This was raised after this one - and I think it would address the use-case better. I'm taking my 3 votes off this feature and putting them on the other.

    An error occurred while saving the comment
    Gerard Murphy commented  · 

    I've voted for this too: some things to bear in mind:-

    1. Let's say the file 'foo.cs' is split via copying by somebody else on a separate branch - so I still see just 'foo.cs' on my branch. If I make commit modifications to it, then if the other person merges in my branch changes, they should get the opportunity to 'multi-merge' my changes made on 'foo.cs' into their 'foo.cs', foo2.cs', 'foo3.cs'.

    2. This is a generalization of the idea of merging through file moves.

    3. There should be some way of merging a split committed by somebody else into my own workspace with local uncommitted changes, similar to #1.

    4. Mercurial also has this functionality. It allows a 'one-off' merge into each copy - once the merge is done though, subsequent changes to the original file are not merged in during later branch merges.

  4. 3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  General  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Gerard Murphy shared this idea  · 
  5. 87 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    12 comments  ·  General  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Gerard Murphy supported this idea  · 
  6. 44 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  Git bisync  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Gerard Murphy supported this idea  · 
  7. 175 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    20 comments  ·  General  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Gerard Murphy commented  · 

    I see the need for this quite a lot at client sites were I work - many developers are afraid to merge changes and will E-mail copies of files to transmit changes between branches being worked on by different people. They then commit the copied file in a new branch as an evil-twin. So when I get round to merging, I inherit lots of evil twin conflicts.

    Mercurial allows evil twins to be merged: it effectively performs three-way merge using an empty file as a common base. As there are merge tools that can identify commonality between the two independent sets of changes (and therefore automatically merge them, as they are the result of the original copy via E-mail), this turns out to be quite an effective way of merging in practice.

    Gerard Murphy supported this idea  ·