Hi Chao,
I am running "gitk --all" on fedora kexec-tools tree. I kind of expected that master branch runs first and then rest of the branches fork off that. Something like as follows.
-------------------------------------------------------> master | | | |--->f18 |----->f19 |---->f20
In my gitk view f20 seems to be on top and it looks as if master has been forked off the main trunk. I am not sure if this is gitk behavior and it is possible that it can show branches anyway, or it has something to do with we fork off branches.
Anyway, this is not something very important. I noticed something and thought of bringing it to your notice.
Thanks Vivek
On 02/10/14 at 04:47pm, Vivek Goyal wrote:
Hi Chao,
Hi, Vivek
Sorry for late response.
I am running "gitk --all" on fedora kexec-tools tree. I kind of expected that master branch runs first and then rest of the branches fork off that. Something like as follows.
-------------------------------------------------------> master | | | |--->f18 |----->f19 |---->f20
In my gitk view f20 seems to be on top and it looks as if master has been forked off the main trunk. I am not sure if this is gitk behavior and it is possible that it can show branches anyway, or it has something to do with we fork off branches.
I don't think we fork off any branches these days. When I took over kexec-tools maintainer's job, other branch (like f19) can't simply merge master branch due to some kind of conflict. I don't know why this happens. But it seems there's nothing I can do, because these are already in the git server.
So I'm told that I can use git cherry-pick. The workflow is like first I apply the patches in master branch and after that I cherry-pick these commits to other branches (f20, f19). Then I push the changes and release an update.
I think that's why these branches are messed up. What do you think?
Anyway, this is not something very important. I noticed something and thought of bringing it to your notice.
Thanks for bringing it up. I never thought of that before. I think it's interesting.
Thanks WANG Chao
On 02/14/14 at 03:22pm, WANG Chao wrote:
On 02/10/14 at 04:47pm, Vivek Goyal wrote:
Hi Chao,
Hi, Vivek
Sorry for late response.
I am running "gitk --all" on fedora kexec-tools tree. I kind of expected that master branch runs first and then rest of the branches fork off that. Something like as follows.
-------------------------------------------------------> master | | | |--->f18 |----->f19 |---->f20
In my gitk view f20 seems to be on top and it looks as if master has been forked off the main trunk. I am not sure if this is gitk behavior and it is possible that it can show branches anyway, or it has something to do with we fork off branches.
I don't think we fork off any branches these days. When I took over kexec-tools maintainer's job, other branch (like f19) can't simply merge master branch due to some kind of conflict. I don't know why this happens. But it seems there's nothing I can do, because these are already in the git server.
So I'm told that I can use git cherry-pick. The workflow is like first I apply the patches in master branch and after that I cherry-pick these commits to other branches (f20, f19). Then I push the changes and release an update.
I think that's why these branches are messed up. What do you think?
Hi Chao,
That git cherry-pick is just my preference. When I maintained, Dave had been using 'git merge'. However after one time of wrong operation, 'git merge' will produce a merge info commit, I don't like it, so I began to use git cherry-pick. I am not sure whether the git cherry-pick will impact the branch fork, but it's for sure these branchs are forked not by us, should be fedora admin.
When you take over, I just told how to make release and my experience, it's not a rule, just my habits and preference. But it's your decision to operate now. Maybe there's any other better methods, then it's can be used for rhel5/6/7 too.
Baoquan Thanks
Anyway, this is not something very important. I noticed something and thought of bringing it to your notice.
Thanks for bringing it up. I never thought of that before. I think it's interesting.
Thanks WANG Chao _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On Mon, Feb 17, 2014 at 12:49:28PM +0800, Baoquan He wrote:
On 02/14/14 at 03:22pm, WANG Chao wrote:
On 02/10/14 at 04:47pm, Vivek Goyal wrote:
Hi Chao,
Hi, Vivek
Sorry for late response.
I am running "gitk --all" on fedora kexec-tools tree. I kind of expected that master branch runs first and then rest of the branches fork off that. Something like as follows.
-------------------------------------------------------> master | | | |--->f18 |----->f19 |---->f20
In my gitk view f20 seems to be on top and it looks as if master has been forked off the main trunk. I am not sure if this is gitk behavior and it is possible that it can show branches anyway, or it has something to do with we fork off branches.
I don't think we fork off any branches these days. When I took over kexec-tools maintainer's job, other branch (like f19) can't simply merge master branch due to some kind of conflict. I don't know why this happens. But it seems there's nothing I can do, because these are already in the git server.
So I'm told that I can use git cherry-pick. The workflow is like first I apply the patches in master branch and after that I cherry-pick these commits to other branches (f20, f19). Then I push the changes and release an update.
I think that's why these branches are messed up. What do you think?
Hi Chao,
That git cherry-pick is just my preference. When I maintained, Dave had been using 'git merge'. However after one time of wrong operation, 'git merge' will produce a merge info commit, I don't like it, so I began to use git cherry-pick. I am not sure whether the git cherry-pick will impact the branch fork, but it's for sure these branchs are forked not by us, should be fedora admin.
I think "git merge" is not the right way to handle it.
I like the cherry picking process better. We commit the patch on master branch and then cherry pick patches from master branch to apply on f20 or any other branch as needed.
Git merge works only if we are creating a temporary development branch and then pull in all the changes into master.
Thanks Vivek
-
Baoquan He -
Vivek Goyal -
WANG Chao