Working on the "explain why ignore" objective within this lesson #94

Open
wants to merge 1 commit into
from

Projects

None yet

5 participants

@wcornwell

No description provided.

@iglpdc iglpdc self-assigned this Apr 20, 2015
@iglpdc iglpdc added the enhancement label Apr 20, 2015
@iglpdc iglpdc commented on the diff Apr 25, 2015
05-ignore.md
-What if we have files that we do not want Git to track for us,
-like backup files created by our editor
-or intermediate files created during data analysis.
-Let's create a few dummy files:
+### Why it is sometimes useful to *not* track files
@iglpdc
iglpdc Apr 25, 2015 Contributor

Our lesson template doesn't use subheadings inside a given topic, so it's better to remove this line.

@iglpdc iglpdc commented on the diff Apr 25, 2015
05-ignore.md
-like backup files created by our editor
-or intermediate files created during data analysis.
-Let's create a few dummy files:
+### Why it is sometimes useful to *not* track files
+
+Git is incredible useful tool for tracking the changes to your code. However, it's not necessary to the track the changes of *every* file associated with a project. Sometime there are non-code files in your project directory for which you might not want to track changes. For example:
+
+1. a text editor might create backup files automatically
+2. intermediate files created during data analysis
+3. some types of output files
+4. binary files (i.e. files that are not text based)
+5. really, really big files
+
+When projects (or files) get really big it's adventageous *not* to track these files, because tracking them will make your repository unnecessarily big, and, in some cases, this will slow down all of Git's processes. Moreover, only tracking changes that are necessary keeps your repository nice and clean and organized. Every little bit of organization helps when project gets big and complicated, when your collaborating with a team, or when you come back to a project in 6 months or so with only a hazy memory of what you did.
+
+### How to configure Git to ignore certain files
@iglpdc
iglpdc Apr 25, 2015 Contributor

Same this as above for subheadings.

@iglpdc iglpdc commented on the diff Apr 25, 2015
05-ignore.md
-What if we have files that we do not want Git to track for us,
-like backup files created by our editor
-or intermediate files created during data analysis.
-Let's create a few dummy files:
+### Why it is sometimes useful to *not* track files
+
+Git is incredible useful tool for tracking the changes to your code. However, it's not necessary to the track the changes of *every* file associated with a project. Sometime there are non-code files in your project directory for which you might not want to track changes. For example:
@iglpdc
iglpdc Apr 25, 2015 Contributor

I think the second and third sentences say mostly the same thing. What about something shorter like:

"However, sometimes it's not necessary to the track the changes of every file in your working directory. For example, you might want to ignore changes in certain types of files, such as:"

I used "working directory" instead of "project directory" because is the terminology we use in the rest of the lesson. Also, I dropped "associated with the project", because we want to emphasize that the repo is restricted to a directory and "associated with" may refer to another file outside this directory.

@daisieh
daisieh Apr 27, 2015 Contributor

teeny comment: can you fix wording: "Git is an incredibl_y_ useful tool"...

@iglpdc iglpdc commented on the diff Apr 25, 2015
05-ignore.md
-What if we have files that we do not want Git to track for us,
-like backup files created by our editor
-or intermediate files created during data analysis.
-Let's create a few dummy files:
+### Why it is sometimes useful to *not* track files
+
+Git is incredible useful tool for tracking the changes to your code. However, it's not necessary to the track the changes of *every* file associated with a project. Sometime there are non-code files in your project directory for which you might not want to track changes. For example:
+
+1. a text editor might create backup files automatically
@iglpdc
iglpdc Apr 25, 2015 Contributor

Maybe (as the rest items are types of files):

"1. backup files created by your text editor"

@iglpdc iglpdc commented on the diff Apr 25, 2015
05-ignore.md
-What if we have files that we do not want Git to track for us,
-like backup files created by our editor
-or intermediate files created during data analysis.
-Let's create a few dummy files:
+### Why it is sometimes useful to *not* track files
+
+Git is incredible useful tool for tracking the changes to your code. However, it's not necessary to the track the changes of *every* file associated with a project. Sometime there are non-code files in your project directory for which you might not want to track changes. For example:
+
+1. a text editor might create backup files automatically
+2. intermediate files created during data analysis
+3. some types of output files
+4. binary files (i.e. files that are not text based)
+5. really, really big files
@iglpdc
iglpdc Apr 25, 2015 Contributor

