From: Philip Oakley <philipoakley@iee.org>
Date: Fri, 06 Jan 2017 21:29:03 GMT
Subject: Re: Rebasing a branch with merges
Message-ID: <49C0981FE7D04AE2AC0BBB011FD74B90@PhilipOakley>
In-Reply-To: <CAHd499BREpaHHyN89a1HchyJiQzPpdo3NSfoLLGVONEmX1m19g@mail.gmail.com>

From: "Robert Dailey" <rcdailey.lists@gmail.com>
> Here's the scenario:
>
> I create a topic branch so one other developer and myself can work on
> a feature that takes 2 weeks to complete. During that 2 week period,
> changes are occurring on master that I need in my topic branch. Since
> I have a collaborator on the branch, I opt for merges instead of
> rebase.
>
> Each day I merge from master to the topic branch, which changes code
> I'm actively working in and requires semantic changes (functions
> renamed, moved, etc).
>
> Once I'm ready to merge the topic branch back into master, I have two
> options (bearing in mind the goal is to keep history as clean as
> possible. Furthermore this implies that the constant merging into
> topic from master has made the topic branch look unwieldy and
> difficult to audit):

a broader question zero;
0. Is the merge always clean? Do you always do a preparatory fixup! to 
ensure that the merge will be clean?

Ensuring that the merge will be clean should greatly simplify your decision 
about process.

>
> 1. Do a squash merge, which keeps history clean but we lose context
> for the important bits (the commits representing units of work that
> contribute to the topic itself).
>
> 2. Do a final rebase prior to merging.
>
> #2 doesn't seem to be possible due to patch ordering. For example, if
> I have real commits after merge commits that depend on those changes
> from master being present as a base at that point in time, the rebase
> will cause the patch before it to no longer include those changes from
> master.

How much of the historic fixups to cover changes on master do you want to 
keep visible? i.e. how many fork-points are truly needed (a. by you, b. by 
the project - personal knowledge vs corporate knowledge).?

>
> Is there a mechanism to rebase in this situation to both achieve a
> clean, linear history for the topic branch and allow fast forward
> merging if desired, while still not causing superfluous conflicts due
> to the merges being omitted during the rebase?
>
> Thanks in advance for any advice in this scenario.
>

Have you looked at @dscho's garden-shears scripts that he uses on 
Git-for-Windows as he has to continuously rebase the Windows specific 
patches on top of the progressing Git master? Very similar issues ;-)

https://github.com/git-for-windows/build-extra/blob/master/shears.sh 
https://blogs.msdn.microsoft.com/visualstudioalm/2016/09/03/whats-new-in-git-for-windows-2-10/ 
(#Fun Facts)

--
Philip