3

Say I have local branch A off of origin/master. I am continuously making changes to branch A, fetching the remote master, and rebasing.

Then I have local branch B off of A. I am continuously making changes to branch B and rebasing.

I am the only one working on branches A and B.

Is this a bad setup since A's commit IDs (hashes) may be changing frequently? Does that destabilize branch B in any way or make conflicts more likely?

In fact, how does Git even implement this setup? What is B's HEAD if A's commit IDs keep changing out from under it?

Aaron
  • 619
  • 6
  • 15

2 Answers2

4

If you are in this type of cycle (fetch/rebase) and see the same conflicts over and over, you could activate the git rerere feature.
That will avoid having to do the same conflict resolution for each of your rebase.

See also "Are there any downsides to enabling git rerere?", "Fun with rerere" and "Rerere Your Boat..." for more.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

This could cause conflicts to continue to cause conflicts every time.

Don't rebase B off A unless topic B depends on topic A.

Otherwise, avoid causing conflicts between A and B.

The git implementation is that commits on B will depend on commits on the old A branch until you rebase.

Basically, when you rebase, git doesn't delete the old commits, it just creates new commits by rebasing, and sets the branch A head pointer to the new final commit.

A branch is just a pointer to a commit.

ronalchn
  • 12,225
  • 10
  • 51
  • 61
  • Topic B does depend on topic A. – Aaron Aug 19 '12 at 01:45
  • Then avoid causing conflicts between A and B. You can stop removing the function for now (if it's just an uncalled function it might not matter), or remove the function in A (only if possible) instead of B. Or you can stop rebasing B onto A until the very end when the feature is complete. – ronalchn Aug 19 '12 at 02:01