threads / discuss / 12369

cookbook question

Subject: cookbook question

## tl;dr

4 messages between Feb 28, 2008 and Feb 28, 2008.

replies: 3people: 2as markdown or json

Kyle Rose· Feb 28, 2008, 19:00 UTC · lore

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· Feb 28, 2008, 22:58 UTC · re: Kyle Rose · lore

Re: cookbook question

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

Show 27 quoted lines

> 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· Feb 28, 2008, 23:08 UTC · re: Charles Bailey · lore

Re: cookbook question

Show 10 quoted 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

Charles Bailey· Feb 28, 2008, 23:20 UTC · re: Kyle Rose · lore

Re: cookbook question

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

Show 5 quoted lines

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