From: Eric Sunshine <sunshine@sunshineco.com>
To: Seb <spluque@gmail.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: interactive rebase results across shared histories
Date: Sun, 21 Feb 2016 14:08:44 -0500 [thread overview]
Message-ID: <CAPig+cSxmWc_Guab0UoQbRMEkVLr-qhF=LCiVk10G5AdnTqnGA@mail.gmail.com> (raw)
In-Reply-To: <8737sm6kmk.fsf@gmail.com>
On Sun, Feb 21, 2016 at 12:25 PM, Seb <spluque@gmail.com> wrote:
> The scenario is much simpler; imagine master has a longer history behind
> the point where the topic branch started:
>
> A---B---C topic
> /
> *---D---E---F---G master
>
> And we want to keep both branches separate (no desire to merge them for
> now), but we realize that, say, commits D and E should be
> squashed/fixup, so we do an interactive rebase. Now, the problem is
> that if I do that from the topic branch, the results are not reflected
> in the master branch, even though these commits are certainly shared
> with master. It seems counterintuitive that a part of history that is
> shared among branches can be independently manipulated/rewritten with
> rebase. I must be missing something...
What you're probably missing is that you can't actually edit commits
in Git. Instead, what you think of as "editing" actually creates a new
commit with its own commit-ID, and the original commit still exists
with its own commit-ID. Since Git commits are chained together by
their commit-ID's, any commits pointing at the original commit-ID
continue to point to that commit, and only commits rebased atop the
new commit-ID of the "edited" commit point at it.
In your example, you're "editing" D and E, which creates new commits
D' and E', so your resulting graph looks like this:
D'---E'---A---B---C topic
/
*---D---E---F---G master
So, "master" and "topic" really are not sharing D and E (or D' and
E'). You could "fix" this to match your intuition by rebasing F...G
onto E' (see git-rebase --onto, for instance), which would give you
this:
A---B---C topic
/
*---D'---E'---F---G master
and then "master" and "topic" would really be sharing D' and E' as
common history. (Of course, rebasing "master" or any branch may not be
desirable if you've published it, so applicable warnings about
rebasing apply.)
By the way, the problem isn't restricted to when you rebase "topic"
(as your problem description implies). You'd see the same behavior if
you'd rebased D and E in "master" to become D' and E'. "topic" would
still have old D and E in its history, and not D' and E'.
next prev parent reply other threads:[~2016-02-21 19:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-20 22:58 interactive rebase results across shared histories Seb
2016-02-21 2:12 ` Moritz Neeb
2016-02-21 17:25 ` Seb
2016-02-21 19:08 ` Eric Sunshine [this message]
2016-02-22 3:32 ` Seb
2016-02-22 7:41 ` David
2016-02-23 17:39 ` Seb
2016-02-23 22:57 ` Moritz Neeb
2016-02-23 23:04 ` Kevin Daudt
2016-02-23 23:05 ` Seb
2016-02-26 12:38 ` David
2016-02-26 21:12 ` Seb
2016-02-26 22:56 ` Stepan Kasal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPig+cSxmWc_Guab0UoQbRMEkVLr-qhF=LCiVk10G5AdnTqnGA@mail.gmail.com' \
--to=sunshine@sunshineco.com \
--cc=git@vger.kernel.org \
--cc=spluque@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 NNTP newsgroup(s).