Re: cookbook question

On Thu, Feb 28, 2008 at 02:00:11PM -0500, Kyle Rose wrote:

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

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.