On Friday 25 July 2014 08:37:24 Carsten Haitzler wrote: > > Once that is done, merge the commit to refs/heads/master, rebase > > refs/heads/master on upstream or simply reset it to upstream. As the > > maintainer, you have the right to make the choice of what is best for the > > project and how the few changes we have in Gerrit will be re-applied, or > > not. > > there is a catch here - the update involved conflicts. that implies that > there are changes in tizen git that have never been merged upstream. likely > these will be all-out lost unless they are dug into in detail and evaluated > (the conflicts themselves). gerrit didn't seem to provide any way to see > the conflicts themselves (before fixing). the gerrit patch submitted for > review would effectively be what happens next above - conflicts resolved by > just squashing the src to a new upstream copy. so this needs resolving > first i think (what are we about to squash/nuke and should it be kept?)
That's up to the maintainer to decide. Often, the conflicts are caused by two different solutions to the same problem, in which case you can just drop the local one and take upstream's more specialised version. The maintainer also needs to pay attention to two different solutions that do not conflict with each other. Like I said, there are three strategies to deal with this: - merge origin/upstream - rebase on top of origin/upstream - reset --hard origin/upstream The maintainer must know what patches were applied and how relevant they still are. If there are too many patches for the maintainer to know them all, we have a different problem. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
