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

use Perl Log In

Log In

[ Create a new account ]

jdavidb (1361)

jdavidb
  (email not shown publicly)
http://voiceofjohn.blogspot.com/
J. David Blackstone has a Bachelor of Science in Computer Science and Engineering and nine years of experience at a wireless telecommunications company, where he learned Perl and never looked back. J. David has an advantage in that he works really hard, he has a passion for writing good software, and he knows many of the world's best Perl programmers.

Journal of jdavidb (1361)

Thursday April 17, 2008
03:14 PM

Git question

[ #36179 ]

I have a branch named local which is a descendant of master with changes which are local to my machine that I want only in my own working environment, and never anywhere else. I have a branch named work which is a descendant of local and includes not only the local changes which I do not want to commit to our working repository, but also some changes I have worked on and now do want to commit.

I have a branch named stage which is a pristine copy of master. I want to assemble JUST the changes I made in work that I want to commit, lacking the changes I made in local. How do I tell git "merge the differences between local and work into stage; not including any of the changes between master and local"? I know how to use git cherry to get a list of just the commits involved, but I don't know any command that says "Merge just those commits into this branch."

Thanks to anyone for any help you can provide. :)


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Git question 8 Comments More | Login | Reply /

 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]

    • Thanks for the pointer, rafael!

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

    • 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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.