Mike,
Btw, for what I'm about to do as described previously, I'll be happy if you
can review and say your point of view / way to do it.
Cheers,
-Fred
-----Message d'origine-----
From: Frédéric THOMAS
Sent: Monday, March 25, 2013 6:14 PM
To: dev@flex.apache.org
Subject: Re: [Git/Wiki] please review the proposed workflow and comment
To me, many of the reasons you are favoring the rebase workflow is so that
people can't accidently mess up a merge (and yes, it can keep the history
cleaner)
Yes, that's meanly that, it will work except if people doesn't want to push
right after the merge, in this rare case, it's better to use 'git rebase -p'
instead of 'git pull --rebase', that's the only exception, almost of the
time people will push as there are no reason to not do it, the 'git
pull --rebase' method will be enough, people can trust it and it's simple to
use, no headaches due to how git works inside, that's the reason why I wrote
this workflow on the main git wiki page, I think it is adapted at what we do
here.
In a more general way, I want to show more examples like managing conflicts,
git undo (reverse / reset / reflog undo / checkout), collaboration, etc...
which are technical particularities but useful to know.
In a more particular one, the workflow and the doc for the release.
Thanks Mike,
-Fred
-----Message d'origine-----
From: Michael A. Labriola
Sent: Monday, March 25, 2013 5:43 PM
To: dev@flex.apache.org
Subject: RE: [Git/Wiki] please review the proposed workflow and comment
Ok, so, yes, it has been discussed on this list with the conclusion it
wasn't feasible by INFRA but one one asked them.
Okay, that's fine if the people here decided it was infeasible I can accept
that.
Sometimes I think we just solve the wrong problems and I was wondering if
that was the case here. To me, many of the reasons you are favoring the
rebase workflow is so that people can't accidently mess up a merge (and yes,
it can keep the history cleaner). Places like the Linux kernel don't have
that issue because people are effectively working in their own repo with a
limited number of people actually merging up into develop and managing
master. It also makes the scenarios that I was describing to Alex, code
reviewing someone's changes, jumping back and forth in time, all more
feasible. Without it, we really do have everyone pushing their branches back
into the same repo, etc. and it does feel (as several people have pointed
out) like a more complicated SVN. Just thinking aloud.
Mike
