Re: cookbook question

[Charles Bailey <charles@hashpling.org>]

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.