# cookbook question

4 messages from 2008-02-28 to 2008-02-28. Participants: Kyle Rose, Charles Bailey.
Thread: https://gitlist.dev/t/12369

## Kyle Rose, 2008-02-28 19:00

Subject: cookbook question
Message-ID: <47C704BB.2010707@krose.org>
URL: https://gitlist.dev/e/47C704BB.2010707%40krose.org

```
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


```

## Charles Bailey, 2008-02-28 22:58

Subject: Re: cookbook question
Message-ID: <20080228225838.GA31479@hashpling.org>
URL: https://gitlist.dev/e/20080228225838.GA31479%40hashpling.org
In-Reply-To: <47C704BB.2010707@krose.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.

```

## Kyle Rose, 2008-02-28 23:08

Subject: Re: cookbook question
Message-ID: <47C73ED3.6000704@krose.org>
URL: https://gitlist.dev/e/47C73ED3.6000704%40krose.org
In-Reply-To: <20080228225838.GA31479@hashpling.org>

```

> 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


```

## Charles Bailey, 2008-02-28 23:20

Subject: Re: cookbook question
Message-ID: <20080228232031.GB31479@hashpling.org>
URL: https://gitlist.dev/e/20080228232031.GB31479%40hashpling.org
In-Reply-To: <47C73ED3.6000704@krose.org>

```
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.

```