{"thread":{"id":"12369","subject":"cookbook question","startedAt":"2008-02-28T19:00:11Z","lastAt":"2008-02-28T23:20:31Z","messageCount":4,"participants":["Kyle Rose","Charles Bailey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"70291","messageId":"47C704BB.2010707@krose.org","threadId":"12369","inReplyTo":null,"subject":"cookbook question","fromName":"Kyle Rose","fromEmail":"krose@krose.org","sentAt":"2008-02-28T19:00:11Z","receivedAt":"2008-02-28T19:00:11Z","isPatch":false,"sender":{"key":"krose@krose.org","avatar":"https://gravatar.com/avatar/4e79b8d8d1ed762bf6d7c6bb575aa8a8b270948788d0d572f62ab2e90149026c?d=mp&s=160"},"body":"In maintaining a postfix config that differs maybe 10% between two \ndifferent machines, I have a \"common\" branch that has ???? in the fields \nthat differ.  I realized after speaking with one of the git developers a \nfew weeks ago that I really should be using git-rebase to fix up the \nmachine-specific branches when I make a change to the common branch.  \nUnfortunately, the merge history was screwed up enough such that doing\n\ngit rebase -s ours origin/common\n\nreplaced one machine-specific config with the other, which is not what I \nwanted.\n\nIn order to reset things to a state in which git-rebase would be useful, \nI did the following:\n\ngit diff origin/common >/tmp/diff\ngit reset --hard origin/common\npatch -p1 </tmp/diff\ngit commit -a -m 'reintroduce changes'\n\nwhich works fine, but is obviously not the right way to do this.  What \n*is* the right way to accomplish this?  Essentially, I'm trying to reset \nthe rebase point such that git won't rewind earlier when trying to do \nsubsequent rebases.\n\nKyle\n\n"},{"id":"70329","messageId":"20080228225838.GA31479@hashpling.org","threadId":"12369","inReplyTo":"47C704BB.2010707@krose.org","subject":"Re: cookbook question","fromName":"Charles Bailey","fromEmail":"charles@hashpling.org","sentAt":"2008-02-28T22:58:38Z","receivedAt":"2008-02-28T22:58:38Z","isPatch":false,"sender":{"key":"charles@hashpling.org","avatar":"https://avatars.githubusercontent.com/u/1668475?v=4"},"body":"On Thu, Feb 28, 2008 at 02:00:11PM -0500, Kyle Rose wrote:\n> In maintaining a postfix config that differs maybe 10% between two \n> different machines, I have a \"common\" branch that has ???? in the fields \n> that differ.  I realized after speaking with one of the git developers a \n> few weeks ago that I really should be using git-rebase to fix up the \n> machine-specific branches when I make a change to the common branch.  \n> Unfortunately, the merge history was screwed up enough such that doing\n>\n> git rebase -s ours origin/common\n>\n> replaced one machine-specific config with the other, which is not what I \n> wanted.\n>\n> In order to reset things to a state in which git-rebase would be useful, I \n> did the following:\n>\n> git diff origin/common >/tmp/diff\n> git reset --hard origin/common\n> patch -p1 </tmp/diff\n> git commit -a -m 'reintroduce changes'\n>\n> which works fine, but is obviously not the right way to do this.  What *is* \n> the right way to accomplish this?  Essentially, I'm trying to reset the \n> rebase point such that git won't rewind earlier when trying to do \n> subsequent rebases.\n>\n> Kyle\n>\n\nI'm not sure I understand your problem fully. Why do you think you\nneed to rebase?\n\nAs far as I can tell your 4 line script is equivalent to:\ngit reset --soft origin/common\ngit commit -m 'reintroduce changes'\n\nbut I don't understand why you'd want to do this.\n\nI presume that origin/common contains changes to the common part of\nthe config files that you want to apply to both machines. If the two\nmachines' configs were originally branched from origin/common and then\nhad there custom changes made and committed, you should just be able\nto merge subsequent changes from origin/common and not get conflicts\nunless there are genuinely changes to the parts of the configs that\nhave been modified for the individual machines. I don't see a case for\nrebase in your example.\n"},{"id":"70330","messageId":"47C73ED3.6000704@krose.org","threadId":"12369","inReplyTo":"20080228225838.GA31479@hashpling.org","subject":"Re: cookbook question","fromName":"Kyle Rose","fromEmail":"krose@krose.org","sentAt":"2008-02-28T23:08:03Z","receivedAt":"2008-02-28T23:08:03Z","isPatch":false,"sender":{"key":"krose@krose.org","avatar":"https://gravatar.com/avatar/4e79b8d8d1ed762bf6d7c6bb575aa8a8b270948788d0d572f62ab2e90149026c?d=mp&s=160"},"body":"\n> I presume that origin/common contains changes to the common part of\n> the config files that you want to apply to both machines. If the two\n> machines' configs were originally branched from origin/common and then\n> had there custom changes made and committed, you should just be able\n> to merge subsequent changes from origin/common and not get conflicts\n> unless there are genuinely changes to the parts of the configs that\n> have been modified for the individual machines. I don't see a case for\n> rebase in your example.\n>\n>   \nThe rebase just avoids unnecessary merge records.  What I really want is \nmy changes placed on top of whatever the common head is at any one time, \nwhich by design means I would use rebase.  Aside from the cleanliness of \nthe history, I'm not sure there is a real reason to do this.  But I like \nthings clean. ;-)\n\nKyle\n\n"},{"id":"70332","messageId":"20080228232031.GB31479@hashpling.org","threadId":"12369","inReplyTo":"47C73ED3.6000704@krose.org","subject":"Re: cookbook question","fromName":"Charles Bailey","fromEmail":"charles@hashpling.org","sentAt":"2008-02-28T23:20:31Z","receivedAt":"2008-02-28T23:20:31Z","isPatch":false,"sender":{"key":"charles@hashpling.org","avatar":"https://avatars.githubusercontent.com/u/1668475?v=4"},"body":"On Thu, Feb 28, 2008 at 06:08:03PM -0500, Kyle Rose wrote:\n> The rebase just avoids unnecessary merge records.  What I really want is my \n> changes placed on top of whatever the common head is at any one time, which \n> by design means I would use rebase.  Aside from the cleanliness of the \n> history, I'm not sure there is a real reason to do this.  But I like things \n> clean. ;-)\n\nrebase should just reorder the patches in the simple cases, so it\nshould do what you want. Either you've found a bug in rebase or you're\ndoing something unconventional.\n"}]}