Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Hi Dasa, You could use git pull --rebase instead but this does not preserve merge commits I just did a test on my git lab, I've got a bare repo and 2 clones. Clone 1: 1- I checkout a new branch test1 2- I created a file test1.txt 2- I add/commit test1.txt 3- I checkout master 4- I merged --no-ff test1 5- I deleted test1 6- I push Clone 2: 1- I created a file file1.txt 2- I add/commit file1.txt 3- I pull --rebase 4- I push Clone 1: 1- I pull --rebase the git log on both clones shows the merge commit, it has been preserved, so, I wonder what do you mean, did I miss something ? Thanks, -Fred -Message d'origine- From: Dasa Paddock Sent: Tuesday, March 19, 2013 8:12 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Here's one way to avoid having git pull create a merge commit on your develop branch. Checkout your develop branch and then run: $ git pull --ff-only If this give you an error it means you have commits on your develop branch that are ahead of the remote develop branch. So then, run: $ git rebase --preserve-merges origin/develop This will rebase your commits on your local develop branch onto the remote develop branch. (Use -p for short.) You could use git pull --rebase instead but this does not preserve merge commits, which is what I commonly have following the git flow workflow. For more info on this, see: http://notes.envato.com/developers/rebasing-merge-commits-in-git/ --Dasa On Mar 19, 2013, at 11:39 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: This is the best explanation of when to merge vs. rebase that I've seen: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ Added as comment to the wiki -Fred -Message d'origine- From: Frédéric THOMAS Sent: Tuesday, March 19, 2013 7:23 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hi, This document is perfect, the maybe only little point it didn't cover in Keeping the feature branch up to date is the possibility interactively rebase your commit, which allows in case of too much conflicts, to abord it, reset --hard and pull (fecth/merge). Thanks for sharing, -Fred -Message d'origine- From: Dasa Paddock Sent: Tuesday, March 19, 2013 6:57 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop This is the best explanation of when to merge vs. rebase that I've seen: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ There's also now a public beta of SourceTree for Windows available: http://blog.sourcetreeapp.com/2013/03/19/introducing-sourcetree-for-windows-a-free-desktop-client-for-git/ In regards to these unwanted merges, I've seen GitHub for Windows do this automatically instead of giving an error when you click it's Sync button and your local develop branch has commits that have not been pushed yet but the remote also also has commits that are not yet on the local develop branch. --Dasa
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
The problem would be if you had first pushed clone 2 and then did the pull --rebase in clone 1. For more info see: http://notes.envato.com/developers/rebasing-merge-commits-in-git/ --Dasa On Mar 20, 2013, at 11:11 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: Hi Dasa, You could use git pull --rebase instead but this does not preserve merge commits I just did a test on my git lab, I've got a bare repo and 2 clones. Clone 1: 1- I checkout a new branch test1 2- I created a file test1.txt 2- I add/commit test1.txt 3- I checkout master 4- I merged --no-ff test1 5- I deleted test1 6- I push Clone 2: 1- I created a file file1.txt 2- I add/commit file1.txt 3- I pull --rebase 4- I push Clone 1: 1- I pull --rebase the git log on both clones shows the merge commit, it has been preserved, so, I wonder what do you mean, did I miss something ? Thanks, -Fred -Message d'origine- From: Dasa Paddock Sent: Tuesday, March 19, 2013 8:12 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Here's one way to avoid having git pull create a merge commit on your develop branch. Checkout your develop branch and then run: $ git pull --ff-only If this give you an error it means you have commits on your develop branch that are ahead of the remote develop branch. So then, run: $ git rebase --preserve-merges origin/develop This will rebase your commits on your local develop branch onto the remote develop branch. (Use -p for short.) You could use git pull --rebase instead but this does not preserve merge commits, which is what I commonly have following the git flow workflow. For more info on this, see: http://notes.envato.com/developers/rebasing-merge-commits-in-git/ --Dasa On Mar 19, 2013, at 11:39 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: This is the best explanation of when to merge vs. rebase that I've seen: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ Added as comment to the wiki -Fred -Message d'origine- From: Frédéric THOMAS Sent: Tuesday, March 19, 2013 7:23 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hi, This document is perfect, the maybe only little point it didn't cover in Keeping the feature branch up to date is the possibility interactively rebase your commit, which allows in case of too much conflicts, to abord it, reset --hard and pull (fecth/merge). Thanks for sharing, -Fred -Message d'origine- From: Dasa Paddock Sent: Tuesday, March 19, 2013 6:57 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop This is the best explanation of when to merge vs. rebase that I've seen: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ There's also now a public beta of SourceTree for Windows available: http://blog.sourcetreeapp.com/2013/03/19/introducing-sourcetree-for-windows-a-free-desktop-client-for-git/ In regards to these unwanted merges, I've seen GitHub for Windows do this automatically instead of giving an error when you click it's Sync button and your local develop branch has commits that have not been pushed yet but the remote also also has commits that are not yet on the local develop branch. --Dasa
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
The problem would be if you had first pushed clone 2 and then did the pull --rebase in clone 1 But in this case I won't have and I don't want any merge commit at all in clone 2 indeed, it's a single commit on the master, something should be missed in that dicussion, could you provide me an example clearer than in your link ? Thanks, -Fred -Message d'origine- From: Dasa Paddock Sent: Wednesday, March 20, 2013 7:16 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop The problem would be if you had first pushed clone 2 and then did the pull --rebase in clone 1. For more info see: http://notes.envato.com/developers/rebasing-merge-commits-in-git/ --Dasa On Mar 20, 2013, at 11:11 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: Hi Dasa, You could use git pull --rebase instead but this does not preserve merge commits I just did a test on my git lab, I've got a bare repo and 2 clones. Clone 1: 1- I checkout a new branch test1 2- I created a file test1.txt 2- I add/commit test1.txt 3- I checkout master 4- I merged --no-ff test1 5- I deleted test1 6- I push Clone 2: 1- I created a file file1.txt 2- I add/commit file1.txt 3- I pull --rebase 4- I push Clone 1: 1- I pull --rebase the git log on both clones shows the merge commit, it has been preserved, so, I wonder what do you mean, did I miss something ? Thanks, -Fred -Message d'origine- From: Dasa Paddock Sent: Tuesday, March 19, 2013 8:12 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Here's one way to avoid having git pull create a merge commit on your develop branch. Checkout your develop branch and then run: $ git pull --ff-only If this give you an error it means you have commits on your develop branch that are ahead of the remote develop branch. So then, run: $ git rebase --preserve-merges origin/develop This will rebase your commits on your local develop branch onto the remote develop branch. (Use -p for short.) You could use git pull --rebase instead but this does not preserve merge commits, which is what I commonly have following the git flow workflow. For more info on this, see: http://notes.envato.com/developers/rebasing-merge-commits-in-git/ --Dasa On Mar 19, 2013, at 11:39 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: This is the best explanation of when to merge vs. rebase that I've seen: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ Added as comment to the wiki -Fred -Message d'origine- From: Frédéric THOMAS Sent: Tuesday, March 19, 2013 7:23 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hi, This document is perfect, the maybe only little point it didn't cover in Keeping the feature branch up to date is the possibility interactively rebase your commit, which allows in case of too much conflicts, to abord it, reset --hard and pull (fecth/merge). Thanks for sharing, -Fred -Message d'origine- From: Dasa Paddock Sent: Tuesday, March 19, 2013 6:57 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop This is the best explanation of when to merge vs. rebase that I've seen: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ There's also now a public beta of SourceTree for Windows available: http://blog.sourcetreeapp.com/2013/03/19/introducing-sourcetree-for-windows-a-free-desktop-client-for-git/ In regards to these unwanted merges, I've seen GitHub for Windows do this automatically instead of giving an error when you click it's Sync button and your local develop branch has commits that have not been pushed yet but the remote also also has commits that are not yet on the local develop branch. --Dasa
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Try: Clone 1: 1- I checkout a new branch test1 2- I created a file test1.txt 3- I add/commit test1.txt 4- I checkout master 5- I merged --no-ff test1 Clone 2: 1- I created a file file1.txt 2- I add/commit file1.txt 3- I push Clone 1: 1- I pull --rebase Now Clone 1 would only have the commit to test1.txt. The merge commit created by merge --no-ff test1 would be gone. Hope this helps, --Dasa On Mar 20, 2013, at 11:25 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: The problem would be if you had first pushed clone 2 and then did the pull --rebase in clone 1 But in this case I won't have and I don't want any merge commit at all in clone 2 indeed, it's a single commit on the master, something should be missed in that dicussion, could you provide me an example clearer than in your link ? Thanks, -Fred -Message d'origine- From: Dasa Paddock Sent: Wednesday, March 20, 2013 7:16 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop The problem would be if you had first pushed clone 2 and then did the pull --rebase in clone 1. For more info see: http://notes.envato.com/developers/rebasing-merge-commits-in-git/ --Dasa On Mar 20, 2013, at 11:11 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: Hi Dasa, You could use git pull --rebase instead but this does not preserve merge commits I just did a test on my git lab, I've got a bare repo and 2 clones. Clone 1: 1- I checkout a new branch test1 2- I created a file test1.txt 2- I add/commit test1.txt 3- I checkout master 4- I merged --no-ff test1 5- I deleted test1 6- I push Clone 2: 1- I created a file file1.txt 2- I add/commit file1.txt 3- I pull --rebase 4- I push Clone 1: 1- I pull --rebase the git log on both clones shows the merge commit, it has been preserved, so, I wonder what do you mean, did I miss something ? Thanks, -Fred -Message d'origine- From: Dasa Paddock Sent: Tuesday, March 19, 2013 8:12 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Here's one way to avoid having git pull create a merge commit on your develop branch. Checkout your develop branch and then run: $ git pull --ff-only If this give you an error it means you have commits on your develop branch that are ahead of the remote develop branch. So then, run: $ git rebase --preserve-merges origin/develop This will rebase your commits on your local develop branch onto the remote develop branch. (Use -p for short.) You could use git pull --rebase instead but this does not preserve merge commits, which is what I commonly have following the git flow workflow. For more info on this, see: http://notes.envato.com/developers/rebasing-merge-commits-in-git/ --Dasa On Mar 19, 2013, at 11:39 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: This is the best explanation of when to merge vs. rebase that I've seen: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ Added as comment to the wiki -Fred -Message d'origine- From: Frédéric THOMAS Sent: Tuesday, March 19, 2013 7:23 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hi, This document is perfect, the maybe only little point it didn't cover in Keeping the feature branch up to date is the possibility interactively rebase your commit, which allows in case of too much conflicts, to abord it, reset --hard and pull (fecth/merge). Thanks for sharing, -Fred -Message d'origine- From: Dasa Paddock Sent: Tuesday, March 19, 2013 6:57 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop This is the best explanation of when to merge vs. rebase that I've seen: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ There's also now a public beta of SourceTree for Windows available: http://blog.sourcetreeapp.com/2013/03/19/introducing-sourcetree-for-windows-a-free-desktop-client-for-git/ In regards to these unwanted merges, I've seen GitHub for Windows do this automatically instead of giving an error when you click it's Sync button and your local develop branch has commits that have not been pushed yet but the remote also also has commits that are not yet on the local develop branch. --Dasa
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Ok, effectively, if the branch which is merged hasn't been pushed yet, it might be a problem, in that special case the git pull --ff-only / git rebase --preserve-merges origin/develop makes sense. Thanks, -Fred -Message d'origine- From: Dasa Paddock Sent: Wednesday, March 20, 2013 7:43 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Try: Clone 1: 1- I checkout a new branch test1 2- I created a file test1.txt 3- I add/commit test1.txt 4- I checkout master 5- I merged --no-ff test1 Clone 2: 1- I created a file file1.txt 2- I add/commit file1.txt 3- I push Clone 1: 1- I pull --rebase Now Clone 1 would only have the commit to test1.txt. The merge commit created by merge --no-ff test1 would be gone. Hope this helps, --Dasa On Mar 20, 2013, at 11:25 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: The problem would be if you had first pushed clone 2 and then did the pull --rebase in clone 1 But in this case I won't have and I don't want any merge commit at all in clone 2 indeed, it's a single commit on the master, something should be missed in that dicussion, could you provide me an example clearer than in your link ? Thanks, -Fred -Message d'origine- From: Dasa Paddock Sent: Wednesday, March 20, 2013 7:16 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop The problem would be if you had first pushed clone 2 and then did the pull --rebase in clone 1. For more info see: http://notes.envato.com/developers/rebasing-merge-commits-in-git/ --Dasa On Mar 20, 2013, at 11:11 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: Hi Dasa, You could use git pull --rebase instead but this does not preserve merge commits I just did a test on my git lab, I've got a bare repo and 2 clones. Clone 1: 1- I checkout a new branch test1 2- I created a file test1.txt 2- I add/commit test1.txt 3- I checkout master 4- I merged --no-ff test1 5- I deleted test1 6- I push Clone 2: 1- I created a file file1.txt 2- I add/commit file1.txt 3- I pull --rebase 4- I push Clone 1: 1- I pull --rebase the git log on both clones shows the merge commit, it has been preserved, so, I wonder what do you mean, did I miss something ? Thanks, -Fred -Message d'origine- From: Dasa Paddock Sent: Tuesday, March 19, 2013 8:12 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Here's one way to avoid having git pull create a merge commit on your develop branch. Checkout your develop branch and then run: $ git pull --ff-only If this give you an error it means you have commits on your develop branch that are ahead of the remote develop branch. So then, run: $ git rebase --preserve-merges origin/develop This will rebase your commits on your local develop branch onto the remote develop branch. (Use -p for short.) You could use git pull --rebase instead but this does not preserve merge commits, which is what I commonly have following the git flow workflow. For more info on this, see: http://notes.envato.com/developers/rebasing-merge-commits-in-git/ --Dasa On Mar 19, 2013, at 11:39 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: This is the best explanation of when to merge vs. rebase that I've seen: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ Added as comment to the wiki -Fred -Message d'origine- From: Frédéric THOMAS Sent: Tuesday, March 19, 2013 7:23 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hi, This document is perfect, the maybe only little point it didn't cover in Keeping the feature branch up to date is the possibility interactively rebase your commit, which allows in case of too much conflicts, to abord it, reset --hard and pull (fecth/merge). Thanks for sharing, -Fred -Message d'origine- From: Dasa Paddock Sent: Tuesday, March 19, 2013 6:57 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop This is the best explanation of when to merge vs. rebase that I've seen: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ There's also now a public beta of SourceTree for Windows available: http://blog.sourcetreeapp.com/2013/03/19/introducing-sourcetree-for-windows-a-free-desktop-client-for-git/ In regards to these unwanted merges, I've seen GitHub for Windows do this automatically instead of giving an error when you click it's Sync button and your local develop branch has commits that have not been pushed yet but the remote also also has commits that are not yet on the local develop branch. --Dasa
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Hi, Very odd as I've made no changes to README - any idea what''s happen here? Justin On 19/03/2013, at 11:37 PM, jmcl...@apache.org wrote: Updated Branches: refs/heads/develop b5fce9368 - 4f6c47d2e Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Project: http://git-wip-us.apache.org/repos/asf/flex-sdk/repo Commit: http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/4f6c47d2 Tree: http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/4f6c47d2 Diff: http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/4f6c47d2 Branch: refs/heads/develop Commit: 4f6c47d2e927860d914a96771b7bffe706e8fff1 Parents: 85af480 b5fce93 Author: Justin Mclean jmcl...@apache.org Authored: Tue Mar 19 23:34:02 2013 +1100 Committer: Justin Mclean jmcl...@apache.org Committed: Tue Mar 19 23:34:02 2013 +1100 -- README | 25 + 1 files changed, 21 insertions(+), 4 deletions(-) --
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
yeah, you shoud run this[1] once to allow automatic rebasing on merge which I referenced here [2] as Suggested pratices, that what I was talking about yesterday about messing the history. -Fred [1] git config --global branch.autosetuprebase always [2] http://flex.apache.org/dev-sourcecode.html -Message d'origine- From: Justin Mclean Sent: Tuesday, March 19, 2013 1:50 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hi, Very odd as I've made no changes to README - any idea what''s happen here? Justin On 19/03/2013, at 11:37 PM, jmcl...@apache.org wrote: Updated Branches: refs/heads/develop b5fce9368 - 4f6c47d2e Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Project: http://git-wip-us.apache.org/repos/asf/flex-sdk/repo Commit: http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/4f6c47d2 Tree: http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/4f6c47d2 Diff: http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/4f6c47d2 Branch: refs/heads/develop Commit: 4f6c47d2e927860d914a96771b7bffe706e8fff1 Parents: 85af480 b5fce93 Author: Justin Mclean jmcl...@apache.org Authored: Tue Mar 19 23:34:02 2013 +1100 Committer: Justin Mclean jmcl...@apache.org Committed: Tue Mar 19 23:34:02 2013 +1100 -- README | 25 + 1 files changed, 21 insertions(+), 4 deletions(-) --
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
I wanted to send you a pic of the history but I can't, instead you can run [1] -Fred [1] git log --graph --oneline --all -Message d'origine- From: Frédéric THOMAS Sent: Tuesday, March 19, 2013 2:06 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop yeah, you shoud run this[1] once to allow automatic rebasing on merge which I referenced here [2] as Suggested pratices, that what I was talking about yesterday about messing the history. -Fred [1] git config --global branch.autosetuprebase always [2] http://flex.apache.org/dev-sourcecode.html -Message d'origine- From: Justin Mclean Sent: Tuesday, March 19, 2013 1:50 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hi, Very odd as I've made no changes to README - any idea what''s happen here? Justin On 19/03/2013, at 11:37 PM, jmcl...@apache.org wrote: Updated Branches: refs/heads/develop b5fce9368 - 4f6c47d2e Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Project: http://git-wip-us.apache.org/repos/asf/flex-sdk/repo Commit: http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/4f6c47d2 Tree: http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/4f6c47d2 Diff: http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/4f6c47d2 Branch: refs/heads/develop Commit: 4f6c47d2e927860d914a96771b7bffe706e8fff1 Parents: 85af480 b5fce93 Author: Justin Mclean jmcl...@apache.org Authored: Tue Mar 19 23:34:02 2013 +1100 Committer: Justin Mclean jmcl...@apache.org Committed: Tue Mar 19 23:34:02 2013 +1100 -- README | 25 + 1 files changed, 21 insertions(+), 4 deletions(-) --
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
HI, [1] git log --graph --oneline --all Which produces nothing that's meaningful to IMO. ie README isn't mentioned. * 4f6c47d Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop |\ | * b5fce93 FLEX-33435 added more details | * 9c7c97e Updated for the Svn to Git migration * | 85af480 Added el_GR locale for postcodes * | 63580a8 Adding more datagrid double click modes |/ * c5869e4 Added nl_NL locale for postcode validator * cbfeae5 Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop |\ | * 5e15ba8 OS X specific entry for flex-tlf link * | f825b4a Added fi_FI locale for postcode validator |/ * 35c5fbd Added ru_RU locale for postcode validator * fc57407 Added pt_PT postcode validator strings * 8645f87 Added pt_BR postcode validator strings * 2d41d85 Added ja_JP postcode validator strings * 8b9c4a6 Added de_DE postcode validator strings Is there any way to get a list of files changed line by line? Justin
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
That's there [1], it's not the git default because in git we're soppose to work on branches for features and more than one commit bug fixes, then merge without rebasing allows the history to keep track of this set of changes, it creates a merge commit. What you did is only do few commits as part of a bugfix, but because you wasn't working on a branch, when you did git pull, internaly, git did a git fetch and then a git merge and because I modified files in between, no fast forward was possible, so, it let you commits before mine, instead, with the command I gave you, the git pull does a git fetch and than a git rebase with rewrite the commits history to place your commits after mine. If you look at the history, you can see that your commits has been placed before mines even though I pushed before and the first line is the merge commit, the reason why it touched the README I committed. * 4f6c47d Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop |\ | * b5fce93 FLEX-33435 added more details | * 9c7c97e Updated for the Svn to Git migration * | 85af480 Added el_GR locale for postcodes * | 63580a8 Adding more datagrid double click modes |/ * c5869e4 Added nl_NL locale for postcode validator * cbfeae5 Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop |\ | * 5e15ba8 OS X specific entry for flex-tlf link * | f825b4a Added fi_FI locale for postcode validator |/ * 35c5fbd Added ru_RU locale for postcode validator * fc57407 Added pt_PT postcode validator strings * 8645f87 Added pt_BR postcode validator strings * 2d41d85 Added ja_JP postcode validator strings * 8b9c4a6 Added de_DE postcode validator strings -Fred [1] https://git-wip-us.apache.org/docs/committer-practices.html -Message d'origine- From: Frédéric THOMAS Sent: Tuesday, March 19, 2013 2:06 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop yeah, you shoud run this[1] once to allow automatic rebasing on merge which I referenced here [2] as Suggested pratices, that what I was talking about yesterday about messing the history. -Fred [1] git config --global branch.autosetuprebase always [2] http://flex.apache.org/dev-sourcecode.html -Message d'origine- From: Justin Mclean Sent: Tuesday, March 19, 2013 1:50 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hi, Very odd as I've made no changes to README - any idea what''s happen here? Justin On 19/03/2013, at 11:37 PM, jmcl...@apache.org wrote: Updated Branches: refs/heads/develop b5fce9368 - 4f6c47d2e Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Project: http://git-wip-us.apache.org/repos/asf/flex-sdk/repo Commit: http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/4f6c47d2 Tree: http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/4f6c47d2 Diff: http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/4f6c47d2 Branch: refs/heads/develop Commit: 4f6c47d2e927860d914a96771b7bffe706e8fff1 Parents: 85af480 b5fce93 Author: Justin Mclean jmcl...@apache.org Authored: Tue Mar 19 23:34:02 2013 +1100 Committer: Justin Mclean jmcl...@apache.org Committed: Tue Mar 19 23:34:02 2013 +1100 -- README | 25 + 1 files changed, 21 insertions(+), 4 deletions(-) --
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Hi, it's not the git default because in git we're soppose to work on branches for features and more than one commit bug fixes, All my bug fixes were a single commit. Are we really support to make a branch for that then merge the branch and then commit for a changing in a single file? AFAIK The git flow model doesn't say you need to make a feature branch for a bug fixes. then merge without rebasing allows the history to keep track of this set of changes, it creates a merge commit. Sorry that makes no sense to me. What you did is only do few commits as part of a bugfix No each commit dealing with a different bug fix. Each commit (some with single file/other with multiple) referred to a single bugfix. , but because you wasn't working on a branch, when you did git pull Well I only had to do a pull because git doesn't allow you to commit changes in a directory when there are outstanding upstream changes in another directory. rewrite the commits history to place your commits after mine. Doesn't that then mean that the history is now out of order? Justin
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Hi, If you look at the history, you can see that your commits has been placed before mines even though I pushed before and the first line is the merge commit, the reason why it touched the README I committed. I guess the question is is README in a correct state or not? And if it didn't make any changes to the file why did it email the list saying this: README | 25 + 1 files changed, 21 insertions(+), 4 deletions(-) Does this mean we going to have a large number of false positives with Git change emails? Justin
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
All my bug fixes were a single commit. Are we really support to make a branch for that then merge the branch and then commit for a changing in a single file? If I where you, I would create a branch named JIRA_ID for a such hudge bugfix, do all my commits relative to this bugfix to it, even push the branch, once all done, I whould do a git fetch and then, from the develop branch, git merge JIRA_ID and push it again. But because generaly, I guess people won't do that and will work on the main dev branch, before to push, they should do a git pull -rebase but even, because they will forget, it is better to instruct git to automaticly rebase on pull (the command I gave you in the previous post) AFAIK The git flow model doesn't say you need to make a feature branch for a bug fixes Yes, look at [1] and see hotfixes. No each commit dealing with a different bug fix. Each commit (some with single file/other with multiple) referred to a single bugfix. It is exactly what I meant Well I only had to do a pull because git doesn't allow you to commit changes in a directory when there are outstanding upstream changes in another directory. And you should have done a git pull -rebase instead, because they will forget to do so, it is better to instruct git to automaticly rebase on pull (the command I gave you in the previous post) -Fred [1] http://nvie.com/posts/a-successful-git-branching-model/ -Message d'origine- From: Justin Mclean Sent: Tuesday, March 19, 2013 2:59 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hi, it's not the git default because in git we're soppose to work on branches for features and more than one commit bug fixes, All my bug fixes were a single commit. Are we really support to make a branch for that then merge the branch and then commit for a changing in a single file? AFAIK The git flow model doesn't say you need to make a feature branch for a bug fixes. then merge without rebasing allows the history to keep track of this set of changes, it creates a merge commit. Sorry that makes no sense to me. What you did is only do few commits as part of a bugfix No each commit dealing with a different bug fix. Each commit (some with single file/other with multiple) referred to a single bugfix. , but because you wasn't working on a branch, when you did git pull Well I only had to do a pull because git doesn't allow you to commit changes in a directory when there are outstanding upstream changes in another directory. rewrite the commits history to place your commits after mine. Doesn't that then mean that the history is now out of order? Justin
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
That's correspond to the 2 commits modifications I did on this file. -Fred -Message d'origine- From: Justin Mclean Sent: Tuesday, March 19, 2013 3:05 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hi, If you look at the history, you can see that your commits has been placed before mines even though I pushed before and the first line is the merge commit, the reason why it touched the README I committed. I guess the question is is README in a correct state or not? And if it didn't make any changes to the file why did it email the list saying this: README | 25 + 1 files changed, 21 insertions(+), 4 deletions(-) Does this mean we going to have a large number of false positives with Git change emails? Justin
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Hi, Yes, look at [1] and see hotfixes. Hotfixes apply to the release branch not the develop branch. And you should have done a git pull -rebase instead, because they will forget to do so, it is better to instruct git to automaticly rebase on pull (the command I gave you in the previous post) From my understanding a rebase can mess up history. Do we really want to do that as the default and if so what are the implication of that? Justin
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Hotfixes apply to the release branch not the develop branch. Oh, true but features and bugfixes are treated in the same way anyway except if the all bugfix is 1 or 2 little commits, in this last case, rebasing is the rule. From my understanding a rebase can mess up history. Do we really want to do that as the default and if so what are the implication of that? NO, that's the opposite, image the how awfull and difficult to read if then persons merge instead of rebasing because they don't work on branches, that will look like spaghetti, unreadable ! -Fred -Message d'origine- From: Justin Mclean Sent: Tuesday, March 19, 2013 3:44 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hi, Yes, look at [1] and see hotfixes. Hotfixes apply to the release branch not the develop branch. And you should have done a git pull -rebase instead, because they will forget to do so, it is better to instruct git to automaticly rebase on pull (the command I gave you in the previous post) From my understanding a rebase can mess up history. Do we really want to do that as the default and if so what are the implication of that? Justin
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
The --rebase option can be used to ensure a linear history by preventing unnecessary merge commits. Many developers prefer rebasing over merging, since it’s like saying, “I want to put my changes on top of what everybody else has done.” In this sense, using git pull with the --rebase flag is even more like svn update than a plain git pull. In fact, pulling with --rebase is such a common workflow that there is a dedicated configuration option for it: git config --global branch.autosetuprebase always -- From what I'm sure has to be read by any new git user http://atlassian.com/git/tutorial/git-basics -Fred -Message d'origine- From: Frédéric THOMAS Sent: Tuesday, March 19, 2013 3:56 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hotfixes apply to the release branch not the develop branch. Oh, true but features and bugfixes are treated in the same way anyway except if the all bugfix is 1 or 2 little commits, in this last case, rebasing is the rule. From my understanding a rebase can mess up history. Do we really want to do that as the default and if so what are the implication of that? NO, that's the opposite, image the how awfull and difficult to read if then persons merge instead of rebasing because they don't work on branches, that will look like spaghetti, unreadable ! -Fred -Message d'origine- From: Justin Mclean Sent: Tuesday, March 19, 2013 3:44 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hi, Yes, look at [1] and see hotfixes. Hotfixes apply to the release branch not the develop branch. And you should have done a git pull -rebase instead, because they will forget to do so, it is better to instruct git to automaticly rebase on pull (the command I gave you in the previous post) From my understanding a rebase can mess up history. Do we really want to do that as the default and if so what are the implication of that? Justin
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Hi, NO, that's the opposite Really? https://wincent.com/wiki/git_rebase:_you're_doing_it_wrong Dozen of stack overflow question on the issue which warn about rebasing. For instance: http://stackoverflow.com/questions/8939977/git-push-rejected-after-feature-branch-rebase Rebase and a shared repository generally do not get along. This is rewriting history. If others are using that branch or have branched from that branch then rebase will be quite unpleasant. http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions It really kills me that people are recommending a rebase workflow as a better alternative to a merge workflow for conflict resolution With rebase, there is no undo! Also http://git-scm.com/book/en/Git-Branching-Rebasing#The-Perils-of-Rebasing Again I'll ask do we really want this option to be the default? Justin
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
The first link says exactly what I'm saying, you want to put your changes on top of what everybody else has done. 'So git rebase is not wrong. But it's right only if it's YOUR VERY OWN PRIVATE git tree.' When you do a pull --rebase, you're rebasing only your commits on the top of the others commits, nothing before the origin/HEAD indeed. The 2nd and especially the 3rd links tell as well what I'm saying, they do a final merge because there are on branches, in between they rebase their own commits: clone the remote repo git checkout -b my_new_feature ..work and commit some stuff git rebase master ..work and commit some stuff git rebase master ..finish the feature git checkout master git merge --squash my_new_feature git branch -D my_new_feature The 4th link: Reason #1: Resolve conflicts once, instead of once for each commit This case is rare but easy to resolve, you abort your rebase on multi commits conflicts and to simplify your life, exceptionnaly, you do what he says, you do a merge, messing the history though. Reason #2: With rebase, there is no undo! Doesn't apply, because, you will never rebase your feature branch on the develop one but merge it and if you work directly on the develop branch, you will push a few of rebased commits which are yours. And I'm tired now, I haven't read the last one. -Fred -Message d'origine- From: Justin Mclean Sent: Tuesday, March 19, 2013 4:20 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hi, NO, that's the opposite Really? https://wincent.com/wiki/git_rebase:_you're_doing_it_wrong Dozen of stack overflow question on the issue which warn about rebasing. For instance: http://stackoverflow.com/questions/8939977/git-push-rejected-after-feature-branch-rebase Rebase and a shared repository generally do not get along. This is rewriting history. If others are using that branch or have branched from that branch then rebase will be quite unpleasant. http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions It really kills me that people are recommending a rebase workflow as a better alternative to a merge workflow for conflict resolution With rebase, there is no undo! Also http://git-scm.com/book/en/Git-Branching-Rebasing#The-Perils-of-Rebasing Again I'll ask do we really want this option to be the default? Justin
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
But to be short and resume what those links means: You rebase your own commits, git pull --rebase (internaly: git fetch/ git rebase) because you stay on your own branch you git pull (internaly: git fetch / git merge) from another branch your feature/bugfix branch you just completely coded. And if you know that most of the time you will work on the develop branch, you can forget the --rebase option setting: git config --global branch.autosetuprebase always -Fred -Message d'origine- From: Frédéric THOMAS Sent: Tuesday, March 19, 2013 4:56 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop The first link says exactly what I'm saying, you want to put your changes on top of what everybody else has done. 'So git rebase is not wrong. But it's right only if it's YOUR VERY OWN PRIVATE git tree.' When you do a pull --rebase, you're rebasing only your commits on the top of the others commits, nothing before the origin/HEAD indeed. The 2nd and especially the 3rd links tell as well what I'm saying, they do a final merge because there are on branches, in between they rebase their own commits: clone the remote repo git checkout -b my_new_feature ..work and commit some stuff git rebase master ..work and commit some stuff git rebase master ..finish the feature git checkout master git merge --squash my_new_feature git branch -D my_new_feature The 4th link: Reason #1: Resolve conflicts once, instead of once for each commit This case is rare but easy to resolve, you abort your rebase on multi commits conflicts and to simplify your life, exceptionnaly, you do what he says, you do a merge, messing the history though. Reason #2: With rebase, there is no undo! Doesn't apply, because, you will never rebase your feature branch on the develop one but merge it and if you work directly on the develop branch, you will push a few of rebased commits which are yours. And I'm tired now, I haven't read the last one. -Fred -Message d'origine- From: Justin Mclean Sent: Tuesday, March 19, 2013 4:20 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hi, NO, that's the opposite Really? https://wincent.com/wiki/git_rebase:_you're_doing_it_wrong Dozen of stack overflow question on the issue which warn about rebasing. For instance: http://stackoverflow.com/questions/8939977/git-push-rejected-after-feature-branch-rebase Rebase and a shared repository generally do not get along. This is rewriting history. If others are using that branch or have branched from that branch then rebase will be quite unpleasant. http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions It really kills me that people are recommending a rebase workflow as a better alternative to a merge workflow for conflict resolution With rebase, there is no undo! Also http://git-scm.com/book/en/Git-Branching-Rebasing#The-Perils-of-Rebasing Again I'll ask do we really want this option to be the default? Justin
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
And now it's really time to explain this to - or rather: prescribe this for - us mere mortals. I think a couple of simple use cases with the exact steps/commands on the wiki (checkout, commit, push, pull) should be an excellent start. Time for some of the other very vocal git proponents to step up and actually help out? EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl (http://www.ixsoftware.nl) On Tuesday, March 19, 2013 at 17:07, Frédéric THOMAS wrote: But to be short and resume what those links means: You rebase your own commits, git pull --rebase (internaly: git fetch/ git rebase) because you stay on your own branch you git pull (internaly: git fetch / git merge) from another branch your feature/bugfix branch you just completely coded. And if you know that most of the time you will work on the develop branch, you can forget the --rebase option setting: git config --global branch.autosetuprebase always -Fred -Message d'origine- From: Frédéric THOMAS Sent: Tuesday, March 19, 2013 4:56 PM To: dev@flex.apache.org (mailto:dev@flex.apache.org) Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop The first link says exactly what I'm saying, you want to put your changes on top of what everybody else has done. 'So git rebase is not wrong. But it's right only if it's YOUR VERY OWN PRIVATE git tree.' When you do a pull --rebase, you're rebasing only your commits on the top of the others commits, nothing before the origin/HEAD indeed. The 2nd and especially the 3rd links tell as well what I'm saying, they do a final merge because there are on branches, in between they rebase their own commits: clone the remote repo git checkout -b my_new_feature ..work and commit some stuff git rebase master ..work and commit some stuff git rebase master ..finish the feature git checkout master git merge --squash my_new_feature git branch -D my_new_feature The 4th link: Reason #1: Resolve conflicts once, instead of once for each commit This case is rare but easy to resolve, you abort your rebase on multi commits conflicts and to simplify your life, exceptionnaly, you do what he says, you do a merge, messing the history though. Reason #2: With rebase, there is no undo! Doesn't apply, because, you will never rebase your feature branch on the develop one but merge it and if you work directly on the develop branch, you will push a few of rebased commits which are yours. And I'm tired now, I haven't read the last one. -Fred -Message d'origine- From: Justin Mclean Sent: Tuesday, March 19, 2013 4:20 PM To: dev@flex.apache.org (mailto:dev@flex.apache.org) Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hi, NO, that's the opposite Really? https://wincent.com/wiki/git_rebase:_you're_doing_it_wrong Dozen of stack overflow question on the issue which warn about rebasing. For instance: http://stackoverflow.com/questions/8939977/git-push-rejected-after-feature-branch-rebase Rebase and a shared repository generally do not get along. This is rewriting history. If others are using that branch or have branched from that branch then rebase will be quite unpleasant. http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions It really kills me that people are recommending a rebase workflow as a better alternative to a merge workflow for conflict resolution With rebase, there is no undo! Also http://git-scm.com/book/en/Git-Branching-Rebasing#The-Perils-of-Rebasing Again I'll ask do we really want this option to be the default? Justin
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Hi Erik, I added a comment to the wiki with a link which to git basics explanations but must be read and understood by all new git user IMO, once those basics clear, which cover all what every boby asks at the moment, I might go further writing someting on the wiki but before that I don't want to waste my time (even I repeated myself a lot recently) on explainations already written and even in a better way than I can do it. -Fred -Message d'origine- From: Erik de Bruin Sent: Tuesday, March 19, 2013 5:35 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop And now it's really time to explain this to - or rather: prescribe this for - us mere mortals. I think a couple of simple use cases with the exact steps/commands on the wiki (checkout, commit, push, pull) should be an excellent start. Time for some of the other very vocal git proponents to step up and actually help out? EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl (http://www.ixsoftware.nl) On Tuesday, March 19, 2013 at 17:07, Frédéric THOMAS wrote: But to be short and resume what those links means: You rebase your own commits, git pull --rebase (internaly: git fetch/ git rebase) because you stay on your own branch you git pull (internaly: git fetch / git merge) from another branch your feature/bugfix branch you just completely coded. And if you know that most of the time you will work on the develop branch, you can forget the --rebase option setting: git config --global branch.autosetuprebase always -Fred -Message d'origine- From: Frédéric THOMAS Sent: Tuesday, March 19, 2013 4:56 PM To: dev@flex.apache.org (mailto:dev@flex.apache.org) Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop The first link says exactly what I'm saying, you want to put your changes on top of what everybody else has done. 'So git rebase is not wrong. But it's right only if it's YOUR VERY OWN PRIVATE git tree.' When you do a pull --rebase, you're rebasing only your commits on the top of the others commits, nothing before the origin/HEAD indeed. The 2nd and especially the 3rd links tell as well what I'm saying, they do a final merge because there are on branches, in between they rebase their own commits: clone the remote repo git checkout -b my_new_feature ..work and commit some stuff git rebase master ..work and commit some stuff git rebase master ..finish the feature git checkout master git merge --squash my_new_feature git branch -D my_new_feature The 4th link: Reason #1: Resolve conflicts once, instead of once for each commit This case is rare but easy to resolve, you abort your rebase on multi commits conflicts and to simplify your life, exceptionnaly, you do what he says, you do a merge, messing the history though. Reason #2: With rebase, there is no undo! Doesn't apply, because, you will never rebase your feature branch on the develop one but merge it and if you work directly on the develop branch, you will push a few of rebased commits which are yours. And I'm tired now, I haven't read the last one. -Fred -Message d'origine- From: Justin Mclean Sent: Tuesday, March 19, 2013 4:20 PM To: dev@flex.apache.org (mailto:dev@flex.apache.org) Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hi, NO, that's the opposite Really? https://wincent.com/wiki/git_rebase:_you're_doing_it_wrong Dozen of stack overflow question on the issue which warn about rebasing. For instance: http://stackoverflow.com/questions/8939977/git-push-rejected-after-feature-branch-rebase Rebase and a shared repository generally do not get along. This is rewriting history. If others are using that branch or have branched from that branch then rebase will be quite unpleasant. http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions It really kills me that people are recommending a rebase workflow as a better alternative to a merge workflow for conflict resolution With rebase, there is no undo! Also http://git-scm.com/book/en/Git-Branching-Rebasing#The-Perils-of-Rebasing Again I'll ask do we really want this option to be the default? Justin
RE: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
I'm just hoping for mostly agreed upon way of doing business... So if I was starting from scratch to create a patch for a JIRA issue I would then do something like... 1) Clone Flex-SDK; the whole thing (creates local from remote apache servers) 2) Checkout the develop branch from the new local clone. (local) 3) Create a new feature branch (local) 4) Update required files in feature branch (local) 5) Commit changes for feature branch(local) 6) Run a diff to create a patch off of the feature branch. (local) 7) Merge the changes from the feature branch back in develop branch(local) Is this correct so far? I mean minus what to name feature branches or special commands to modify history / timelines. -Mark -Original Message- From: Erik de Bruin [mailto:e...@ixsoftware.nl] Sent: Tuesday, March 19, 2013 12:35 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop And now it's really time to explain this to - or rather: prescribe this for - us mere mortals. I think a couple of simple use cases with the exact steps/commands on the wiki (checkout, commit, push, pull) should be an excellent start. Time for some of the other very vocal git proponents to step up and actually help out? EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl (http://www.ixsoftware.nl)
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Hi, This document is perfect, the maybe only little point it didn't cover in Keeping the feature branch up to date is the possibility interactively rebase your commit, which allows in case of too much conflicts, to abord it, reset --hard and pull (fecth/merge). Thanks for sharing, -Fred -Message d'origine- From: Dasa Paddock Sent: Tuesday, March 19, 2013 6:57 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop This is the best explanation of when to merge vs. rebase that I've seen: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ There's also now a public beta of SourceTree for Windows available: http://blog.sourcetreeapp.com/2013/03/19/introducing-sourcetree-for-windows-a-free-desktop-client-for-git/ In regards to these unwanted merges, I've seen GitHub for Windows do this automatically instead of giving an error when you click it's Sync button and your local develop branch has commits that have not been pushed yet but the remote also also has commits that are not yet on the local develop branch. --Dasa
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
This is the best explanation of when to merge vs. rebase that I've seen: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ Added as comment to the wiki -Fred -Message d'origine- From: Frédéric THOMAS Sent: Tuesday, March 19, 2013 7:23 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hi, This document is perfect, the maybe only little point it didn't cover in Keeping the feature branch up to date is the possibility interactively rebase your commit, which allows in case of too much conflicts, to abord it, reset --hard and pull (fecth/merge). Thanks for sharing, -Fred -Message d'origine- From: Dasa Paddock Sent: Tuesday, March 19, 2013 6:57 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop This is the best explanation of when to merge vs. rebase that I've seen: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ There's also now a public beta of SourceTree for Windows available: http://blog.sourcetreeapp.com/2013/03/19/introducing-sourcetree-for-windows-a-free-desktop-client-for-git/ In regards to these unwanted merges, I've seen GitHub for Windows do this automatically instead of giving an error when you click it's Sync button and your local develop branch has commits that have not been pushed yet but the remote also also has commits that are not yet on the local develop branch. --Dasa
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Here's one way to avoid having git pull create a merge commit on your develop branch. Checkout your develop branch and then run: $ git pull --ff-only If this give you an error it means you have commits on your develop branch that are ahead of the remote develop branch. So then, run: $ git rebase --preserve-merges origin/develop This will rebase your commits on your local develop branch onto the remote develop branch. (Use -p for short.) You could use git pull --rebase instead but this does not preserve merge commits, which is what I commonly have following the git flow workflow. For more info on this, see: http://notes.envato.com/developers/rebasing-merge-commits-in-git/ --Dasa On Mar 19, 2013, at 11:39 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: This is the best explanation of when to merge vs. rebase that I've seen: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ Added as comment to the wiki -Fred -Message d'origine- From: Frédéric THOMAS Sent: Tuesday, March 19, 2013 7:23 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop Hi, This document is perfect, the maybe only little point it didn't cover in Keeping the feature branch up to date is the possibility interactively rebase your commit, which allows in case of too much conflicts, to abord it, reset --hard and pull (fecth/merge). Thanks for sharing, -Fred -Message d'origine- From: Dasa Paddock Sent: Tuesday, March 19, 2013 6:57 PM To: dev@flex.apache.org Subject: Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop This is the best explanation of when to merge vs. rebase that I've seen: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ There's also now a public beta of SourceTree for Windows available: http://blog.sourcetreeapp.com/2013/03/19/introducing-sourcetree-for-windows-a-free-desktop-client-for-git/ In regards to these unwanted merges, I've seen GitHub for Windows do this automatically instead of giving an error when you click it's Sync button and your local develop branch has commits that have not been pushed yet but the remote also also has commits that are not yet on the local develop branch. --Dasa
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Hi, I find it interesting that you apparently can't use Git well without appending all sorts of obscure switches such as --ff-only, --preserve-merges, and --rebase to your commands. And everyone seems to have a slightly different opinion on which one to use :-) If you don;t use the command line how do you know the tool you are using is doing the right thing? Justin
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Hi, What I'm hoping to see is more task-based and Flex/Apache/NVIE oriented step-by-steps. +100 to this. Justin
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
I used a test git repo to experiment with different scenarios by first going through this tutorial: http://try.github.com You could of course skip the tutorial and just create a test git repo directly at github.com --Dasa On Mar 19, 2013, at 2:30 PM, Justin Mclean jus...@classsoftware.com wrote: If you don;t use the command line how do you know the tool you are using is doing the right thing?
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Hi, I used a test git repo to experiment with different scenarios by first going through this tutorial: http://try.github.com You could of course skip the tutorial and just create a test git repo directly at github.com I think most of us are aware and can use the basic git commands. I don't think that's the issue. What seems to be the issues is that's rules about which (possibly obscure) options we should be using and what is missing is this discussion is how they apply to our project, what happens if you don't use them and how to get out of trouble when things go wrong. For instance why did my commit email the list about a merge in my local develop branch (to README) that no one should care about? Have we just got the email change messages configured incorrectly or are messages about local merges useful to everyone in some way? If you use rebase as far as I can see there no command to undo what you done if you make a mistake. How can we make it safer to use for people new to git? Do we really want to encourage new Git users to use rebase globally when there seems to be a lot of information out there saying this can be dangerous. How do we mark up JIRA tickets to indicate what changes have been made? How do we work out what changes have been applied to a branch? How do we work out what changes have gone into a release? Also a lot of the Git advice out make certain assumptions (ie you work all the time in master) so may be confusing to new people as our setup is slightly different. Thanks, Justin
Re: [3/3] git commit: Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
I'll take a shot at these :) On Mar 19, 2013, at 4:04 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, I used a test git repo to experiment with different scenarios by first going through this tutorial: http://try.github.com You could of course skip the tutorial and just create a test git repo directly at github.com I think most of us are aware and can use the basic git commands. I don't think that's the issue. What seems to be the issues is that's rules about which (possibly obscure) options we should be using and what is missing is this discussion is how they apply to our project, what happens if you don't use them and how to get out of trouble when things go wrong. For instance why did my commit email the list about a merge in my local develop branch (to README) that no one should care about? Have we just got the email change messages configured incorrectly or are messages about local merges useful to everyone in some way? [DP] - I think you did a pull and had local commits on your develop branch and there were commits on the remote so it had to create a merge commit on your develop branch to bring them together. This could have been avoided using git pull --rebase or see my earlier email. If you use rebase as far as I can see there no command to undo what you done if you make a mistake. How can we make it safer to use for people new to git? [DP] - The only option I know of is to copy the whole repo directory on your disk and then restore it if rebase goes wrong for you. Do we really want to encourage new Git users to use rebase globally when there seems to be a lot of information out there saying this can be dangerous. [DP] - I don't think so. See: http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ How do we mark up JIRA tickets to indicate what changes have been made? [DP] - I think there was a thread where this was being worked on. How do we work out what changes have been applied to a branch? [DP] - You can use various tools to see the log of commits. How do we work out what changes have gone into a release? [DP] - following the git flow workflow, you'd just need to see the changes made in the merge commit from the release branch to the master branch. See Finishing a release branch at: http://nvie.com/posts/a-successful-git-branching-model/ Also a lot of the Git advice out make certain assumptions (ie you work all the time in master) so may be confusing to new people as our setup is slightly different. Thanks, Justin
