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.
Ok, my next topic will be that showing up how it can be messy after only 3
commits.
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?
It might be simple to think that working on the develop branch makes
flattened because only one commit at time and working on a branch create a
parallel line which shows that merged branch.
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.
Actually, the Justin repo has this README at creation time, mine too, it's
because it's not easily possible to keep an empty branch in Git, that's the
reason why, but sure, I could have explained it.
Thanks,
-Fred
-----Message d'origine-----
From: Alex Harui
Sent: Monday, March 25, 2013 6:40 PM
To: dev@flex.apache.org
Subject: Re: [Git/Wiki] please review the proposed workflow and comment
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
