On Mon 10 Nov 2014, Emil Velikov wrote:
On 10/11/14 06:17, Chad Versace wrote:
On Sun 09 Nov 2014, Emil Velikov wrote:
- As explained in man:gitworkflow(7), merges between branches always
flow "upwards" and never "downwards". That is,
maint -> master -> next
and never
master <- next
- Merges are preferred over cherry-picks. As explained in
man:gitworkflow(7):
Merges have many advantages, so we try to solve as many problems as
possible with merges alone. Cherry-picking is still occasionally
useful.
Most importantly, merging works at the branch level, while
cherry-picking works at the commit level. [...] Merges are also
easier to understand because merge commit is a "promise" that all
changes from all its parents are now included.
There is a tradeoff of course: merges require a more careful branch
management. [...]
Always commit your fixes to the oldest supported branch that require
them. Then (periodically) merge the integration branches upwards
into each other.
[A "merging upwards" strategy"] gives a very controlled flow of
fixes. If you notice that you have applied a fix to
e.g. master that is also required in maint, you will need to
cherry-pick it (using git-cherry-pick(1)) downwards. This will
happen a few times and is nothing to worry about unless you do it
very frequently.
Fwiw although it somewhat makes sense to merge maint into master, I'm
personally "commit to master and cherry-pick to stable/maint" kind of
person. Either way, as long as you're ok dealing with conflicts etc.
I'll deal with it :P
I like the merge conflicts. They make me feel safer, more aware of the
global picture. Maybe I'm a masochist :/
Friendly request - please don't cherry-pick from next onto master.
Agreed. If had cherry-picked from next onto master in the past,
I consider that a mistake. That shouldn't happen again.
_______________________________________________
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
