use Perl

• rebase (Score:2)

  by rafael (2125)

  Sounds like you want git rebase --onto. See the docs, there's an example: http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html [kernel.org]
  • Re: (Score:2)

    by jdavidb (1361)

    Well, this seems like the right command, and from the documentation this should be working. I'm executing:

    git rebase --onto stage local work

    My understanding is this should select all of the commits that are in work but not in local, and then apply them all to stage. git crunches some numbers or something, even ran garbage collection, seems to do something ... but my "stage" branch is left completely unchanged, as far as I can tell.

    I tried using the -i (interactive) option to git-rebase, and I could

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • Re: (Score:1)

      by Aristotle (5147)

      I haven’t actually tried this, but going by the documentation, it seems like your situation is as in the git-rebase --onto master topicA topicB example in the docs. So if I understand correctly, your stage branch would indeed remain untouched – however, after rebasing, the work branch would be rooted on stage instead of local.

      To verify, switch to work and check the log.
      • Re: (Score:2)

        by jdavidb (1361)

        This is great! This is now accomplishing just what I want, although not in the way I expected. Instead of saying "Take the changes between branch A and branch B, and apply them to transform branch C," I can say "Pluck branch B off from its root at branch A and reattach it to new direct ancestor D, eliminating any of the changes between D and A." Works. :)

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
        • Re:rebase (Score:1)

          by Aristotle (5147) <pagaltzis@gmx.de> on 2008.04.18 13:16 (#62283) Homepage Journal

          This is now accomplishing just what I want, although not in the way I expected.

          And that is probably why at first you misunderstood it. :-) It happens to me too when I approach something with a strong preconception of what I want to happen when it actually does something different to achieve the same ultimate goal.

          Still a little scared.

          Yeah – git’s hundreds of yards of rope for rewriting history can be scary. :-)

          “Pluck branch B off from its root at branch A […]”

          Note that it needn’t even be a formal branch. You can use any two commits where one is an ancestor of the other. That’s the git rebase --onto topicA~5 topicA~3 topicA example in the docs: it says “take the stretch from after topicA~3 (the fourth last commit on topicA) to topicA (the last commit on topicA) and root it onto topicA~5 (the sixth last commit on topicA).” What happens is that the fifth and fourth last commit of topicA become a nameless orphan branch rooted on what was topicA~5, and the three last commits of topicA are also rooted on that commit, so the ancestry of topicA no longer includes the orphan branch.

          Note that you can reverse this command if you know the SHA1 of that fourth last commit. You can say something like gitk --all `git-fsck | ack --output='$1' '^dangling commit (\w*)'` to browse all the orphan branches in your repo (as long as you don’t GC them). (The first time you do this you will also discover that every time you rewrite history, even if it is just by amending a commit, you leave behind such orphan branches.) Once you have the SHA1 ID of the commit in question, you can say git rebase --onto $SHA1 topicA~3 topicA, which will root the same stretch of four commits from the previous example back onto that commit.

          Reply to This

          Parent

          • Re: (Score:2)

            by jdavidb (1361)

            Note that it needn’t even be a formal branch. You can use any two commits where one is an ancestor of the other.

            Gah! Stop; I'm not sure a mere mortal should be trusted with such power! :)

            Note that you can reverse this command if you know the SHA1 of that fourth last commit.

            I feel a probably unjustified sense of pride at knowing that.

            Actually the design of git's internals has fascinated me so much that I've even dreamed about it in the last couple of weeks.

            --
            J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers