I'm hoping to spend more time in flex-sdk later this week. We have to get mustella to not disturb your git status so I will figure out how to ignore enough stuff to make that possible, or add an ant target that cleans out mustella if there isn't already one.
Regarding merge vs rebase, it is my current understanding that you shouldn't set policy to always use one or the other. It really depends on what you want to see in the log history. If you look at a visual representation of the log you will see a single line of history for a while, then a split and then a return to a single line. My personal preference is that we get to know Git well enough to understand how we are affecting that tree when we choose merge vs rebase. So far, I generally use rebase since the kinds of work I am doing don't feel like a separate effort to me. I see them as a single incremental change to what is already there. But I can imagine that some day I will want to record history as a separate line. I would argue that the way the log looks right now doesn't really need the most of those changes that are in a separate line to be in that separate line, but I am willing to learn from the experts as to why certain changes should be in a separate line. On 5/7/13 7:01 PM, "Justin Mclean" <jus...@classsoftware.com> wrote: > Hi, > >> It is okay to have exceptions. We can't have a solve for every scenario. > Well in a normal check in for the Flex SDK you should of at least run the > mustella check in tests, so I think the exception is going to be for every > check in. > > Normal development process for fixing bugs etc should involve running mustella > tests. > > I currently don't have a "clean" tree so can't confirm that the check in test > break git rebase. Can anyone try that out for me? > >> I am saying that there is a way to not deal with this I'd we don't want to. > Move back to SVN? :-) (I'm kidding) > > Justin -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
