Thanks, that clarifies a lot.
I only have two follow-up questions:
In your branch example, how does git determine that C/D have been
rewritten and need to be "replaced" with their current versions
existing upstream? In this scenario I've encountered, the commit hash
and the patch ID of those commits changed because the contents of the
patches had to be modified slightly due to merge conflicts which
occurred when the upstream branch was rebased.
Also, you mentioned "not building off of upstream branches which might
be rewritten". We generally try to avoid this but I don't see any
alternative with the way we do things.
upstream/master <- An always-clean copy of what's fully approved and live
upstreamfeature-A
upstreamfeature-B, etc <- Feature branches designed to organized
long-term new feature work
Individual developers will then create local development branches
based on those feature branches. If three people are responsible for
tasks for feature-A, they'll create development branches for each
task, do their work, and(via github enterprise) submit a pull request
so we can properly review their work, test it, etc.
The problem I have today stems from situations where a feature branch
has been merged with master. If feature-B is merged with master, and
someone rebases feature-A, there may be merge conflicts. If they fix
the conflicts, that may alter the commit history of the feature
branch, which then impacts all branches developers have based on it.
Part of me feels like we should be able to never rebase feature
branches, they should exist outside of new work merged to master.
However, it's much easier to resolve merge conflicts in small doses,
and we're in a much better position to know that we're fully updated
and can catch other problems early.
Is there a better way to do this, so that we never risk rewriting the
"middle tier"?
On Tue, Mar 3, 2015 at 3:40 PM, John Keeping <john@xxxxxxxxxxxxx> wrote:
> On Tue, Mar 03, 2015 at 03:20:48PM -0800, Mike Botsko wrote:
>> Maybe I'm lacking the distinction regarding what I'm being specific about.
>>
>> In both examples, I'm asking it specifically to rebase in changes from
>> the remote "upstream" and a named branch at that location. I'm giving
>> git the same information, it's just interpreting it differently - and
>> I'm not understanding why.
>
> Not quite. If you say:
>
> git rebase $sha1
>
> then you're telling git-rebase to apply the commits $sha1..HEAD onto
> $sha1.
>
> If you say:
>
> git rebase
>
> then it will be re-written as:
>
> git rebase --fork-point @{upstream}
>
> in which case Git will apply more complicated logic so that you can
> recover from the case where @{upstream} has been re-written.
>
> Consider the following scenario:
>
> F branch
> /
> C -- D master@{1}
> /
> A -- B -- C' -- D' -- E master
>
> where C' and D' are rewritten versions of C and D.
>
> In this case, imagine you are at F on "branch", "git rebase master" will
> replace C, D and F onto E because you have explicitly selected to replay
> master..branch onto master.
>
> "git rebase" will apply the fork-point logic and realise that D is a
> previous version of master, so it will only replay F onto E.
>
> In general if you just want to rebase onto your upstream it is simpler
> to just call "git rebase" which will do the right thing; it's also
> shorter to type ;-)
>
>> My local branch would have been created from the
>> upstream/feature-branch, and will eventually be merged back into it.
>> Until I'm ready for that, I regularly rebase the work done on
>> upstream/feature-branch so that my local work is always clean and
>> above anything else.
>
> In this case the problem stems from the fact that
> upstream/feature-branch has been rewritten. Building on top of branches
> that will be rewritten is not advisable unless you have a really good
> reason to do so.
>
>> On Tue, Mar 3, 2015 at 3:15 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> > John Keeping <john@xxxxxxxxxxxxx> writes:
>> >
>> >> git-rebase assumes that if you give an explicit upstream then you want
>> >> precisely what you asked for. From git-rebase(1):
>> >>
>> >> If either <upstream> or --root is given on the command line,
>> >> then the default is `--no-fork-point`, otherwise the default is
>> >> `--fork-point`.
>> >
>> > Correct.
>> >
>> > You ask it to rebase the history without guessing by being explicit;
>> > the command guesses when you are not explicit and being lazy ;-).
--
Mike Botsko
Lead Dev @ Helion3
Ph: 1-(503)-897-0155
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html