* cookbook question
@ 2008-02-28 19:00 Kyle Rose
2008-02-28 22:58 ` Charles Bailey
0 siblings, 1 reply; 4+ messages in thread
From: Kyle Rose @ 2008-02-28 19:00 UTC (permalink / raw)
To: git mailing list
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: cookbook question
2008-02-28 19:00 cookbook question Kyle Rose
@ 2008-02-28 22:58 ` Charles Bailey
2008-02-28 23:08 ` Kyle Rose
0 siblings, 1 reply; 4+ messages in thread
From: Charles Bailey @ 2008-02-28 22:58 UTC (permalink / raw)
To: Kyle Rose; +Cc: git mailing list
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: cookbook question
2008-02-28 22:58 ` Charles Bailey
@ 2008-02-28 23:08 ` Kyle Rose
2008-02-28 23:20 ` Charles Bailey
0 siblings, 1 reply; 4+ messages in thread
From: Kyle Rose @ 2008-02-28 23:08 UTC (permalink / raw)
To: Charles Bailey; +Cc: git mailing list
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: cookbook question
2008-02-28 23:08 ` Kyle Rose
@ 2008-02-28 23:20 ` Charles Bailey
0 siblings, 0 replies; 4+ messages in thread
From: Charles Bailey @ 2008-02-28 23:20 UTC (permalink / raw)
To: Kyle Rose; +Cc: git mailing list
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-02-28 23:21 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-28 19:00 cookbook question Kyle Rose
2008-02-28 22:58 ` Charles Bailey
2008-02-28 23:08 ` Kyle Rose
2008-02-28 23:20 ` Charles Bailey
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).