I'm not sure about this one. "Big file" is different for different people and, in practice, most novices wouldn't deal with "really, really big files". I'd drop it.

@iglpdc iglpdc commented on the diff Apr 25, 2015
05-ignore.md
-What if we have files that we do not want Git to track for us,
-like backup files created by our editor
-or intermediate files created during data analysis.
-Let's create a few dummy files:
+### Why it is sometimes useful to *not* track files
+
+Git is incredible useful tool for tracking the changes to your code. However, it's not necessary to the track the changes of *every* file associated with a project. Sometime there are non-code files in your project directory for which you might not want to track changes. For example:
+
+1. a text editor might create backup files automatically
+2. intermediate files created during data analysis
+3. some types of output files
+4. binary files (i.e. files that are not text based)
@iglpdc
iglpdc Apr 25, 2015 Contributor

What about "compiled code and libraries" or something like that instead? Binary files is a bit restrictive. E.g. if you work with images, you may want to store them in the repo as data, just to improve the provenance of your data analysis.

@iglpdc iglpdc commented on the diff Apr 25, 2015
05-ignore.md
-What if we have files that we do not want Git to track for us,
-like backup files created by our editor
-or intermediate files created during data analysis.
-Let's create a few dummy files:
+### Why it is sometimes useful to *not* track files
+
+Git is incredible useful tool for tracking the changes to your code. However, it's not necessary to the track the changes of *every* file associated with a project. Sometime there are non-code files in your project directory for which you might not want to track changes. For example:
+
+1. a text editor might create backup files automatically
+2. intermediate files created during data analysis
+3. some types of output files
+4. binary files (i.e. files that are not text based)
+5. really, really big files
+
+When projects (or files) get really big it's adventageous *not* to track these files, because tracking them will make your repository unnecessarily big, and, in some cases, this will slow down all of Git's processes. Moreover, only tracking changes that are necessary keeps your repository nice and clean and organized. Every little bit of organization helps when project gets big and complicated, when your collaborating with a team, or when you come back to a project in 6 months or so with only a hazy memory of what you did.
@iglpdc
iglpdc Apr 25, 2015 Contributor

I think this part is unnecessary. Novices are unlikely to have big repos, but they tend to overestimate the size of a repo. Moreover, this is not the main reason for using git-ignore.

@daisieh
daisieh Apr 27, 2015 Contributor

Agreed.

@iglpdc
Contributor
iglpdc commented Apr 25, 2015

Thanks, @wcornwell. I made some comments above, take a look please.

@wcornwell

Hi @iglpdc I agree with all of your changes and comments. What's the next step?

@msarahan
Contributor

Hi @wcornwell the next step is for you to make the changes and comments from above and commit them. When you push them to your repository, those changes automatically show up here. The maintainers will review those changes. Once you and the maintainers are both happy, they will merge this PR.

@iglpdc
Contributor
iglpdc commented Apr 29, 2015

@wcornwell, yes, as @msarahan says you just have to make another (or more) commits with the new changes to the same branch you sent the PR from. So, basically:

$ git checkout patch-1
(...make your changes...)
$ git add 05-ignore.md
$ git commit -m "Describe your changes"
$ git push origin patch-1

And your PR will be automatically updated.

@iglpdc
Contributor
iglpdc commented Jun 14, 2016

Hi, @wcornwell, any chances you can finish this any time soon? Otherwise I could carry on the changes and merge the PR on your behalf.

@wcornwell

Hi @iglpdc sorry about that. I've lost track of where this is at the moment, so why don't you carry on the changes and merge it for me. That way I won't mess the repo up. Cheers!

@rgaiacs rgaiacs commented on the diff Aug 27, 2016
05-ignore.md
@@ -6,13 +6,25 @@ minutes: 5
---
> ## Learning Objectives {.objectives}
>
-> * Configure Git to ignore specific files,
-> and explain why it is sometimes useful to do so.
+> * Explain why it is sometimes useful to have Git ignore specific files
@rgaiacs
rgaiacs Aug 27, 2016 Contributor

Maybe "Explain why can be useful to have Git ignoring some files"?

@rgaiacs
Contributor
rgaiacs commented Aug 27, 2016

@iglpdc I think that you can close this one since it is very out of date.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment