cookbook question

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

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.

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

On Thu, Feb 28, 2008 at 06:08:03PM -0500, Kyle Rose wrote:

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.