*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.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.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=60134791&iu=/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 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=60134791&iu=/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=60134791&iu=/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=60134791&iu=/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=60134791&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
