Re: [leaf-devel] start with branch renaming/moving
Le 6 janv. 2014 à 19:09, KP Kirchdörfer kap...@users.sourceforge.net a écrit : Locally I do have maint-4.x, how to proceed? btw: how can we fix the wrong rename/move of maint to maint-4.x? Yes easy :D remove local and remote branches with the commands: git checkout master git branch -d maint-4.x git push origin :maint-4.x Really? master is at 5.0. What I'm looking for is to have move back maint-4.x to maint, then do it right to move maint to maint-4x and from then to create a new maint from master. Yes you need to delete maint-4.x locally and remotely then « create » a new maint and a new master. If you think it’s obscur for you i can do it. Regards, Yves -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] start with branch renaming/moving
Hi kp, no « renaming » branch is not the right thing to do. Also removing integration branches on the repository is not a good idea :D It seems there a problem has my local maint branch is now not « attach » to a remote maint branch (do you remove or change the maint branch) ? In any case we only do fast-forward for integration branch !! I have update the Git Workflow guide to explain how to manage the maint branch after a new release: http://goo.gl/dAxfQ2 so in our case we need to COPY the old maint branch to another name: maint-4.x if we want to continue to maintain it or v4.x if the branch will not get updates: git branch maint-4.x maint or git branch v4.x maint After that we need to fast forward the maint branch to master so the master branch become the new maint branch: git checkout maint git merge —ff-only master After that we can work on master like before and tag the new releases. Sorry for the time to reply but i don’t see your message during christmas holidays. Regards, Yves Le 4 janv. 2014 à 20:19, KP Kirchdörfer kap...@users.sourceforge.net a écrit : Hi; I've recently updated my router to run with a kernel 3.10.25 and it works - as you when reading this mail :). I've also get a raspberry pi up and running with the same kernel and build from the rpi branch. So I think it's time, as proposed a few days ago, to move master to maint, and to merge the rpi branch into master as new master. First I merged rpi and master locally, and with Yves hints given earlier how to resolve issues shown with git status I've build a new local branch, from which I've build the above mentioned versions runing on my router and the raspberry. So this part went well. Renaming remote branches is another task. I've googled around and found the easiest way to accomplish this task with the commands: git branch -m old_branch new_branch # Rename branch locally git push origin :old_branch # Delete the old branch git push --set-upstream origin new_branch # Push the new branch, set local branch to track the new remote I did that to test with the maint branch (movng to maint-4.x), seeming uncritical to me. While it worked locally, I'm unshure if other team memeber tracking the branch maint will be moved automatically to maint-4.x. I've added a new file in the new branch for testing TEST_GIT_MOVING. Is that the correct approach to rename remote repository? Does work others as well as on my side? If not, what has to be done on other users client tracking the remote branch? kp -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] start with branch renaming/moving
Hi Yves on 06.01.2014 10:34, Yves Blusseau wrote: Hi kp, no « renaming » branch is not the right thing to do. Also removing integration branches on the repository is not a good idea :D It seems there a problem has my local maint branch is now not « attach » to a remote maint branch (do you remove or change the maint branch) ? In any case we only do fast-forward for integration branch !! I have update the Git Workflow guide to explain how to manage the maint branch after a new release: http://goo.gl/dAxfQ2 so in our case we need to COPY the old maint branch to another name: maint-4.x if we want to continue to maintain it or v4.x if the branch will not get updates: git branch maint-4.x maint or git branch v4.x maint After that we need to fast forward the maint branch to master so the master branch become the new maint branch: git checkout maint git merge —ff-only master After that we can work on master like before and tag the new releases. All this sounds fine for the central repository, would you mind to elaborate this for the distributed (workspace) repositories? What is the canonical way distribute the new repository structure? cheers Erich smime.p7s Description: S/MIME Cryptographic Signature -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] start with branch renaming/moving
Le 6 janv. 2014 à 11:07, Erich Titl erich.t...@think.ch a écrit : Hi Yves Hi Erich All this sounds fine for the central repository, would you mind to elaborate this for the distributed (workspace) repositories? What is the canonical way distribute the new repository structure? I don’t understand, you checkout the central repository into local. Can you explain me your problem exactly, because (sorry) i don’t understand your problematic ? Regards, Yves -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] start with branch renaming/moving
Hi Yves on 06.01.2014 13:00, Yves Blusseau wrote: Le 6 janv. 2014 à 11:07, Erich Titl erich.t...@think.ch a écrit : Hi Yves Hi Erich All this sounds fine for the central repository, would you mind to elaborate this for the distributed (workspace) repositories? What is the canonical way distribute the new repository structure? I don’t understand, you checkout the central repository into local. Can you explain me your problem exactly, because (sorry) i don’t understand your problematic ? If the central repository gets changed structurally, what needs to be done to the peripheral copies, are they just magically modified? cheers Erich smime.p7s Description: S/MIME Cryptographic Signature -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] start with branch renaming/moving
Le 6 janv. 2014 à 16:33, Erich Titl erich.t...@think.ch a écrit : If the central repository gets changed structurally, what needs to be done to the peripheral copies, are they just magically modified? If we only fast-forward central repository branches nothing specific things is needed to be done locally. Only fetch or pull to be in sync with the central repository. Regards, Yves -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] start with branch renaming/moving
Hi Yves; I knew I made something wrong :) Because of that I started only with the old maint branch, which I hoped wouldn't be that harmful, and didn't touch anything else. Am Montag, 6. Januar 2014, 10:34:30 schrieb Yves Blusseau: Hi kp, no « renaming » branch is not the right thing to do. Also removing integration branches on the repository is not a good idea :D It seems there a problem has my local maint branch is now not « attach » to a remote maint branch (do you remove or change the maint branch) ? I renamed/moved maint to maint-4-x (see commands below) The main idea was that maint until now has had fixes for 4.x, where mainly master was for version 5. I now want to move 5.0.x to maint, which receive further maintenance for shure, while preserving a way to maintain also 4.x if necessary, though I do expect very few changes. And the idea also is to merge the rpi branch into master, that means master will be moved feature-wise to a 3.10 kernel etc and the main development branch and base for the next major version (5.1). In any case we only do fast-forward for integration branch !! I have update the Git Workflow guide to explain how to manage the maint branch after a new release: http://goo.gl/dAxfQ2 I've read that, but I do not understand, sorry. Given that we only had maint branch, and that the command I know to create a new branch is git branch current-branch new branch the command in the docs, looks to me the other way round. I would have expected git branch maint maint-X.(Y-1) so in our case we need to COPY the old maint branch to another name: maint-4.x if we want to continue to maintain it or v4.x if the branch will not get updates: git branch maint-4.x maint or git branch v4.x maint See above. Just asking, before I make more errors. After that we need to fast forward the maint branch to master so the master branch become the new maint branch: git checkout maint git merge —ff-only master After that we can work on master like before and tag the new releases. Sorry for the time to reply but i don’t see your message during christmas holidays. No pb, thx for responding and patience. I learned a lot the last year about working with git, and I hope at the end of the year I'll be able to doing basic tasks error-free :) btw: how can we fix the wrong rename/move of maint to maint-4.x? kp Le 4 janv. 2014 à 20:19, KP Kirchdörfer kap...@users.sourceforge.net a écrit : Hi; I've recently updated my router to run with a kernel 3.10.25 and it works - as you when reading this mail :). I've also get a raspberry pi up and running with the same kernel and build from the rpi branch. So I think it's time, as proposed a few days ago, to move master to maint, and to merge the rpi branch into master as new master. First I merged rpi and master locally, and with Yves hints given earlier how to resolve issues shown with git status I've build a new local branch, from which I've build the above mentioned versions runing on my router and the raspberry. So this part went well. Renaming remote branches is another task. I've googled around and found the easiest way to accomplish this task with the commands: git branch -m old_branch new_branch # Rename branch locally git push origin :old_branch # Delete the old branch git push --set-upstream origin new_branch # Push the new branch, set local branch to track the new remote I did that to test with the maint branch (movng to maint-4.x), seeming uncritical to me. While it worked locally, I'm unshure if other team memeber tracking the branch maint will be moved automatically to maint-4.x. I've added a new file in the new branch for testing TEST_GIT_MOVING. Is that the correct approach to rename remote repository? Does work others as well as on my side? If not, what has to be done on other users client tracking the remote branch? kp -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] start with branch renaming/moving
Le 6 janv. 2014 à 17:31, KP Kirchdörfer kap...@users.sourceforge.net a écrit : Hi Yves; I knew I made something wrong :) Because of that I started only with the old maint branch, which I hoped wouldn’t be that harmful, and didn't touch anything else. It hard to break (not recoverable) in git. The main idea was that maint until now has had fixes for 4.x, where mainly master was for version 5. I now want to move 5.0.x to maint, which receive further maintenance for shure, while preserving a way to maintain also 4.x if necessary, though I do expect very few changes. And the idea also is to merge the rpi branch into master, that means master will be moved feature-wise to a 3.10 kernel etc and the main development branch and base for the next major version (5.1). In any case we only do fast-forward for integration branch !! I have update the Git Workflow guide to explain how to manage the maint branch after a new release: http://goo.gl/dAxfQ2 I've read that, but I do not understand, sorry. Given that we only had maint branch, and that the command I know to create a new branch is git branch current-branch new branch No the command is git branch new-branch start-point so to copy the old maint branch to maint-4.x do: git branch maint-4.x maint the command in the docs, looks to me the other way round. I would have expected git branch maint maint-X.(Y-1) No it’s git branch maint-X.(Y-1) maint After that we need to fast forward the maint branch to master so the master branch become the new maint branch: git checkout maint git merge —ff-only master After that we can work on master like before and tag the new releases. Sorry for the time to reply but i don’t see your message during christmas holidays. No pb, thx for responding and patience. I learned a lot the last year about working with git, and I hope at the end of the year I’ll be able to doing basic tasks error-free :) I have try rapidly do ff the old maint to master and it’s not working because you have forget to merge a commit in maint in master. Do: git log master..maint commit 9dff17faf09948a1232324a41715e1a5f06d5cb7 (origin/maint, maint) Author: kapeka kap...@users.sourceforge.net Date: Sun Jun 23 15:35:57 2013 remove outdated entries This commit (9dff17fa) must be merge into master even if it cannot apply at all in master. Remember to always merge commit upwards along integration branches. So first merge (and resolv the conflict) the commit in master using the command describe here: http://bit.ly/JYvUbZ I can do it for you if you have a difficulty to resolv the conflict. Then you can fast-forward the maint to master (so the maint branch will be at the current master position). btw: how can we fix the wrong rename/move of maint to maint-4.x? Yes easy :D remove local and remote branches with the commands: git checkout master git branch -d maint-4.x git push origin :maint-4.x Now you can follow the instructions above to copy maint to maint-4.x and master to maint Regards, Yves smime.p7s Description: S/MIME cryptographic signature -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] start with branch renaming/moving
Am Montag, 6. Januar 2014, 18:00:08 schrieb Yves Blusseau: Le 6 janv. 2014 à 17:31, KP Kirchdörfer kap...@users.sourceforge.net a écrit : Hi Yves; I knew I made something wrong :) Because of that I started only with the old maint branch, which I hoped wouldn’t be that harmful, and didn't touch anything else. It hard to break (not recoverable) in git. Good :) The main idea was that maint until now has had fixes for 4.x, where mainly master was for version 5. I now want to move 5.0.x to maint, which receive further maintenance for shure, while preserving a way to maintain also 4.x if necessary, though I do expect very few changes. And the idea also is to merge the rpi branch into master, that means master will be moved feature-wise to a 3.10 kernel etc and the main development branch and base for the next major version (5.1). In any case we only do fast-forward for integration branch !! I have update the Git Workflow guide to explain how to manage the maint branch after a new release: http://goo.gl/dAxfQ2 I've read that, but I do not understand, sorry. Given that we only had maint branch, and that the command I know to create a new branch is git branch current-branch new branch No the command is git branch new-branch start-point so to copy the old maint branch to maint-4.x do: git branch maint-4.x maint the command in the docs, looks to me the other way round. I would have expected git branch maint maint-X.(Y-1) No it’s git branch maint-X.(Y-1) maint Ok. You are the expert. After that we need to fast forward the maint branch to master so the master branch become the new maint branch: git checkout maint git merge —ff-only master After that we can work on master like before and tag the new releases. Sorry for the time to reply but i don’t see your message during christmas holidays. No pb, thx for responding and patience. I learned a lot the last year about working with git, and I hope at the end of the year I’ll be able to doing basic tasks error-free :) I have try rapidly do ff the old maint to master and it’s not working because you have forget to merge a commit in maint in master. Do: git log master..maint commit 9dff17faf09948a1232324a41715e1a5f06d5cb7 (origin/maint, maint) Author: kapeka kap...@users.sourceforge.net Date: Sun Jun 23 15:35:57 2013 remove outdated entries This commit (9dff17fa) must be merge into master even if it cannot apply at all in master. Remember to always merge commit upwards along integration branches. So first merge (and resolv the conflict) the commit in master using the command describe here: http://bit.ly/JYvUbZ I believe did that with latest commits. I can do it for you if you have a difficulty to resolv the conflict. Then you can fast-forward the maint to master (so the maint branch will be at the current master position). Locally I do have maint-4.x, how to proceed? btw: how can we fix the wrong rename/move of maint to maint-4.x? Yes easy :D remove local and remote branches with the commands: git checkout master git branch -d maint-4.x git push origin :maint-4.x Really? master is at 5.0. What I'm looking for is to have move back maint-4.x to maint, then do it right to move maint to maint-4x and from then to create a new maint from master. Gosh, git is still too much for me :) kp Now you can follow the instructions above to copy maint to maint-4.x and master to maint Regards, Yves -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
