Hi, On Mon, Feb 4, 2019 at 6:19 PM Andrei Chis <chisvasileand...@gmail.com> 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: 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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
