Re: Policy on git feature branches
On 02/01/2011 11:11 AM, Andreas Pakulat wrote: On 01.02.11 10:21:01, Sebastian Trüg wrote: Hi list, I have been working on an improvement for Nepomuk via git-svn for a while now and would now like to push it to kde-runtime. If the branch has been created via git-svn you cannot merge it properly. You need to cherry-pick all commits. However, I would prefer to keep the commit history and backport to 4.6. Thus, I thought of pushing my feature branch into the kde-runtime That won't work, as git-svn created different commits for all the history your branch is based on. So git cannot merge your branch into kde-runtimes history. The only options are to either cherry-pick all commits or rebase your feature branch onto kde-runtime as it is now. Then you can merge it. I did cherry-pick them all into a new branch in my local kde-runtime clone. Merging itself should be local, the history of the branch will be preserved anyway (specify --no-ff in case git merge decides to try a fast-forward) even if you don't push the feature branch into the remote repository. So I merge into master and 4.6 locally and then simply push the two, right? Cheers, Sebastian
Re: Policy on git feature branches
On 01.02.11 13:05:49, Sebastian Trüg wrote: On 02/01/2011 11:11 AM, Andreas Pakulat wrote: On 01.02.11 10:21:01, Sebastian Trüg wrote: Hi list, I have been working on an improvement for Nepomuk via git-svn for a while now and would now like to push it to kde-runtime. If the branch has been created via git-svn you cannot merge it properly. You need to cherry-pick all commits. However, I would prefer to keep the commit history and backport to 4.6. Thus, I thought of pushing my feature branch into the kde-runtime That won't work, as git-svn created different commits for all the history your branch is based on. So git cannot merge your branch into kde-runtimes history. The only options are to either cherry-pick all commits or rebase your feature branch onto kde-runtime as it is now. Then you can merge it. I did cherry-pick them all into a new branch in my local kde-runtime clone. Merging itself should be local, the history of the branch will be preserved anyway (specify --no-ff in case git merge decides to try a fast-forward) even if you don't push the feature branch into the remote repository. So I merge into master and 4.6 locally and then simply push the two, right? Yes. Except that I thought 4.6 was staying feature-frozen not only in kdelibs but also kde-runtime and other modules. But then I don't follow that stuff closely, so maybe I'm wrong. Andreas -- You should go home.
Re: Policy on git feature branches
On 02/01/2011 01:21 PM, Andreas Pakulat wrote: On 01.02.11 13:05:49, Sebastian Trüg wrote: On 02/01/2011 11:11 AM, Andreas Pakulat wrote: On 01.02.11 10:21:01, Sebastian Trüg wrote: Hi list, I have been working on an improvement for Nepomuk via git-svn for a while now and would now like to push it to kde-runtime. If the branch has been created via git-svn you cannot merge it properly. You need to cherry-pick all commits. However, I would prefer to keep the commit history and backport to 4.6. Thus, I thought of pushing my feature branch into the kde-runtime That won't work, as git-svn created different commits for all the history your branch is based on. So git cannot merge your branch into kde-runtimes history. The only options are to either cherry-pick all commits or rebase your feature branch onto kde-runtime as it is now. Then you can merge it. I did cherry-pick them all into a new branch in my local kde-runtime clone. Merging itself should be local, the history of the branch will be preserved anyway (specify --no-ff in case git merge decides to try a fast-forward) even if you don't push the feature branch into the remote repository. So I merge into master and 4.6 locally and then simply push the two, right? Yes. Except that I thought 4.6 was staying feature-frozen not only in kdelibs but also kde-runtime and other modules. But then I don't follow that stuff closely, so maybe I'm wrong. It is not really a feature. Just a fix/improvement/whatever which is rather heavy. Cheers, Sebastian
