Re: [E-devel] Git, merges, and better work-flows
But that will create a remote branch which is not needed for others. Or I can delete the remote branch after merging to master. Is that ok? Daniel Juyung Seo (SeoZ) On Sun, Oct 6, 2013 at 12:36 AM, Tom Hacohen t...@stosb.com wrote: Well. There's a way to avoid that: If you push to a remote branch before merging, there will be no tsunami. A mail will only be sent to the merge commit. On Sat, Oct 5, 2013 at 4:05 PM, Daniel Juyung Seo seojuyu...@gmail.com wrote: I thought the same as David Seikel :) That's why the commit tsunami happened. Anyhow, it's same as before except we now allow merge commit for some cases. Daniel Juyung Seo (SeoZ) On Sat, Oct 5, 2013 at 8:09 PM, Tom Hacohen t...@stosb.com wrote: No. The point is not to squash them, but have one cover-letter commit that holds them all. If you git log --first-parent you won't see all the commits, just the merge commit that describes the whole changeset. On Sat, Oct 5, 2013 at 10:36 AM, David Seikel onef...@gmail.com wrote: On Sat, 5 Oct 2013 17:58:17 +0900 Daniel Juyung Seo seojuyu...@gmail.com wrote: On Fri, Oct 4, 2013 at 11:48 PM, Tom Hacohen tom.haco...@samsung.comwrote: On 04/10/13 15:40, Michael Blumenkrantz wrote: On Fri, 04 Oct 2013 15:18:46 +0100 Tom Hacohen tom.haco...@samsung.com wrote: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel So, is this a go? May I write up some
Re: [E-devel] Git, merges, and better work-flows
Yeah, you can delete the remote branch after merging to master. The trick here is that we don't send emails about commits in dev branches and we don't send emails about commits that were merged into master from a dev branch (that is, commits that have already existed in the repo at the time of the push). Pushing to a dev branch first will thus prevent the emails from being sent. -- Tom. On Sun, Oct 6, 2013 at 5:09 PM, Daniel Juyung Seo seojuyu...@gmail.comwrote: But that will create a remote branch which is not needed for others. Or I can delete the remote branch after merging to master. Is that ok? Daniel Juyung Seo (SeoZ) On Sun, Oct 6, 2013 at 12:36 AM, Tom Hacohen t...@stosb.com wrote: Well. There's a way to avoid that: If you push to a remote branch before merging, there will be no tsunami. A mail will only be sent to the merge commit. On Sat, Oct 5, 2013 at 4:05 PM, Daniel Juyung Seo seojuyu...@gmail.com wrote: I thought the same as David Seikel :) That's why the commit tsunami happened. Anyhow, it's same as before except we now allow merge commit for some cases. Daniel Juyung Seo (SeoZ) On Sat, Oct 5, 2013 at 8:09 PM, Tom Hacohen t...@stosb.com wrote: No. The point is not to squash them, but have one cover-letter commit that holds them all. If you git log --first-parent you won't see all the commits, just the merge commit that describes the whole changeset. On Sat, Oct 5, 2013 at 10:36 AM, David Seikel onef...@gmail.com wrote: On Sat, 5 Oct 2013 17:58:17 +0900 Daniel Juyung Seo seojuyu...@gmail.com wrote: On Fri, Oct 4, 2013 at 11:48 PM, Tom Hacohen tom.haco...@samsung.comwrote: On 04/10/13 15:40, Michael Blumenkrantz wrote: On Fri, 04 Oct 2013 15:18:46 +0100 Tom Hacohen tom.haco...@samsung.com wrote: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help
Re: [E-devel] Git, merges, and better work-flows
On 2013-10-06 23:47, Tom Hacohen wrote: Yeah, you can delete the remote branch after merging to master. The trick here is that we don't send emails about commits in dev branches and we don't send emails about commits that were merged into master from a dev branch (that is, commits that have already existed in the repo at the time of the push). Pushing to a dev branch first will thus prevent the emails from being sent. Maybe this trick is handled by the multi mail hook, but post-receive will be constructed that way : #1 push to own branch LAST COMMIT SHA1 refs/heads/dev/XX/YY #2 push the merge to master common ancestor MERGE SHA1 refs/heads/master So in the case of original seojuyung2 00141eb19a879c64d24e773d0dec6e6440ad6c51 refs/heads/dev/seojuyung2/YY d9e81284369edad30f9225d86f1959c6901e87d8 ad8a00cf343786497f12ef6efc1c1de38d363196 refs/heads/master The second is still 60 commit difference, so I'm not so sure there will be no mail storm again. This will not happen is case multimail hook save somewhere what sha1 have already been announced, but I don't believe it's the case atm. beber On Sun, Oct 6, 2013 at 5:09 PM, Daniel Juyung Seo seojuyu...@gmail.comwrote: But that will create a remote branch which is not needed for others. Or I can delete the remote branch after merging to master. Is that ok? Daniel Juyung Seo (SeoZ) On Sun, Oct 6, 2013 at 12:36 AM, Tom Hacohen t...@stosb.com wrote: Well. There's a way to avoid that: If you push to a remote branch before merging, there will be no tsunami. A mail will only be sent to the merge commit. On Sat, Oct 5, 2013 at 4:05 PM, Daniel Juyung Seo seojuyu...@gmail.com wrote: I thought the same as David Seikel :) That's why the commit tsunami happened. Anyhow, it's same as before except we now allow merge commit for some cases. Daniel Juyung Seo (SeoZ) On Sat, Oct 5, 2013 at 8:09 PM, Tom Hacohen t...@stosb.com wrote: No. The point is not to squash them, but have one cover-letter commit that holds them all. If you git log --first-parent you won't see all the commits, just the merge commit that describes the whole changeset. On Sat, Oct 5, 2013 at 10:36 AM, David Seikel onef...@gmail.com wrote: On Sat, 5 Oct 2013 17:58:17 +0900 Daniel Juyung Seo seojuyu...@gmail.com wrote: On Fri, Oct 4, 2013 at 11:48 PM, Tom Hacohen tom.haco...@samsung.comwrote: On 04/10/13 15:40, Michael Blumenkrantz wrote: On Fri, 04 Oct 2013 15:18:46 +0100 Tom Hacohen tom.haco...@samsung.com wrote: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced
Re: [E-devel] Git, merges, and better work-flows
On Fri, Oct 4, 2013 at 11:48 PM, Tom Hacohen tom.haco...@samsung.comwrote: On 04/10/13 15:40, Michael Blumenkrantz wrote: On Fri, 04 Oct 2013 15:18:46 +0100 Tom Hacohen tom.haco...@samsung.com wrote: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel So, is this a go? May I write up some documentation about it and start doing it? -- Tom. I think you probably could have started documenting it at any point to help those who are interested. I already documented enough to explain the idea, and a more detailed explanation is available at the link Peter gave. I will only format it and actually put it in our documentation if actually agreed upon. Would be a waste of time otherwise. Well, your explanation in your first email was quite enough for me. I just made a merge branch commit what you described above. https://git.enlightenment.org/core/elementary.git/commit/?id=ad8a00cf343786497f12ef6efc1c1de38d363196 It was quite easy and clear to me. Thanks for the suggestion. Daniel Juyung Seo (SeoZ) -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See
Re: [E-devel] Git, merges, and better work-flows
On Sat, 5 Oct 2013 17:58:17 +0900 Daniel Juyung Seo seojuyu...@gmail.com wrote: On Fri, Oct 4, 2013 at 11:48 PM, Tom Hacohen tom.haco...@samsung.comwrote: On 04/10/13 15:40, Michael Blumenkrantz wrote: On Fri, 04 Oct 2013 15:18:46 +0100 Tom Hacohen tom.haco...@samsung.com wrote: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel So, is this a go? May I write up some documentation about it and start doing it? -- Tom. I think you probably could have started documenting it at any point to help those who are interested. I already documented enough to explain the idea, and a more detailed explanation is available at the link Peter gave. I will only format it and actually put it in our documentation if actually agreed upon. Would be a waste of time otherwise. Well, your explanation in your first email was quite enough for me. I just made a merge branch commit what you described above. https://git.enlightenment.org/core/elementary.git/commit/?id=ad8a00cf343786497f12ef6efc1c1de38d363196 It was quite easy and clear to me. Thanks for the suggestion. I thought the object of this exercise was to squash them down to a single commit? So why was there dozens of commit emails? -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___
Re: [E-devel] Git, merges, and better work-flows
No. The point is not to squash them, but have one cover-letter commit that holds them all. If you git log --first-parent you won't see all the commits, just the merge commit that describes the whole changeset. On Sat, Oct 5, 2013 at 10:36 AM, David Seikel onef...@gmail.com wrote: On Sat, 5 Oct 2013 17:58:17 +0900 Daniel Juyung Seo seojuyu...@gmail.com wrote: On Fri, Oct 4, 2013 at 11:48 PM, Tom Hacohen tom.haco...@samsung.comwrote: On 04/10/13 15:40, Michael Blumenkrantz wrote: On Fri, 04 Oct 2013 15:18:46 +0100 Tom Hacohen tom.haco...@samsung.com wrote: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel So, is this a go? May I write up some documentation about it and start doing it? -- Tom. I think you probably could have started documenting it at any point to help those who are interested. I already documented enough to explain the idea, and a more detailed explanation is available at the link Peter gave. I will only format it and actually put it in our documentation if actually agreed upon. Would be a waste of time otherwise. Well, your explanation in your first email was quite enough for me. I just made a merge branch commit what you described above. https://git.enlightenment.org/core/elementary.git/commit/?id=ad8a00cf343786497f12ef6efc1c1de38d363196 It was quite easy and clear to me. Thanks for the suggestion. I thought the object of this exercise was to squash them down to a single commit? So why was there dozens of commit emails? -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- October
Re: [E-devel] Git, merges, and better work-flows
Exactly. Awesome. :) On Sat, Oct 5, 2013 at 9:58 AM, Daniel Juyung Seo seojuyu...@gmail.comwrote: On Fri, Oct 4, 2013 at 11:48 PM, Tom Hacohen tom.haco...@samsung.com wrote: On 04/10/13 15:40, Michael Blumenkrantz wrote: On Fri, 04 Oct 2013 15:18:46 +0100 Tom Hacohen tom.haco...@samsung.com wrote: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel So, is this a go? May I write up some documentation about it and start doing it? -- Tom. I think you probably could have started documenting it at any point to help those who are interested. I already documented enough to explain the idea, and a more detailed explanation is available at the link Peter gave. I will only format it and actually put it in our documentation if actually agreed upon. Would be a waste of time otherwise. Well, your explanation in your first email was quite enough for me. I just made a merge branch commit what you described above. https://git.enlightenment.org/core/elementary.git/commit/?id=ad8a00cf343786497f12ef6efc1c1de38d363196 It was quite easy and clear to me. Thanks for the suggestion. Daniel Juyung Seo (SeoZ) -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
I thought the same as David Seikel :) That's why the commit tsunami happened. Anyhow, it's same as before except we now allow merge commit for some cases. Daniel Juyung Seo (SeoZ) On Sat, Oct 5, 2013 at 8:09 PM, Tom Hacohen t...@stosb.com wrote: No. The point is not to squash them, but have one cover-letter commit that holds them all. If you git log --first-parent you won't see all the commits, just the merge commit that describes the whole changeset. On Sat, Oct 5, 2013 at 10:36 AM, David Seikel onef...@gmail.com wrote: On Sat, 5 Oct 2013 17:58:17 +0900 Daniel Juyung Seo seojuyu...@gmail.com wrote: On Fri, Oct 4, 2013 at 11:48 PM, Tom Hacohen tom.haco...@samsung.comwrote: On 04/10/13 15:40, Michael Blumenkrantz wrote: On Fri, 04 Oct 2013 15:18:46 +0100 Tom Hacohen tom.haco...@samsung.com wrote: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel So, is this a go? May I write up some documentation about it and start doing it? -- Tom. I think you probably could have started documenting it at any point to help those who are interested. I already documented enough to explain the idea, and a more detailed explanation is available at the link Peter gave. I will only format it and actually put it in our documentation if actually agreed upon. Would be a waste of time otherwise. Well, your explanation in your first email was quite enough for me. I just made a merge branch commit what you described above. https://git.enlightenment.org/core/elementary.git/commit/?id=ad8a00cf343786497f12ef6efc1c1de38d363196 It was quite easy and
Re: [E-devel] Git, merges, and better work-flows
*about the merge commit. On Sat, Oct 5, 2013 at 4:36 PM, Tom Hacohen t...@stosb.com wrote: Well. There's a way to avoid that: If you push to a remote branch before merging, there will be no tsunami. A mail will only be sent to the merge commit. On Sat, Oct 5, 2013 at 4:05 PM, Daniel Juyung Seo seojuyu...@gmail.comwrote: I thought the same as David Seikel :) That's why the commit tsunami happened. Anyhow, it's same as before except we now allow merge commit for some cases. Daniel Juyung Seo (SeoZ) On Sat, Oct 5, 2013 at 8:09 PM, Tom Hacohen t...@stosb.com wrote: No. The point is not to squash them, but have one cover-letter commit that holds them all. If you git log --first-parent you won't see all the commits, just the merge commit that describes the whole changeset. On Sat, Oct 5, 2013 at 10:36 AM, David Seikel onef...@gmail.com wrote: On Sat, 5 Oct 2013 17:58:17 +0900 Daniel Juyung Seo seojuyu...@gmail.com wrote: On Fri, Oct 4, 2013 at 11:48 PM, Tom Hacohen tom.haco...@samsung.comwrote: On 04/10/13 15:40, Michael Blumenkrantz wrote: On Fri, 04 Oct 2013 15:18:46 +0100 Tom Hacohen tom.haco...@samsung.com wrote: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel So, is this a go? May I write up some documentation about it and start doing it? -- Tom. I think you probably could have started documenting it at any point to help those who are interested. I already documented enough to explain the idea, and a more
Re: [E-devel] Git, merges, and better work-flows
Well. There's a way to avoid that: If you push to a remote branch before merging, there will be no tsunami. A mail will only be sent to the merge commit. On Sat, Oct 5, 2013 at 4:05 PM, Daniel Juyung Seo seojuyu...@gmail.comwrote: I thought the same as David Seikel :) That's why the commit tsunami happened. Anyhow, it's same as before except we now allow merge commit for some cases. Daniel Juyung Seo (SeoZ) On Sat, Oct 5, 2013 at 8:09 PM, Tom Hacohen t...@stosb.com wrote: No. The point is not to squash them, but have one cover-letter commit that holds them all. If you git log --first-parent you won't see all the commits, just the merge commit that describes the whole changeset. On Sat, Oct 5, 2013 at 10:36 AM, David Seikel onef...@gmail.com wrote: On Sat, 5 Oct 2013 17:58:17 +0900 Daniel Juyung Seo seojuyu...@gmail.com wrote: On Fri, Oct 4, 2013 at 11:48 PM, Tom Hacohen tom.haco...@samsung.comwrote: On 04/10/13 15:40, Michael Blumenkrantz wrote: On Fri, 04 Oct 2013 15:18:46 +0100 Tom Hacohen tom.haco...@samsung.com wrote: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel So, is this a go? May I write up some documentation about it and start doing it? -- Tom. I think you probably could have started documenting it at any point to help those who are interested. I already documented enough to explain the idea, and a more detailed explanation is available at the link Peter gave. I will only format it and actually
Re: [E-devel] Git, merges, and better work-flows
steps 3, 4, 5, 6, 8... are an incantation. to be done in that order. there is --no-ff... and he series.. its a DEFINITE incantation. read up on git as a leaky abstraction. it is very much one. it forces peole to learn a series of incantations/steps all the time as opposed to just having a single do X where X is always the same series of steps. why do it by hand. why have to LEARN by heart and then of course get it wrong at times Officially, raster is now a high level manager ! Theses incantation are quite straight forward when you use git daily. Not at the first use, but become fast essential. My 2 cents -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On Fri, 04 Oct 2013 11:42:35 +0200 Bertrand Jacquin be...@meleeweb.net said: steps 3, 4, 5, 6, 8... are an incantation. to be done in that order. there is --no-ff... and he series.. its a DEFINITE incantation. read up on git as a leaky abstraction. it is very much one. it forces peole to learn a series of incantations/steps all the time as opposed to just having a single do X where X is always the same series of steps. why do it by hand. why have to LEARN by heart and then of course get it wrong at times Officially, raster is now a high level manager ! Theses incantation are quite straight forward when you use git daily. Not at the first use, but become fast essential. i use git every day.. but i dont go making private branches and merging them. even then, take a look at my aliases and scripts dir. i fail to understand how many people survive doing everything manually by hand. i see it all around me. they do the full command like: ps -ef | grep X when i do: psg X why? i get tired of memorizing N steps or magic incantations. i do NOT do: ./autogen.sh make sudo make install i do: cmi i never do: make sudo make install i do: mi why? i can't stand having to memorize a tonneof obscure incantations that make little sense outside of the leaky abstraction that is git: http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ https://news.ycombinator.com/item?id=3891598 you may love doing it all by hand and find great pleasure in twisting your brain to work and think like gits internals do, but i do not. i want to perform a simple task and git turns it into a job of remembering a magic incantation. i keep now having to build scripts that wrap git stuff up so i dont have to do N steps and maybe forget one. the same people who say omg git is so awesome! it has git bisect! svn sucks! it is the worst thing. it doesnt have bisect have a set of standards that think doing other SIMPLE stuff that svn does in a single cmd is ok to break into a dozen steps in git with a bunch of cmdline opts u have to keep looking up, and if in svn i had to write a small script to do a bisect (which was perfectly possible too) then svn insta-sucks. but having to wrap up git or memorize a vast series of steps for everything u need to do in git is perfectly fine and great! git is a poor tool. it's interface is poor. it does some cool stuff - but as a tool it is poor. if you want people to follow conventions/procedures, don't make them have to read your powerpoint on them and study them and memorize the document/process. (and the people here know what i'm referring to). make the TOOL doe the thing for you obviously and simply. for git that would normally mean patching it (not as easy), but a simple wrapper does the job. don't define a document to describe a process - encapsulate it in a simple tool (script). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel So, is this a go? May I write up some documentation about it and start doing it? -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On Fri, 04 Oct 2013 15:18:46 +0100 Tom Hacohen tom.haco...@samsung.com wrote: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel So, is this a go? May I write up some documentation about it and start doing it? -- Tom. I think you probably could have started documenting it at any point to help those who are interested. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On 04/10/13 15:40, Michael Blumenkrantz wrote: On Fri, 04 Oct 2013 15:18:46 +0100 Tom Hacohen tom.haco...@samsung.com wrote: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel So, is this a go? May I write up some documentation about it and start doing it? -- Tom. I think you probably could have started documenting it at any point to help those who are interested. I already documented enough to explain the idea, and a more detailed explanation is available at the link Peter gave. I will only format it and actually put it in our documentation if actually agreed upon. Would be a waste of time otherwise. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On Friday 04 October 2013 15:18, Tom Hacohen wrote : So, is this a go? May I write up some documentation about it and start doing it? -- Tom. for me it's a +1 go in case that's part of your plan, I've added an 'eo2: ' prefix to the commits in devs/jeyzu/eo2-old. I can still fix the committer name to be the same as author -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On 04/10/13 16:05, Jérémy Zurcher wrote: On Friday 04 October 2013 15:18, Tom Hacohen wrote : So, is this a go? May I write up some documentation about it and start doing it? -- Tom. for me it's a +1 go in case that's part of your plan, I've added an 'eo2: ' prefix to the commits in devs/jeyzu/eo2-old. I can still fix the committer name to be the same as author Committer name != Author name. Both should be correct according to the reality. :) Yes, I do plan on using it for eo2 (among other things). -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On Friday 04 October 2013 15:59, Tom Hacohen wrote : On 04/10/13 16:05, Jérémy Zurcher wrote: On Friday 04 October 2013 15:18, Tom Hacohen wrote : So, is this a go? May I write up some documentation about it and start doing it? -- Tom. for me it's a +1 go in case that's part of your plan, I've added an 'eo2: ' prefix to the commits in devs/jeyzu/eo2-old. I can still fix the committer name to be the same as author Committer name != Author name. Both should be correct according to the reality. :) what is the reality? Cedric and you committed patches in eo2, but I'm the only committer in eo2-old, I don't know Yes, I do plan on using it for eo2 (among other things). -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel --- Hell'O from Yverdoom Jérémy (jeyzu) -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On Fri, Oct 4, 2013 at 7:05 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 04 Oct 2013 11:42:35 +0200 Bertrand Jacquin be...@meleeweb.net said: steps 3, 4, 5, 6, 8... are an incantation. to be done in that order. there is --no-ff... and he series.. its a DEFINITE incantation. read up on git as a leaky abstraction. it is very much one. it forces peole to learn a series of incantations/steps all the time as opposed to just having a single do X where X is always the same series of steps. why do it by hand. why have to LEARN by heart and then of course get it wrong at times Officially, raster is now a high level manager ! Theses incantation are quite straight forward when you use git daily. Not at the first use, but become fast essential. i use git every day.. but i dont go making private branches and merging them. even then, take a look at my aliases and scripts dir. i fail to understand how many people survive doing everything manually by hand. i see it all around me. they do the full command like: ps -ef | grep X when i do: psg X why? i get tired of memorizing N steps or magic incantations. i do NOT do: ./autogen.sh make sudo make install i do: cmi i never do: make sudo make install i do: mi why not use names like a, b, c, d, e...? I guess it would be easier for you to remember all the aliases. why? i can't stand having to memorize a tonneof obscure incantations that make little sense outside of the leaky abstraction that is git: http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ https://news.ycombinator.com/item?id=3891598 you may love doing it all by hand and find great pleasure in twisting your brain to work and think like gits internals do, but i do not. i want to perform a simple task and git turns it into a job of remembering a magic incantation. i keep now having to build scripts that wrap git stuff up so i dont have to do N steps and maybe forget one. the same people who say omg git is so awesome! it has git bisect! svn sucks! it is the worst thing. it doesnt have bisect have a set of standards that think doing other SIMPLE stuff that svn does in a single cmd is ok to break into a dozen steps in git with a bunch of cmdline opts u have to keep looking up, and if in svn i had to write a small script to do a bisect (which was perfectly possible too) then svn insta-sucks. but having to wrap up git or memorize a vast series of steps for everything u need to do in git is perfectly fine and great! git is a poor tool. it's interface is poor. it does some cool stuff - but as a tool it is poor. if you want people to follow conventions/procedures, don't make them have to read your powerpoint on them and study them and memorize the document/process. (and the people here know what i'm referring to). make the TOOL doe the thing for you obviously and simply. for git that would normally mean patching it (not as easy), but a simple wrapper does the job. don't define a document to describe a process - encapsulate it in a simple tool (script). I was going to reply, but then the complaints became too entertaining. Instead acidx gave me this link that I'd like to share: http://usvsth3m.co.uk/javascript-under-pressure/torvalds.gif Lucas De Marchi -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On Fri, 4 Oct 2013 15:57:52 -0300 Lucas De Marchi lucas.demar...@profusion.mobi said: On Fri, Oct 4, 2013 at 7:05 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 04 Oct 2013 11:42:35 +0200 Bertrand Jacquin be...@meleeweb.net said: steps 3, 4, 5, 6, 8... are an incantation. to be done in that order. there is --no-ff... and he series.. its a DEFINITE incantation. read up on git as a leaky abstraction. it is very much one. it forces peole to learn a series of incantations/steps all the time as opposed to just having a single do X where X is always the same series of steps. why do it by hand. why have to LEARN by heart and then of course get it wrong at times Officially, raster is now a high level manager ! Theses incantation are quite straight forward when you use git daily. Not at the first use, but become fast essential. i use git every day.. but i dont go making private branches and merging them. even then, take a look at my aliases and scripts dir. i fail to understand how many people survive doing everything manually by hand. i see it all around me. they do the full command like: ps -ef | grep X when i do: psg X why? i get tired of memorizing N steps or magic incantations. i do NOT do: ./autogen.sh make sudo make install i do: cmi i never do: make sudo make install i do: mi why not use names like a, b, c, d, e...? I guess it would be easier for you to remember all the aliases. thats just silly. mi == Make Install. cmi == Configure Make Install. see my original mail. i didnt say make it gb or x. just dont ask people to memorize a series of 5, 6, 7 etc. steps each with a different git command and incantation with attendant option if you want anyone to do things this way. why? i can't stand having to memorize a tonneof obscure incantations that make little sense outside of the leaky abstraction that is git: http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ https://news.ycombinator.com/item?id=3891598 you may love doing it all by hand and find great pleasure in twisting your brain to work and think like gits internals do, but i do not. i want to perform a simple task and git turns it into a job of remembering a magic incantation. i keep now having to build scripts that wrap git stuff up so i dont have to do N steps and maybe forget one. the same people who say omg git is so awesome! it has git bisect! svn sucks! it is the worst thing. it doesnt have bisect have a set of standards that think doing other SIMPLE stuff that svn does in a single cmd is ok to break into a dozen steps in git with a bunch of cmdline opts u have to keep looking up, and if in svn i had to write a small script to do a bisect (which was perfectly possible too) then svn insta-sucks. but having to wrap up git or memorize a vast series of steps for everything u need to do in git is perfectly fine and great! git is a poor tool. it's interface is poor. it does some cool stuff - but as a tool it is poor. if you want people to follow conventions/procedures, don't make them have to read your powerpoint on them and study them and memorize the document/process. (and the people here know what i'm referring to). make the TOOL doe the thing for you obviously and simply. for git that would normally mean patching it (not as easy), but a simple wrapper does the job. don't define a document to describe a process - encapsulate it in a simple tool (script). I was going to reply, but then the complaints became too entertaining. Instead acidx gave me this link that I'd like to share: http://usvsth3m.co.uk/javascript-under-pressure/torvalds.gif i'm happy for you that you love to memorize everything you do instead of summarize and automate it. why use git? why not just calculate your diffs by hand? it's oh so much more cool. much cooler than the i love git and everything it does exactly as it is club is far less cool than i calculate my own diffs and toggle them in in binary via switches club. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On Sat, 5 Oct 2013 11:54:46 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Fri, 4 Oct 2013 15:57:52 -0300 Lucas De Marchi lucas.demar...@profusion.mobi said: On Fri, Oct 4, 2013 at 7:05 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 04 Oct 2013 11:42:35 +0200 Bertrand Jacquin be...@meleeweb.net said: steps 3, 4, 5, 6, 8... are an incantation. to be done in that order. there is --no-ff... and he series.. its a DEFINITE incantation. read up on git as a leaky abstraction. it is very much one. it forces peole to learn a series of incantations/steps all the time as opposed to just having a single do X where X is always the same series of steps. why do it by hand. why have to LEARN by heart and then of course get it wrong at times Officially, raster is now a high level manager ! Theses incantation are quite straight forward when you use git daily. Not at the first use, but become fast essential. i use git every day.. but i dont go making private branches and merging them. even then, take a look at my aliases and scripts dir. i fail to understand how many people survive doing everything manually by hand. i see it all around me. they do the full command like: ps -ef | grep X when i do: psg X why? i get tired of memorizing N steps or magic incantations. i do NOT do: ./autogen.sh make sudo make install i do: cmi i never do: make sudo make install i do: mi why not use names like a, b, c, d, e...? I guess it would be easier for you to remember all the aliases. thats just silly. mi == Make Install. cmi == Configure Make Install. see my original mail. i didnt say make it gb or x. just dont ask people to memorize a series of 5, 6, 7 etc. steps each with a different git command and incantation with attendant option if you want anyone to do things this way. why? i can't stand having to memorize a tonneof obscure incantations that make little sense outside of the leaky abstraction that is git: http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ https://news.ycombinator.com/item?id=3891598 you may love doing it all by hand and find great pleasure in twisting your brain to work and think like gits internals do, but i do not. i want to perform a simple task and git turns it into a job of remembering a magic incantation. i keep now having to build scripts that wrap git stuff up so i dont have to do N steps and maybe forget one. the same people who say omg git is so awesome! it has git bisect! svn sucks! it is the worst thing. it doesnt have bisect have a set of standards that think doing other SIMPLE stuff that svn does in a single cmd is ok to break into a dozen steps in git with a bunch of cmdline opts u have to keep looking up, and if in svn i had to write a small script to do a bisect (which was perfectly possible too) then svn insta-sucks. but having to wrap up git or memorize a vast series of steps for everything u need to do in git is perfectly fine and great! git is a poor tool. it's interface is poor. it does some cool stuff - but as a tool it is poor. if you want people to follow conventions/procedures, don't make them have to read your powerpoint on them and study them and memorize the document/process. (and the people here know what i'm referring to). make the TOOL doe the thing for you obviously and simply. for git that would normally mean patching it (not as easy), but a simple wrapper does the job. don't define a document to describe a process - encapsulate it in a simple tool (script). I was going to reply, but then the complaints became too entertaining. Instead acidx gave me this link that I'd like to share: http://usvsth3m.co.uk/javascript-under-pressure/torvalds.gif i'm happy for you that you love to memorize everything you do instead of summarize and automate it. why use git? why not just calculate your diffs by hand? it's oh so much more cool. much cooler than the i love git and everything it does exactly as it is club is far less cool than i calculate my own diffs and toggle them in in binary via switches club. I'm even cooler, being in the I write my diffs directly to my hard drive using a magnetised needle and a magnifying glass club. Actually I'm really short sighted, I can skip the magnifying glass bit. B-) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
Re: [E-devel] Git, merges, and better work-flows
-Original Message- From: Daniel Juyung Seo [mailto:seojuyu...@gmail.com] Sent: den 3 oktober 2013 06:55 To: Enlightenment developer list Subject: Re: [E-devel] Git, merges, and better work-flows On Thu, Oct 3, 2013 at 12:20 AM, Tom Hacohen tom.haco...@samsung.comwrote: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over- simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature- sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. Needless to say, that if agreed upon, I will add some documentation about how best to follow this work-flow. Just update https://phab.enlightenment.org/w/git_practices/ must be enough :) Daniel Juyung Seo (SeoZ) -- Tom. The branching model Tom describes is a personal favorite of mine. Here is a description of it with some dos and don'ts and other tips: https://gist.github.com/jbenet/ee6c9ac48068889b0912 //Peter -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On 03/10/13 08:48, Peter Kjellerstedt wrote: -Original Message- From: Daniel Juyung Seo [mailto:seojuyu...@gmail.com] Sent: den 3 oktober 2013 06:55 To: Enlightenment developer list Subject: Re: [E-devel] Git, merges, and better work-flows On Thu, Oct 3, 2013 at 12:20 AM, Tom Hacohen tom.haco...@samsung.comwrote: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over- simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature- sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. Needless to say, that if agreed upon, I will add some documentation about how best to follow this work-flow. Just update https://phab.enlightenment.org/w/git_practices/ must be enough :) Daniel Juyung Seo (SeoZ) -- Tom. The branching model Tom describes is a personal favorite of mine. Here is a description of it with some dos and don'ts and other tips: https://gist.github.com/jbenet/ee6c9ac48068889b0912 //Peter -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel THANK YOU. A very good link indeed. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On 03/10/13 03:55, Carsten Haitzler (The Rasterman) wrote: On Wed, 02 Oct 2013 16:20:38 +0100 Tom Hacohen tom.haco...@samsung.com said: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. Needless to say, that if agreed upon, I will add some documentation about how best to follow this work-flow. write some mini tools/scripts. not just docs. if any step in such a workflow involves knowing some magic git incantation and/or more than 1 step, then wrap it up. eg. gitfeature-start BRANCHNAME gitfeature-merge the first just creates the branch named BRANCHNAME (with any given namespace prepended ) and ensure you switch to it. the second does all the last steps (rebase over master, blah blah blah) and just executes the appropriate sequence of git cmds. As Lucas has said, it's pretty straight forward (and only one difference) compared to what most of us are used to. The only real difference is passing --no-ff instead of --rebase to git merge in my process. Anyhow, this is the process in git commands: Create a local branch for the feature (something I hope people do already): git checkout -b branch-name Work on your feature and commit. rebase over master: git fetch ; git rebase origin/master Switch to master and merge --no-ff instead of --rebase git checkout master ; git merge --no-ff branch-name And push: git push origin master The stages are similar and the same. Also, as I've mentioned, let's let people try using it (it's not mandatory) and wait for feedback. Also, please refer to the really good link Peter has posted to this thread: https://gist.github.com/jbenet/ee6c9ac48068889b0912 -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Git, merges, and better work-flows
Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. Needless to say, that if agreed upon, I will add some documentation about how best to follow this work-flow. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
-0 I'm not convinced but I don't have any evidence that it's bad, just a personal feeling. However I'm not an active committer, so I don't count much these days and I'll follow whatever you choose. On Wed, Oct 2, 2013 at 12:20 PM, Tom Hacohen tom.haco...@samsung.com wrote: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. Needless to say, that if agreed upon, I will add some documentation about how best to follow this work-flow. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Gustavo Sverzut Barbieri -- Mobile: +55 (19) 9225-2202 Contact: http://www.gustavobarbieri.com.br/contact -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On 02/10/13 17:51, Gustavo Sverzut Barbieri wrote: -0 I'm not convinced but I don't have any evidence that it's bad, just a personal feeling. However I'm not an active committer, so I don't count much these days and I'll follow whatever you choose. All I'm asking is the permission to do so (and recommend others to follow suit). At least for a test period. I wouldn't like to force anyone to do it. So you being an active committer doesn't really matter, because it affects viewers/reviewers, not committers. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
Hi, On Wed, Oct 02, 2013, Gustavo Sverzut Barbieri wrote: -0 I'm not convinced but I don't have any evidence that it's bad, just a personal feeling. All it does is add a commit that says branch X was merged in branch Y. There are two possible drawbacks: - commit message should be checked to contain meaningful branch names (you can end up with bad names if you use bad names in your local branches and expect these names to never be seen by the public) - one useless commit (some people actually don't like it) -- Adrien Nader -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On 02/10/13 18:12, Adrien Nader wrote: Hi, On Wed, Oct 02, 2013, Gustavo Sverzut Barbieri wrote: -0 I'm not convinced but I don't have any evidence that it's bad, just a personal feeling. All it does is add a commit that says branch X was merged in branch Y. There are two possible drawbacks: - commit message should be checked to contain meaningful branch names (you can end up with bad names if you use bad names in your local branches and expect these names to never be seen by the public) - one useless commit (some people actually don't like it) Well not really. By default it shows that message. I also find the default message useless. I use that commit as an opportunity to describe the feature as a whole. Look at my example: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/commit/?id=9f56f6a31762df8ae7f26e2481ea0032e1e90450 That's the merge commit. As for the one useless commit: I think that without it, we have 10 useless commits (the components making the feature), while with it, we have only 1 commit per change with the ability to look at more basic components of the commit. This makes review easier, and everything clear. As I mentioned above, if you use git log --first-only, you won't even see the commits involved in the feature. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
* Tom Hacohen tom.haco...@samsung.com [2013-10-02 17:58:45 +0100]: On 02/10/13 17:51, Gustavo Sverzut Barbieri wrote: -0 I'm not convinced but I don't have any evidence that it's bad, just a personal feeling. However I'm not an active committer, so I don't count much these days and I'll follow whatever you choose. All I'm asking is the permission to do so (and recommend others to follow suit). At least for a test period. I wouldn't like to force anyone to do it. So you being an active committer doesn't really matter, because it affects viewers/reviewers, not committers. It seems fancy, we could give it a try. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Gustavo Lima Chaves Senior Developer @ Intel - Open Source Technology Center -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On Wed, 02 Oct 2013 16:20:38 +0100 Tom Hacohen tom.haco...@samsung.com said: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. Needless to say, that if agreed upon, I will add some documentation about how best to follow this work-flow. write some mini tools/scripts. not just docs. if any step in such a workflow involves knowing some magic git incantation and/or more than 1 step, then wrap it up. eg. gitfeature-start BRANCHNAME gitfeature-merge the first just creates the branch named BRANCHNAME (with any given namespace prepended ) and ensure you switch to it. the second does all the last steps (rebase over master, blah blah blah) and just executes the appropriate sequence of git cmds. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On Wed, Oct 2, 2013 at 11:55 PM, Carsten Haitzler ras...@rasterman.com wrote: On Wed, 02 Oct 2013 16:20:38 +0100 Tom Hacohen tom.haco...@samsung.com said: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. I have no strong opinion. I have no problems with merges *when they are well defined*, i.e. it's either a feature that is properly split in multiple commits, or when there are people maintaining parts of the tree and periodically merge them (like in linux kernel). And in those cases even not being FF I think is ok. I'd say let's give it a try for those who want to. Needless to say, that if agreed upon, I will add some documentation about how best to follow this work-flow. write some mini tools/scripts. not just docs. if any step in such a workflow involves knowing some magic git incantation and/or more than 1 step, then wrap it up. eg. gitfeature-start BRANCHNAME gitfeature-merge humn... I don't think creating this beforehand makes any good. This invariably ends up with horribly big scripts and people not really understanding what's going on. In his description I don't see any git incantation... they are just the normal commands of every day. Lucas De Marchi -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On Thu, 3 Oct 2013 00:10:17 -0300 Lucas De Marchi lucas.demar...@profusion.mobi said: On Wed, Oct 2, 2013 at 11:55 PM, Carsten Haitzler ras...@rasterman.com wrote: On Wed, 02 Oct 2013 16:20:38 +0100 Tom Hacohen tom.haco...@samsung.com said: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. I have no strong opinion. I have no problems with merges *when they are well defined*, i.e. it's either a feature that is properly split in multiple commits, or when there are people maintaining parts of the tree and periodically merge them (like in linux kernel). And in those cases even not being FF I think is ok. I'd say let's give it a try for those who want to. Needless to say, that if agreed upon, I will add some documentation about how best to follow this work-flow. write some mini tools/scripts. not just docs. if any step in such a workflow involves knowing some magic git incantation and/or more than 1 step, then wrap it up. eg. gitfeature-start BRANCHNAME gitfeature-merge humn... I don't think creating this beforehand makes any good. This invariably ends up with horribly big scripts and people not really understanding what's going on. In his description I don't see any git incantation... they are just the normal commands of every day. steps 3, 4, 5, 6, 8... are an incantation. to be done in that order. there is --no-ff... and he series.. its a DEFINITE incantation. read up on git as a leaky abstraction. it is very much one. it forces peole to learn a series of incantations/steps all the time as opposed to just having a single do X where X is always the same series of steps. why do it by hand. why have to LEARN by heart and then of course get it wrong at times Lucas De Marchi -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com
Re: [E-devel] Git, merges, and better work-flows
On Thu, Oct 3, 2013 at 12:25 AM, Carsten Haitzler ras...@rasterman.com wrote: On Thu, 3 Oct 2013 00:10:17 -0300 Lucas De Marchi lucas.demar...@profusion.mobi said: On Wed, Oct 2, 2013 at 11:55 PM, Carsten Haitzler ras...@rasterman.com wrote: On Wed, 02 Oct 2013 16:20:38 +0100 Tom Hacohen tom.haco...@samsung.com said: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. I have no strong opinion. I have no problems with merges *when they are well defined*, i.e. it's either a feature that is properly split in multiple commits, or when there are people maintaining parts of the tree and periodically merge them (like in linux kernel). And in those cases even not being FF I think is ok. I'd say let's give it a try for those who want to. Needless to say, that if agreed upon, I will add some documentation about how best to follow this work-flow. write some mini tools/scripts. not just docs. if any step in such a workflow involves knowing some magic git incantation and/or more than 1 step, then wrap it up. eg. gitfeature-start BRANCHNAME gitfeature-merge humn... I don't think creating this beforehand makes any good. This invariably ends up with horribly big scripts and people not really understanding what's going on. In his description I don't see any git incantation... they are just the normal commands of every day. steps 3, 4, 5, 6, 8... are an incantation. to be done in that order. there is --no-ff... and he series.. its a DEFINITE incantation. read up on git as a leaky abstraction. it is very much one. it forces peole to learn a series of incantations/steps all the time as opposed to just having a single do X where X is always the same series of steps. why do it by hand. why have to LEARN by heart and then of course get it wrong at times because you won't get it wrong if you know what's going on. And if you still do then and only then is the time to wrap it up. Lucas De Marchi -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On Thu, Oct 3, 2013 at 12:20 AM, Tom Hacohen tom.haco...@samsung.comwrote: On 02/10/13 16:17, Tom Hacohen wrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. Needless to say, that if agreed upon, I will add some documentation about how best to follow this work-flow. Just update https://phab.enlightenment.org/w/git_practices/ must be enough :) Daniel Juyung Seo (SeoZ) -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
Thanks Tasn for the suggestion. I like the idea. It's been a while since we started Rebase instead of Merge policy and it worked well so far. Now it's time to enhance it more. Thanks. Daniel Juyung Seo (SeoZ) On Thu, Oct 3, 2013 at 12:17 AM, Tom Hacohen tom.haco...@samsung.comwrote: Hey guys, I would like to suggest a new work-flow. This work-flow will not be mandatory, but just an allowed alternative to the current commit to master approach. At the moment we do not allow merges, at all. This was to prevent people from littering the log with their inability to rebase (git pull --rebase) their local changes on top of the existing commits. This will still remain the same. I'd like to suggest using merges to our advantage. I suggest the following: For fixes, small features, and the like, do the same as you do now. Commit and push to master. For bigger features, rewrites, or any form of a few commits that are tied together by being part of the same set, do as follows (it's obviously simpler than that, I listed everything to over-simplify things): 1. Create a branch (either local or remote) for your change. 2. Work on that branch. 3. When ready, instead of pushing to master: 3. rebase over master (git fetch; git rebase origin/master). 4. switch to master (git checkout master) 6. git merge --no-ff your-feature-branch-name 7. Describe your feature in the commit message. 8. push to master (git push or git push origin master). I've done a few example commits on https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ This work-flow lets us have linear history, while having feature-sets show as a single merge that can easily be reverted, provide a good description about a feature and the commits that introduced it and I find generally easier for the eye. There are also technical advantages, for example, if you run git log --first-parent you will only see the merge commits, cleaning the log from all the fluff involving a feature letting you just see the feature. Another advantage is that git bisect will not go inside the merged branch unless the issue was introduced there. Please feel free to inspect my repo, more specifically, the log: https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ To see how it looks. Important note: commits on the merge branch should be treated as if they are on master, that is, don't use this as an excuse to make ugly commits with bad commit messages. Again: I'm not trying to make it mandatory, just to allow this sort of merges. Please let me know what you think. -- Tom. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
