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 ________________________________________ 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 >
