Skip to content
← General

I suggest you ...

General

Categories

JUMP TO ANOTHER FORUM

(thinking…)

Possibility to split changesets

Problem:
Sometimes you checkin changes that aren't necessarily corelated. Well, yes they belong to the same fix, but you could easily revert one change without the other.
When people don't have the habbit to checkin every now and then, they need to checkin when they're done. Most of the time, this checkin contains more than one change.

In the unexpected event of a new bug, that was checkedin with these changes, it's hard to revert that one change that's causing the issue.

Suggested solution:
This problem could be solved if there was a way to split existing changesets into new changesets. It would be easy then to substractive merge the one change.

I think it should be possible to select the files and secific changes in a file to split into a new changeset.
The new changeset would have to be placed right between the original one and everything thats roots to it.

People were asking for a solution for this problem for a long time now and this is what I came up with this morning.

It would be a killer feature! Maybe for version 6.1? ;)

9 votes
Vote

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
You have left! (?) (thinking…)
SWSBB shared this idea  ·   ·  Report…  ·  Admin →
How important is this to you?

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • SWSBB commented  ·   ·  Report

    Sorry to keep you waiting.
    I'm not very familiar with git, so maybe you are right with that squash thingie.

    The substractive merge is fine. But it will undo all changes of one changeset.
    If there are to files in the changeset and I only need to undo one, then both will be undone and I have to redo the change I didn't wanted to undo. That is how it works today.

    We can totaly work with that! But I thought it would be nice to have the split option as well.
    This wouldn't only benefit the "partial-undo" but also the "partial cherry-pick".

    I'll also accept "no" as an answer ;) It was just a thought.

  • AdminCodice Software (CEO / Founder, plasticscm) commented  ·   ·  Report

    You are asking for something like git squash, some sort of history rewriting, right?

    Uhm... it is powerful but dangerous. I mean, if you push that branch to other server, you'd be in trouble.

    That being said, it sounds interesting. But we should probably have to rewrite all descendant changesets too, uhm... yes, something like squash is what you want here :-)

    Why doing a subtractive merge wouldn't work for you?

  • SWSBB commented  ·   ·  Report

    Please let me get this clear for you.
    Imagine you checked in File1 and File2 in changeset A.
    Then the smallest unit is changeset A (containing File1 and File2).

    When time passes, other changesets will be created (let’s call them by inheritance AA, AB, AAA)
    As graph
    A - AA - AAA
    - AB

    This is what plastic can do today.
    If you wanted to revert the change in File2 you’d have a problem.

    Now here is what I think of:
    Split up changeset A into A1 and A2. As a unit they’re “the same” as the old changeset A, but now you can merge them separately.
    This is what it looks like:
    (A1 - A2) - AA - AAA
    - AB

    That’s the theory. I’m not aware of your designs and maybe you’re right and it’s not possible.
    But in my mind, it should be ;)

    Changeset A is the same as A1+A2, so there should be no problem.
    You would have to change all references from changeset A to A2 of course.
    And maybe you would have to do some reorganization of other data. But still, possible.

    Anyway, please share this with your team. It would be fantastic to see this feature in the future =)

    We <3 Plastic SCM