2

Problem

When developing experimental code, I sometimes commit changes which lead to a dead end. Then I'd like to rollback to some previous revision, to start over. But I don't know how to do it best.

Example - Problem

Lets say we have the following Structure in branch A: r1 -> r2 -> r3 -> r4 -> r5

Then I recognize, it's a dead end and want to start over from r3.

Example - Approach

It seems to me that the following final repository structure would be ideal, but correct me if I'm wrong:

Branch A:              r1 -> r2 -> r3 -> r4_new -> ...
                                     \
Branch A_dead_end:                    `-> r4 -> r5

Question

What are the best practices to handle thos dead end rollbacks? Please do also correct my wording, since I didn't know what terms to search for. I'm interested in the Solution for Git and SVN.

Waog
  • 7,127
  • 5
  • 25
  • 37
  • Side note: in git, all the arrows point the other way. The branch label points to the latest commit, which points back to each earlier commit, until you reach `r1` which just says "nothing earlier". This is necessary because commits are permanently unchangeable: you create `r2` pointing wherever, but you can never change it after, so you can't make it point to `r3` which does not exist yet. So point `r2` to `r1`, then create `r3` pointing to `r2`, etc. – torek Aug 12 '14 at 08:51
  • Thanks for the info, i didn't know that. Yet I'm not sure about a better way to display it. I want to express it in a unified notation for *all version control systems*. Just leave away the arrow heads? I think that wouldn't be a good idea. – Waog Aug 12 '14 at 10:42

2 Answers2

3

For Git: If you haven't pushed the branch A yet, you can do a:

git checkout -b A_dead_end
git branch -f A r3
git checkout A
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks, this works, but I'm not totally satisfied with this answer. I have different issues with that answer, which I'll explain in further comments, for easier editing. – Waog Aug 12 '14 at 11:19
  • Why do I have to use a *force* flag? I thought this kind of rollback is one of the main reasons to use version control. So why do I need to use such *hack* to accomplish a main purpose of version control? How should my requirement be done instead? – Waog Aug 12 '14 at 11:22
  • 1
    @Waog because you want to reset the branch. This is not a hack, just a way to move master HEAD back. – VonC Aug 12 '14 at 11:23
  • How to accomplish this result, if everything is pushed already? – Waog Aug 12 '14 at 11:23
  • 1
    Then you can, and git push --force, but if other have already cloned your repo, they will have issue. The other way in that case is to use `git revert`, and create a new commit which will cancel r4 and r5: http://stackoverflow.com/a/4992711/6309 – VonC Aug 12 '14 at 11:25
  • Do ``r1``,``r2`` and ``r3`` *belong to* some branch, after using your solution? The visualized graph somehow foreshadows, that the straight line is one branch and the other branch somehow *originates from* the straight branch and only ``r4`` and ``r5`` are belonging to it. IS that just a matter of visualisation, or is that realy how git works? – Waog Aug 12 '14 at 11:42
  • 1
    @Waog yes, r1, r2, r3 remains part of the branch: any commit accessible from master HEAD is part of the master branch. See also http://stackoverflow.com/a/2707110/6309, and, for proper visualization, http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging – VonC Aug 12 '14 at 11:44
  • That means ``r2`` is in both branches now? In ``A`` and in ``A_dead_end``? And there is no *parent-of-relationship* between these two branches? – Waog Aug 12 '14 at 11:48
  • 1
    @Waog yes, r2 is part of both branches, which is normal. No, there is no "parent" of a branch: see the discussion in http://stackoverflow.com/q/3161204/6309. – VonC Aug 12 '14 at 11:51
  • Ah cool, that's helpful. In that case renaming ``A`` to ``A_dead_end`` first and then branch a new ``A`` from it should also work. So one last question, since it gets a little bit off-topic: when I already pushed my branches. Does renaming the branches like described also cause problems on other clients who cloned the repository before? – Waog Aug 12 '14 at 11:58
  • @Waog yes, because they will need to reset their own local branch to the new branch commit they just fetched. – VonC Aug 12 '14 at 12:04
0

For SVN you have at least two ways

  • Reverse merge r4 + r5 (commit as r6 mergeset) and continue work in the same branch
  • Create new branch from BranchA_dead_end@3 and forget original (you can even svn rm it)
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110