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=60134791&iu=/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 ------------------------------------------------------------------------------ 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
