ITDP / the-online-brt-planning-guide

Online collaborative version of the BRT Planning Guide
https://brtguide.itdp.org
Other
6 stars 20 forks source link

Edits to the landing page #110

Closed aegauthier closed 7 years ago

aegauthier commented 7 years ago

Hi - again, feeling super unsure about all of this : ) but I have made edits to the landing page that will do for now. I left the volume text at the end because I didn't see it on the online version and as long as it doesn't show in real life, we can leave it for now. Does that sound okay? Let me know if this worked and if not, we may need a deeper intervention with me : )

Thanks - Aimee

aegauthier commented 7 years ago

Okay so I failed : ) so let me know what we need to do - thanks

jonasmalacofilho commented 7 years ago

Hi! You need to escape the @ by prefixing it with a backslash: \@.

The @ character alone is reserved for quotations using the short syntax:

> Quote
@ Author
aegauthier commented 7 years ago

i think i fixed the at sign thing...do i need to do anything else - whoops already another failure : (

jonasmalacofilho commented 7 years ago

Err... [ and ] are also reserved characters, they are used to surround (optional) arguments to commands.

Try brtguide\@itdp.org or brtguide \[at\] itdp.org : )

jonasmalacofilho commented 7 years ago

(I'll document the reserved characters ASAP)

jonasmalacofilho commented 7 years ago

The continuous-integration/travis-ci/pr check for assets not saved with LFS will fail, but that's ok. It's just that your branch is based on a very old commit (Aug 18), which makes this pull request include a commit that I made in error that includes a file not in LFS and that makes the test fail.

aegauthier commented 7 years ago

So what should I do? I wasn't sure how to or if i needed to update my guide on the c: drive - I tried git pull (see screen shot) as an attempt to update it but didn't know what else to do... git bash screen shot

jonasmalacofilho commented 7 years ago

What's usually enough for me is to go to my local master (git checkout master), update it (git pull), and create and checkout a new branch (git checkout -b what-i-ll-do-now). That is, if the work branch hasn't been created yet.

If I already am on a work branch and need to update it with the latest master, I might do one of the following:

I find the first way to be clearer and easier, but many people might prefer the second.

From the screenshot I see one minor problem: you tried to checkout "origin". If you were planning to checkout "master", you were probably following the (b) method of updating your branch, and it would have worked...