Re: Rebasing a branch with merges

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jan 6, 2017 at 3:28 PM, Philip Oakley <philipoakley@xxxxxxx> wrote:
> From: "Robert Dailey" <rcdailey.lists@xxxxxxxxx>
>>
>> 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.

I don't understand what you're asking. How would I do a fixup with
merges? Can you explain a bit? Normally the only time I use fixup! or
squash! is for local changes prior to pushing.

>> 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).?


Again, I do not understand. Maybe the first question you asked needs
to be understood before I can answer this one. Sorry for the trouble.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]