iceberg: merging branches just at the git level without changing code in the image

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

iceberg: merging branches just at the git level without changing code in the image

Andrei Chis
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.
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.

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?

Cheers,
Andrei



Reply | Threaded
Open this post in threaded view
|

Re: iceberg: merging branches just at the git level without changing code in the image

Ben Coman


On Tue, 5 Feb 2019 at 01:19, Andrei Chis <[hidden email]> wrote:
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.
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.

Another use case for this might be where I recently wanted to resurrect an old PR 
to contribute to Pharo 8 and loading the old code broke the image.  I'd to update the PR
by merging master into it without loading it.  Rebasing the old PR onto master would be even better.

Perhaps the existing <Merge> button becomes a <Merge & Load> button
and the <Merge> button presents a dialog for any any-to-any disc-only merge
(default would be "selected" commit into the image's "current" commit)

cheers -ben
Reply | Threaded
Open this post in threaded view
|

Re: iceberg: merging branches just at the git level without changing code in the image

Guillermo Polito
In reply to this post by Andrei Chis
Hi,

On Mon, Feb 4, 2019 at 6:19 PM Andrei Chis <[hidden email]> wrote:
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 commited
 - a merge, unless fast forward, will need to create a new commit, and potentially if there is a merge conflict it requires some manual intervention

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

Phone: +33 06 52 70 66 13