Hi, On upstream branch I've left the Tizen git history as it was, and I've pushed all upstream commits from version 1.0.1h to 1.0.1j on the top. I did the same for tizen branch + rebase all tizen-specific commit on the top. I've also sent commit with changing version number to the review.
I think it the best solution. BR, Janusz On 2014-10-22 02:19:32, Whiteman, John L wrote: > > > -----Original Message----- > From: Markus Lehtonen [mailto:[email protected]] > Sent: Tuesday, October 21, 2014 4:39 AM > To: Janusz Kozerski > Cc: Whiteman, John L; [email protected] > Subject: Re: [Dev] [openssl] upstream branch update > > Hi, > > On Tue, 2014-10-21 at 10:57 +0200, Janusz Kozerski wrote: > > Hi John, > > > > Do you think that it would be better to keep current history of > > upstream branch and cherry-pick upstream history from version 1.0.1h > > to 1.0.1j (as I did on my > > sandbox) or overwrite whole upstream branch with upstream history > > (force push)? > > Please, at least do not overwrite existing upstream/* tags. > > One way would be just to merge the real upstream git version (v1.0.1j) > into the existing upstream branch. This would not break the git history. > Then, in future you'd only need to git-merge new upstream versions > into the upstream branch. This would preserve the real upstream Git > history (with the same commit ids than in the upstream git) and avoid > cherry-picking. > > You can also consider importing upstream release tarballs as before, > but, with using the --upstream-vcs-tag option that I mentioned in my > previous email. > > [JOHN]: Either one is fine although the first choice is quicker > without the download hassle we are doing now. > > > And second question: Are merges from upstream branch to tizen branch > > OK? Do we want to merge upstream to tizen, or we want to keep linear > > history and cherry-pick commits from upstream to tizen? > > In the current maintenance model version bumps should be done by > rebasing the tizen branch on the desired upstream version. Otherwise > the GBS patch generation will not function as desired (it'll generate > one big diff instead of individual one-per-commit patches). > > [JOHN]: Yes. Keep upstream pristine with our patches in Tizen branch > applied after rebase. > > Thanks, > Markus > > > > On 2014-10-20 19:10:43, Whiteman, John L wrote: > > > Hi Janusz, > > > > > > I'm fine with the second approach. Other upstream packages are > > > already doing it and the history can be useful. > > > > > > Best Regards, > > > > > > John > > > > > > -----Original Message----- > > > From: Janusz Kozerski [mailto:[email protected]] > > > Sent: Monday, October 20, 2014 6:38 AM > > > To: [email protected] > > > Cc: Tomasz Swierczek; Bartlomiej Grzelewski; Whiteman, John L; > > > Demeter, Michael > > > Subject: [openssl] upstream branch update > > > > > > Hi All, > > > > > > I've seen that on platform/upstream/openssl repository on upstream > > > branch, changes are pulled from upstream as a one big blob of code. > > > Wouldn't be better if we pull commits from upstream as they are? > > > We can have full git history instead of these blobs. > > > > > > I've pushed to a review a commit with update to 1.0.1j in existing > > > convenction. > > > https://review.tizen.org/gerrit/#/c/29027/1 > > > > > > I've also prepared a sandbox branch with the same upstream changes > > > (with full git history) rebased on tizen.org upstream branch: > > > https://review.tizen.org/gerrit/gitweb?p=platform%2Fupstream%2Fope > > > ns > > > sl > > > .git; > > > a > > > =sho > > > rtlog;h=refs%2Fheads%2Fsandbox%2Fjkozerski%2Fupstream > > > > > > We should choose one way of moving changes from upstream. > > > We should do the same for tizen branch. > > > > > > BR, > > > Janusz Kozerski > > > > > > > > > > > > _______________________________________________ > > Dev mailing list > > [email protected] > > https://lists.tizen.org/listinfo/dev > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
