World: r3wp
[!REBOL3 Source Control] How to manage build process
older newer | first last |
BrianH 29-Oct-2010 [219] | Not really, Fork. The mezzanine code has to be ported by hand, for various reasons. Small but significant tweaks are necessary. Different directories in the same repo would work though. |
Andreas 29-Oct-2010 [220x2] | The respective command for that is "git push". |
You can work with remote repositories either by directly referring to URLs, or by locally associating symbolic names with the URLs (git calls those local aliases "remotes"). | |
Fork 29-Oct-2010 [222x2] | Brian: You can have as significant differences on a branch as you want, and you can name the branches. You can peruse the branch heads independently, like this: http://github.com/mojombo/god/branches |
It's not necessary that branches ever actually be merged together. | |
BrianH 29-Oct-2010 [224] | The file organization and naming is completely different in a108+ now too. They really are separate. |
Andreas 29-Oct-2010 [225] | Btw, I strongly recommend doing a: $ git config --global color.ui auto Which will instruct git to use ANSI colors in command output to the terminal. |
Fork 29-Oct-2010 [226x3] | Also do not miss doing the git config to set up your email and name information in the commits. Otherwise it will swipe that from your local machine name / localhost: http://help.github.com/git-email-settings/ |
GitHub hides the address and replaces it with your user name on the site... if you have one registered. But anyone who clones the repository will have access to the address you list. | |
(By looking at the commit log.) | |
BrianH 29-Oct-2010 [229x2] | The git installer is asking what the line ending conversion policy should be - what should I use? Before you answer, let me point out that some of the new script features (notably checksum) are line ending sensitive. Shall we establish a rule to use Unix-style line endings in committed source? And then tell people that script checksums of uncompressed scripts will break if you convert to your local line endings? Note: Binary-encoded compressed scripts will also break if they are transmitted in text mode, but script-encoded compressed scripts will be fine; nonetheless, we should probably not accept compressed scripts of any kind in the official repos. |
Carl, if you just installed without paying attention to that setting, you might need to change things based on the answer. | |
Andreas 29-Oct-2010 [231] | Use "commit line endings as they are", and Git does not interfere with line endings. This is usually easiest to handle. |
BrianH 29-Oct-2010 [232x2] | OK. And then I will remember to never initially create a source file with CRLF. |
That will be a real problem for most REBOL users though, as they use Windows. | |
Andreas 29-Oct-2010 [234] | That's a separate decision, then. |
BrianH 29-Oct-2010 [235] | Yes, but on topic for managing the build process. Hence the question. |
Andreas 29-Oct-2010 [236x3] | As Carl correctly said, "If C code line terminators are effecting your tools, I suggest you get better tools." |
As long as we are using something consistently ... | |
Carl's call, I guess. | |
BrianH 29-Oct-2010 [239] | I would recommend using Unix line endings in the repo, whatever you like locally, and just not allow script checksums or compression in the official repo. |
Andreas 29-Oct-2010 [240] | Agreed. Would be my choice as well. |
Fork 29-Oct-2010 [241x3] | Yup. |
Want to reiterate: Bravo for taking this step, you guys. | |
I know it's hard to use an unfamiliar tool, and I empathize with BrianH's observations about how Linus's Git implementation does have a hefty dependency stack (if you don't use Linux where all that stuff is taken for granted). If you're trying to stage a revolution in software methodology it might seem a bit like you're sleeping with the enemy... | |
BrianH 29-Oct-2010 [244] | I have a github account now: BrianHawley. Next week I will be putting up repos for R2/Forward and the loadable version of R3's module system. |
Fork 29-Oct-2010 [245] | There'll certainly be things you want changed and improved, and I think the best way to do that is to insinuate Rebol into the predominant toolchain rather than see it as its own completely parallel universe. Github itself is based on Ruby on Rails, but they're using a python syntax colorizer. If a tool is good, it can get slipstreamed in... and Rebol is so small that it could do the same, if it just mellowed out and became a little less prickly... |
Oldes 29-Oct-2010 [246] | Is it possible that if we add enough REBOL scripts, GitHub associates .r extension to REBOL? |
Fork 29-Oct-2010 [247x2] | Rebol is not the only language where file extension issues come up, but they're trying to take the sort of Apple philosophy of "we'll figure it out" as opposed to there being a web of settings. It's just not high on their priority list to "sense" whether a file is Rebol or not. |
But long term that's what they want, to sniff and guess instead of offer settings. The GitHub people are very pragmatic, and opinionated, and (in my experience) quick and efficient. | |
BrianH 29-Oct-2010 [249] | The new default lookup extension for IMPORT is .reb, so maybe we can use that, or .r2 or .r3 for version-specific code. |
Fork 29-Oct-2010 [250x2] | I saw the .reb thing. They would probably do that. They've already given Rebol .r2, .r3, and .rebol ... tekkub and I seem to have a little bit of a rapport now so I could probably ask him to do .reb too |
But still, why not .rebol ? | |
BrianH 29-Oct-2010 [252] | But you have to remember that R is really established, so it will be hard to take .r away from them in Github. |
Andreas 29-Oct-2010 [253] | (-> "Source Control") |
Fork 29-Oct-2010 [254x3] | They were talking about recognizing the rebol header, that's what they want to do, they just don't have the priority. |
I imagine that if RT said "hey we'd like to be your customers and pay you for a closed source hosting account of capacity X" then for some X they'd accept adding that sensor to the system as a priority. | |
Without that, they tend to their paying clients priorities first, I think. | |
BrianH 29-Oct-2010 [257] | Good point :) |
Fork 29-Oct-2010 [258] | You could add it to gitorious trivially, or run your own gitorious installation which favors .r for Rebol, but outsourcing things like this seems to me like it's worth every penny... esp when it's free. |
Andreas 29-Oct-2010 [259] | Fork, _please_ move this discussion to "Source control". |
Carl 29-Oct-2010 [260] | Had the chance to read Git for Computer Scientists. Any system that has a "rebase" cannot be all bad. ;) |
Andreas 29-Oct-2010 [261] | rebase rocks :) |
Carl 29-Oct-2010 [262x2] | Checking for git on local ubuntu. |
nope. not found | |
Andreas 29-Oct-2010 [264x2] | up until 10.04 the package is called "git-core" |
for anything before 9.04 (jaunty), the packaged git-core is rather old, so you're probably better off installing from source. | |
Carl 29-Oct-2010 [266x3] | yes, I was concluding that same thing. |
git does not make | |
Strolling down a dangerous road... | |
older newer | first last |