[Pharo-dev] iceberg: merging branches just at the git level without changing code in the image

Guillermo Polito guillermopolito at gmail.com
Tue Feb 5 05:03:12 EST 2019


On Mon, Feb 4, 2019 at 6:19 PM Andrei Chis <chisvasileandrei at gmail.com>

> Hi,
> Currently in Iceberg to merge a branch into another, we need to checkout
> the branch into which we want to merge and then do the merge.

For the moment it is done that way because
 - every commit is first written in disk before moved to the index and then
 - a merge, unless fast forward, will need to create a new commit, and
potentially if there is a merge conflict it requires some manual

Also, we have decided for the moment to follow git's semantics to avoid
MORE terminology/technological mismatch than what we have.
We could implement the merge operation to work on any two arbitrary
branches, but still in case of merge conflict it's not so straight forward.
We have discussed in Esug with some guys, and there would be the
possibility to have automatic merge strategies like:
  - take all incoming
  - take all outgoing

But still there are cases where the user would like a mix of them, and even
do manual modifications.

Checking out a branch also updates the code in the image, which when
> needing to perform automatic releases on a branch can cause issues.

> Is there already a way in Iceberg to switch to a branch (for example
> `release`) and then merge another branch (for example `master`) into it
> without updating any code in the image?
> The use-case is that the user is on the `master` branch and needs to merge
> `master` into `release` without changing any code in the image.

Yes, when you checkout a branch, there is a combobox:

[image: image.png]

You can choose the last option for it.
These are called in iceberg CheckoutStrategies, and though they are so far
only used for checkouts, they could be used for merge toos.

> I found LGitRepository>>#merge:, but it seems not to be used anywhere in
> the image.
> Another way would be to implement something like the method below. This:
>   - calculates what changes need to be merged
>   - always takes what is on the left branch (in this case what is on
> master overrides what is on release)
>   - does not call loadChangesInWorkingCopy: to update the working copy as
> the code is already in the image
>   - refreshes the dirty packages in case there are changes between what is
> on the image and what is on disk
> ```
> IceMerge>>#executeWithAcceptingLeftOnConflictAndWithoutImageUpdate
> | commitToAdvance |
> mergeCommit validateCanMerge.
> self isAlreadyMerged ifTrue: [ ^ self ].
> self calculateChanges.
> self conflictsDo: [ :operation |
> operation selectLeft.
> ].
> commitToAdvance := self updateHead.
>         "Do not update the working copy"
> "repository workingCopy loadChangesInWorkingCopy: self
> changesToWorkingCopyTree."
> repository workingCopy refreshDirtyPackages.
> ^ commitToAdvance
> ```
> Could something like the above solution work? Or are there other issues to
> take into account?

I think something like that would work...
But it would be nice to extract those things to be more reusable?
 - a conflict resolution strategy (with a default "do not solve conflict")
 - a checkout strategy (with a checkout in image strategy).

Anyway you go, I'd write some tests about that, since a broken merge can
lead to super fuzzy behaviour (like losing code...) :)

> Cheers,
> Andrei


Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr

*Web:* *http://guillep.github.io* <http://guillep.github.io>

*Phone: *+33 06 52 70 66 13
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20190205/d862baee/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 75403 bytes
Desc: not available
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20190205/d862baee/attachment.png>

More information about the Pharo-dev mailing list