Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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]
    • 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
      • 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.

        • Hey, you're correct! That's what it did!

          I'm still not sure how I was misunderstanding the docs. But, I think I can use this. I can completely drop the concept of the stage branch, I think, and just rebase work branches to master when I am ready to commit them.

          I think. Still a little scared. And I'm even more scared that the next thought I had was, "At least I still have CVS to tell me what's changed or not; that should make me feel secure." Seriously. And then I thought, "Yeah, right."

          --
          J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
        • 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
          • 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 […]”

            No

            • 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