tags:

views:

75

answers:

5

I started a feature branch B from branch A. Then I made some changes in both. Merging A into B and then B into A results in both heads pointing at the same merged commit (which is what I wanted because changes in A should also affect branch B). Now for a while only A will experience changes.

Is there a way to make B stick to A until I checkout B and make a commit there? I could of course just delete B and recreate it when branching of again, or work with A and merge it into B before branching off again, but that all relies on me remembering my intention...

+2  A: 

No, you can't stick B to A like you described it.
You already list the alternative options. I'd just delete B, that makes sure that you remember that you have to branch again :)

tanascius
+1  A: 

If you again merge A to B, it should jump forward to meet A, and then you simply start committing against B again.

Marcelo Cantos
+1  A: 

You could let B be a patch queue (using something like quilt) on top of A. Then you can work on it at your leisure; each time you want to update to the newest version of A, you pop off your patches, update A, and then fuzz your patches back on again and fix whatever's broken.

Mercurial actually has an in-core extension for doing this easily and keeping the patches under revision control.

I do this all the time, and it works out really well when you're toying with a bunch of ideas that aren't ready for commit.

Is that what you're looking for?

Borealid
sounds like it, thanks, but as tagged I'm using git. Is there something similar?
Tobias Kienzler
Well, you could just use `quilt` on your working directory. When I said `mq` above, that's really what I meant - it's `hg mq`, but the program is called `quilt`. Get it? A bunch of patches?
Borealid
@Borealid: I'll definitely have a look at quilt, so thanks for mentioning it. (In this case it will however be a little overkill)
Tobias Kienzler
+1  A: 

Lets say you have a master branch with you main code line. Then you decide to implement a new foo feature, and create a new branch foo for that. Then you happily commit to foo, developing your feature, and find you there's a bug in your master branch. In this case, the usual git workflow is to checkout master a fix the bug there. Then, when you continue to develop your feature, you checkout foo, and bring it up to date with your master branch using git merge master. Then you have everything in order and there's no need to stick anything anywhere.

(Or, you can forget to update foo and merge the changes when you later merge foo to your master branch.)

che
I know. And then comes the time when you decide feature *foo* is worked out and merged back into *master*, and for a while nothing happens with *foo* until a bugfix but it should be kept up to date with master's state. My question was on how to do that then
Tobias Kienzler
After you have merged *foo* back to master, there's no reason to keep the branch. Your full history including what was developed separately and when it was merged is preserved in the master branch.
che
@che: You're right. Thanks for your answer (Sorry though, I accepted tanscius' one for shortness)
Tobias Kienzler
+2  A: 

I assume B's real name is sufficiently evocative that merely seeing it in the output of git branch or in the display of gitk --all is enough to remind you of the cool new feature you eventually want to add.

Next time you make changes to A and want to make B catch up, check out B and advance it to A's head. You wrote that A and B currently both point to the same commit. Down the road when you've made changes to A, B's history will still contain nothing that isn't already in A's, so this is an easy rebase:

git rebase A B

The previous command checks out B, so when you're ready to continue working on A:

git checkout A
Greg Bacon