Skip to contentSkip to conversation

cookbook question

DISCUSSION Kyle Rose 2 participants 4 messages Jun 15, 2016

lore
Share & tools
lore

Kyle Rose

author
#0 lore raw

In maintaining a postfix config that differs maybe 10% between two different machines, I have a "common" branch that has ???? in the fields that differ. I realized after speaking with one of the git developers a few weeks ago that I really should be using git-rebase to fix up the machine-specific branches when I make a change to the common branch. Unfortunately, the merge history was screwed up enough such that doing

git rebase -s ours origin/common

replaced one machine-specific config with the other, which is not what I wanted.

In order to reset things to a state in which git-rebase would be useful, I did the following:

git diff origin/common >/tmp/diff
git reset --hard origin/common
patch -p1 </tmp/diff
git commit -a -m 'reintroduce changes'

which works fine, but is obviously not the right way to do this. What *is* the right way to accomplish this? Essentially, I'm trying to reset the rebase point such that git won't rewind earlier when trying to do subsequent rebases.

Kyle

#1 lore raw
Quoted 20 lines · Kyle Rose

In maintaining a postfix config that differs maybe 10% between two different machines, I have a "common" branch that has ???? in the fields that differ. I realized after speaking with one of the git developers a few weeks ago that I really should be using git-rebase to fix up the machine-specific branches when I make a change to the common branch. Unfortunately, the merge history was screwed up enough such that doing

git rebase -s ours origin/common

replaced one machine-specific config with the other, which is not what I wanted.

In order to reset things to a state in which git-rebase would be useful, I did the following:

git diff origin/common >/tmp/diff
git reset --hard origin/common
patch -p1 </tmp/diff
git commit -a -m 'reintroduce changes'

Quoted 7 lines

which works fine, but is obviously not the right way to do this. What *is* the right way to accomplish this? Essentially, I'm trying to reset the rebase point such that git won't rewind earlier when trying to do subsequent rebases.

Kyle

I'm not sure I understand your problem fully. Why do you think you need to rebase?

As far as I can tell your 4 line script is equivalent to:
git reset --soft origin/common
git commit -m 'reintroduce changes'

but I don't understand why you'd want to do this.

I presume that origin/common contains changes to the common part of the config files that you want to apply to both machines. If the two machines' configs were originally branched from origin/common and then had there custom changes made and committed, you should just be able to merge subsequent changes from origin/common and not get conflicts unless there are genuinely changes to the parts of the configs that have been modified for the individual machines. I don't see a case for rebase in your example.

author
#2 lore raw
Quoted 11 lines

I presume that origin/common contains changes to the common part of the config files that you want to apply to both machines. If the two machines' configs were originally branched from origin/common and then had there custom changes made and committed, you should just be able to merge subsequent changes from origin/common and not get conflicts unless there are genuinely changes to the parts of the configs that have been modified for the individual machines. I don't see a case for rebase in your example.

The rebase just avoids unnecessary merge records. What I really want is my changes placed on top of whatever the common head is at any one time, which by design means I would use rebase. Aside from the cleanliness of the history, I'm not sure there is a real reason to do this. But I like things clean. ;-)

Kyle

#3 lore raw
Quoted 5 lines · Kyle Rose

The rebase just avoids unnecessary merge records. What I really want is my changes placed on top of whatever the common head is at any one time, which by design means I would use rebase. Aside from the cleanliness of the history, I'm not sure there is a real reason to do this. But I like things clean. ;-)

rebase should just reorder the patches in the simple cases, so it should do what you want. Either you've found a bug in rebase or you're doing something unconventional.