Hi Fred, I looked at your good/bad wiki page. Thanks for taking the time to add pictures. For me, instead of labeling things good and bad, it might be better to have an explanation or picture of the longer-term ramifications of each sequence and why one sequence is recommended.
For example, I get that in the first scenario history gets flattened, but why does it really matter? And why, later, when you merge your branch, do you not want it flattened? Why will we all be glad some day that the history is flattened in certain cases but not others? Also, in the first scenario, it might be important to explain that you pushed your README change before Justin tried to push. You might need a two-column "timeline" to show what commands happened when. Thanks, -Alex On 3/25/13 10:14 AM, "Frédéric THOMAS" <webdoubl...@hotmail.com> wrote: >> 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 > > > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
