|
Any Twin Peaks fans still waiting for answers 25 years after the show finished?
Not for much longer[^], apparently. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
And here I thought you were talking about Twin Peaks[^] sports bars.
For those that don't know, it's like Hooters.
Jeremy Falcon
|
|
|
|
|
Quote:
colloquially referred to as breastaurants
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Or the Twin Pines Mall that was renamed to Lone Pine Mall by a time traveller.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
|
|
|
|
|
WHOHOA! How on for a second while I book my ticket to Lewisville, Texas! 
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
|
They're not just in Texas man. I know we have some in Louisiana as well because I've been there. Picked up a waitress's phone number once while stuffing my face.
She turned out to be crazy though.
Jeremy Falcon
|
|
|
|
|
"Hooters then filed suit against Twin Peaks and alleged the former Hooters executives had stolen Hooters trade secrets and management documents as part of their move to Twin Peaks"
What, they had a piece of headed paper with "Get hotties to flash the flesh" written on it?
I can't see that there's anything else they could have "stolen" that wouldn't be applicable to several million non-boobie-flashing establishments, so what could the great "secrets" be?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: what could the great "secrets" be?
Sorry man, I can't tell you. It's a secret.
Jeremy Falcon
|
|
|
|
|
That is great news ! I wonder if that sonic wizard Angelo Badalamenti (now 77 years old) will do the music. He did the score for the Russian film, Stalingrad, in 2013.
« There is only one difference between a madman and me. The madman thinks he is sane. I know I am mad. » Salvador Dali
|
|
|
|
|
Wow, Yet another show from the past brought back (Dad's Army thread)!
|
|
|
|
|
I wonder if you can expect answers from anything Lynch creates, he even said so himself in an interview I can't be arsed to look up(I think the interview was with regards to Mullholland Drive).
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
After the movie "Twin Peaks:Fire Walk With Me" a friends wife commented "Screwed again".
Answers may be given but more questions will be posed.
|
|
|
|
|
How are all those people going to get up and down those hills in their wheelchairs?
|
|
|
|
|
Down is not the problem. 
|
|
|
|
|
Hi everybody, me and my coworkers are new in Git, we just come from TFS, no one in the company had used Git before, we are totally noobs with Git.
So here comes our big question...
We don't know and it's not clear in the documentations (mostlry based on this http://nvie.com/posts/a-successful-git-branching-model/[^])
if:
- When Release-XX is in QA, should Development be in Code Freeze, no new Features are added or bug fixings that doesn't comes from Release-XX?
- Are we able to add or features after we end (following Pull request) or all the Pull request should be approved at the end some days before the new Release will be created?
I personally believe Development is for Developers, so its free, if I finish a feature or bug it should go to Develop branch, without being queue for weeks, this avoids the chaos or merging all the Features in the same day. But we are doing Code Freeze in develop when there is a Release-XX branch in QA, and due there is always a Release-XX, I can't never Finish my Ticket until the Pull Request fails due other Pull request approvals, then I must re-do my Pull Request.
If someone can give a good advice on how this should work, and provide links with documentation I would really appreciate it, I feel like we are in a Git-Chaos train
|
|
|
|
|
I am no guru in git (still confuses the hell out of me at times!), but I would have thought you would create a new branch to continue developing in. Alternatively clone the Repo into a whole new fork and develop on that, you could then do a pull back into the previous (in QA) repo.
|
|
|
|
|
We are using git flow.. it uses 2 main Branch:
Main <-- Current production, no one works here, you can create branches for hot fixes.
Develop <-- you get branches and do you work (Features), at the end you merge all there. When a release is planed, they get a Branch, called Release-## and that one is in QA and you can en theory continue working in Develop and the Features branch
so is like you said, but following the Git Flow logic, what we are not sure is when can we merge into Develop branch, and if we should or no do Code Freeze in Develop...
|
|
|
|
|
|
That link gave me a good clue...
When finishing a feature, it merges and deletes the local feature branch....
You can't do Develop code freeze if you applies that.. it sounds more as I like it and less as we are implementing it...
|
|
|
|
|
We have just starting using Git and it still confuses me, but once we are ready to do a release for verification and certification processes to be performed, we create another branch for development to continue and then rebase once the release is finished.
|
|
|
|
|
That is no Code Freeze over Develop... developers can close they Feature and merge in the right order. That sound good
|
|
|
|
|
I can't speak to the proper way to use Git-Flow, as I'd never heard of it before this post. However, I've been using Git professionally for about 4 years now, so maybe my experience will still be helpful.
I've found that the answer to most questions about using Git is "make a new branch".
Need a release that's "frozen" for QA? Make a new branch for it. There's no need for that to affect any other branch, since you can use cherry-pick to pull just the commit with the bug fix you need from your Dev branch to your QA branch without pulling anything else from Dev (assuming said bug fix doesn't depend on other commits). Alternatively, you can fix the bug on your QA branch and merge that change back to your Dev branch, again without pulling anything from Dev to QA.
Not sure if the thing you're working on should be in the main development branch yet? Make a new branch for it. Feature branches are fantastic, especially if you're working on a feature you aren't entirely sure how to implement. Think of it like a white board you can use to explore possible solutions, and then wipe clean if your current tack doesn't pan out. Plus, you can easily switch back to the main branch any time if, say, there's some bug you need to urgently fix.
Branching and merging are just so easy with Git that it's almost like you should branch by default unless you have some specific reason not to.
That said, I also recommend that you use rebase rather than merge. The reason is because bisect is a fantastic troubleshooting tool and it works better with a linear commit history, which rebase gives you. Some people will make a lot of noise about how merge preserves history and rebase doesn't, but that's a load of rubbish. The history that merge preserves is useless. I have never needed to know what the date was when J Random Dev originally created Commit-X, but I have many times needed to know when Commit-X was added to the branch I'm currently looking at, and rebase makes it easy to see that.
|
|
|
|
|
|
Thanks both for your answers...
I see now that probably my question was not clear enought...
Quote: I've found that the answer to most questions about using Git is "make a new branch".
That is exactly what we do... the question is, when you finish with your Feature Brach, are you able to merge it into Develop? (at this point QA have one Release XX)
That is the question, when are or aren't you allowed to merge. We are implementing Develo Code freeze until Release is close and merge, so all the pull request are applied at the end, it can be chaotic. So am I supposed to always merge after I finish into develop?
I hasn't see any single graph or draw showing Dev-Features-Release-Production-Hotfix interaction all at the same time, they are always modularized and never show the intersection between all.
|
|
|
|
|
When to merge two specific branches is a policy decision for your lead/project manager. In my case, I don't have to deal with QA, Release, or Code Freeze, but that's just a peculiarity of being a tools dev in the game industry. But, here is how I would do it if I were asked to:
Master: aka Develop. It is by and for the developers, and they control when things get merged into it. I see no reason why this branch should ever be frozen, but it should also never be broken (that's what feature branches are for). A dev should ALWAYS rebase their feature branch on master and test it before pushing to master/submitting a pull request.
Feature branches: Created and deleted by individuals/teams as needed. Merged into master when the feature is "done" (ready for validation, QA, etc).
QA/Freeze: branched off master from whatever commit is determined to be a release candidate. Bugs should be fixed on this branch and those fixes should be merged back into master asap.
Release: QA/Freeze branch when it's deemed ready to ship. The branch name should probably include the version number (eg: "release_3-0-0"). Start a new QA branch for your next RC.
Other branches (Production, Hotfix, etc) are basically just special cases of the above.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
