Merge sounds like the way to go... Let's not revisit the whole Git usage thread(s) ;-)
EdB On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala <bigosma...@gmail.com> wrote: > On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz <christofer.d...@c-ware.de > > > wrote: > > > You don't loose the history when rebasing ... you sort of serialize it. > Ok > > the order of commits is messed up, but I never really care about this. > > It might look less interesting in a GIT visualization tool where you > could > > see tons of different branches and merges, but it should be a lot easier > to > > maintain, as a serial history is definiely the one that causes the least > > trouble ;-) > > > > In IntelliJ I usually set my "update" operation to "Rebase" using "Stash" > > and have never really had any problems. One click on "Update SCM" and I > > still work on my featrue branch, but pull in all changes from develop or > > whatever branch I branched from. When it comes to commit, the commit > itself > > should be a fast-forward commit. > > > > But I guess there are several flavours here ... depending on the guy you > > ask or listen too, a different way will probably be recommended. I guess > > manually merging changes from develop to the feature branch is as valid > as > > rebasing, but I think rebasing is easier and causes less trouble, but you > > loose the "real-order" of commits (Which I don't really care about). > > > > Chris > > > > I will let Erik decide if he wants to rebase or merge. My recommendation > is that, since it is a feature branch, it will be useful to retain the > commit history intact. So, merge makes sense. > > If Erik does not want to keep the commit history intact, rebase will just > work fine. > > Thanks, > Om > > > > > > > > > > ________________________________________ > > Von: omup...@gmail.com <omup...@gmail.com> im Auftrag von OmPrakash > > Muppirala <bigosma...@gmail.com> > > Gesendet: Mittwoch, 2. Juli 2014 10:25 > > An: dev@flex.apache.org > > Betreff: Re: New Flex to JS project > > > > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin <e...@ixsoftware.nl> > wrote: > > > > > Ok, just checking: > > > > > > I create a local branch, let's call it 'vf2js', off 'origin/develop'. I > > > select this as my active branch. > > > > > > So far so good. > > > > > > > If I then 'rebase', all changes that have > > > been made to 'origin/develop' will be pulled into my local branch? So > > far, > > > so good. > > > > > > Rebase at this point is not required. The code from origin/develop is > > already in the 'vf2js' branch. You will need to 'merge' from > > origin/develop into vf2js once in a while to make sure that you are in > sync > > with whats happening with origin/develop. When you are done with the > > feature, you just 'merge' vf2js into develop. If the history of the > > 'vf2js' branch is not important, then you use the rebase option. > > > > > > > But now I want the world to see what's in my local vf2js branch, > > > so I 'publish' it. Is keeping the remote copy of my local branch up to > > date > > > just a question of 'pushing' all commits to that remote branch? > > > > > > Yes, that is correct. > > > > > > > Will > > > changes that come from the remote 'develop' via my local 'vf2js' also > in > > > the remote 'vf2js' that way? > > > > > > > Cannot compute. Can you rephrase the question? > > > > > > > > > > Thanks, > > > > > > EdB > > > > > > > > > > > > On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz < > > christofer.d...@c-ware.de > > > > > > > wrote: > > > > > > > No effort at all ... that's what GIT rebase is for. > > > > > > > > You can think of this sort of an automated "Create-Patch, Revert, > > Update, > > > > Apply Patch" ... if all goes well, it's just this one command, if > there > > > are > > > > conflicts, you get the usual conflict editor you would get anyway if > > you > > > > created conflicts on develop. > > > > > > > > Chris > > > > > > > > > > > > ________________________________________ > > > > Von: Erik de Bruin <e...@ixsoftware.nl> > > > > Gesendet: Mittwoch, 2. Juli 2014 09:50 > > > > An: dev@flex.apache.org > > > > Betreff: Re: New Flex to JS project > > > > > > > > Hi Chris, > > > > > > > > Thanks for the feedback. > > > > > > > > I'm talking about FalconJX, not Falcon. The latter is the "new" SWF > > > > compiler, the former is the Flex to JavaScript cross compiler. > > > > > > > > I guess a feature branch might work... But I'm afraid that keeping > that > > > > branch up to date with the 'develop' branch will add extra work. How > to > > > > best handle that part, so I don't spend what little time I have on > Git > > > > stuff instead of code? > > > > > > > > EdB > > > > > > > > > > > > > > > > > > > > On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz < > > > christofer.d...@c-ware.de > > > > > > > > > wrote: > > > > > > > > > I think the reason for the overlay is that by this we are tricking > > the > > > > > FlashBuilder to use Falcon instead of the old compiler. > > > > > It should be possible to have Falcon separate from the normal > > compiler. > > > > > It's just that FlashBuilder will probably not be albe to use it > that > > > way. > > > > > Probably IntelliJ would support this withn a few hours, Flexmojos > > > within > > > > a > > > > > few weeks and FlashBuilder never ;-) > > > > > > > > > > You shouldn't implement this in the develop branch but create a > > > > > feature-branch instead that forks off the develop branch. This way > > your > > > > > changes are available to anyone interested and as soon as the > feature > > > is > > > > > finished, you merge it back to develop. > > > > > > > > > > Chris > > > > > ________________________________________ > > > > > Von: Erik de Bruin <e...@ixsoftware.nl> > > > > > Gesendet: Mittwoch, 2. Juli 2014 09:33 > > > > > An: dev@flex.apache.org > > > > > Betreff: New Flex to JS project > > > > > > > > > > Hi, > > > > > > > > > > I'm working on creating a way to publish vanilla Flex SDK projects > to > > > > > JavaScript on latest gen browsers. This project consists of several > > sub > > > > > projects, and I'm wondering what is the best way forward with > regard > > to > > > > > contributing them: > > > > > > > > > > 1) two new namespaces and accompanying projects in the main Flex > SDK: > > > > > vf2js_mx and vf2js_s. These namespaces will contain shim objects > for > > > (you > > > > > guessed it) MX and Spark components. > > > > > > > > > > 2) two new code paths in FalconJX: one for AS and one for MXML > > > > > > > > > > 3) a new JavaScript library for the components and shims for AS > > classes > > > > > > > > > > 4) a testing framework for the JS components, loosely based on > > > Marmotinni > > > > > > > > > > Questions: > > > > > > > > > > A - I would very much like to work in the 'develop' branches of the > > > > > projects involved, but especially on the part of '1)' I'm not sure > > if I > > > > did > > > > > it right. All tests I can think of seem to pass, but maybe someone > > has > > > > the > > > > > time to do a code review on a branch that I can publish? > > > > > > > > > > B - In order for this to work, FalconJX needs to be part of the > > regular > > > > SDK > > > > > distribution. Folks who did this on the FlexJS overlay: what does > it > > > take > > > > > to make FalconJX part of the SDK? > > > > > > > > > > That's it, for now :-) > > > > > > > > > > Thanks, > > > > > > > > > > EdB > > > > > > > > > > > > > > > > > > > > -- > > > > > Ix Multimedia Software > > > > > > > > > > Jan Luykenstraat 27 > > > > > 3521 VB Utrecht > > > > > > > > > > T. 06-51952295 > > > > > I. www.ixsoftware.nl > > > > > > > > > > > > > > > > > > > > > -- > > > > Ix Multimedia Software > > > > > > > > Jan Luykenstraat 27 > > > > 3521 VB Utrecht > > > > > > > > T. 06-51952295 > > > > I. www.ixsoftware.nl > > > > > > > > > > > > > > > > -- > > > Ix Multimedia Software > > > > > > Jan Luykenstraat 27 > > > 3521 VB Utrecht > > > > > > T. 06-51952295 > > > I. www.ixsoftware.nl > > > > > > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
