Adding git-ignore command, tests, and documentation. #264

tstone2077 · 2019-06-13T03:42:50Z

git-ignore will allow users to quickly add entries to the gitignore files in the repositories.

Many times, I'll have a config file or log file buried in a series of sub-directories and find it frustrating to edit the right git ignore with the right relative path to the file that i want to add. This script makes adding items to a gitignore file easier.

Instead of managing paths and relative paths such as
echo "path/to/the/file.txt" >../../../../../../.gitignore
git ignore path/to/the/file.txt
No matter what directory that is in, the correct relative path will be added to the gitignore.

This script will also give the ability to add directories, extention globs, and files to any gitignore in parent directories. Furthermore, it allows you to easily open the gitignore file in your favorite editor from anywhere using:
git ignore --edit

I have been using this script for years and it has made things much easier for me, so I figured I'd contribute.

gitgitgadget · 2019-06-13T03:43:46Z

Welcome to GitGitGadget

Hi @tstone2077, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests.

Please make sure that this Pull Request has a good description, as it will be used as cover letter.

Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:

the lines should not exceed 76 columns,
the first line should be like a header and typically start with a prefix like "tests:" or "commit:", and
the commit messages' body should be describing the "why?" of the change.
Finally, the commit messages should end in a Signed-off-by: line matching the commits' author.

It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code.

Contributing the patches

Before you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a PR comment of the form /allow <username>.

Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment /submit.

After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions.

If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox ("raw") file corresponding to the mail you want to reply to from the Git mailing list. If you use GMail, you can upload that raw mbox file via:

curl -g --user "<EMailAddress>:<Password>" --url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txt

dscho · 2019-06-13T08:45:20Z

Please edit this desctription before submitting, as it will be sent as cover letter (and you don't really want to repeat the commit message, but instead give a bit more background/motivation for your work).

dscho · 2019-06-13T08:45:43Z

/allow tstone2077

gitgitgadget · 2019-06-13T08:46:33Z

User tstone2077 is now allowed to use GitGitGadget.

dscho · 2019-06-13T08:49:41Z

Also note that the tests failed on Windows:

++ git ignore -p 2 --edit
/usr/bin/seq: missing operand
Try '/usr/bin/seq --help' for more information.

Maybe this tell s you immediately what's wrong?

dscho · 2019-06-13T15:08:39Z

git-ignore.sh

@@ -77,8 +77,9 @@ get_git_ignore () {

 	if test $_parent_level -ne 0
 	then
-	    for i in $(seq 1 $_parent_level)


If the problem is a missing operand, isn't it more likely that $_parent_level is set to empty?

interesting... i don't have a windows box to test on, so I was guessing that the seq binary worked differently on windows (which I've seen in other utilities before). I'm not sure how $_parent_level could be empty since it's defaulted on line 162. The only guess I have is on line 182,

_parent_level="${1#--parent-level=}"

evaluates to empty on windows... maybe... Tricky to debug without being able to reproduce it. I'll see what I can come up with.

Thanks!

One simple trick I use all the time is to insert something like

test -z "$DDDEBUG" || set -x

into the shell script in question, and then run the command in the test suite prefixed with DDDEBUG=1, like so:

DDDEBUG=1 git ignore ...

Another trick I use when debugging things via Azure Pipelines (I don't have a macOS setup, for example) is to edit the azure-pipelines.yml definition to execute only the job that I am really interested in, and also substitute the make test in ci/run-build-and-test.sh with something like (cd t && sh t7070-*.sh -i -v -x), to accelerate the turnaround between force-push and test result.

Maybe that helps you, too?

Awesome tricks which I will be sure to employ. Do you think it's necessary at this point since the last CI succeeded? Also, are there any more suggestions on getting this submitted? I changed the description, but I don't know if that is good enough. I think the most descriptive message I could write about this change is in the original commit message.

Do you think it's necessary at this point since the last CI succeeded?

I fear that the value of _parent_level might still be bogus and that the most recent changes might still just paper over that issue...

are there any more suggestions on getting this submitted?

Yes. The commit 4462b7f should be squashed into the first commit: On the Git mailing list, adding a patch with a bug that is immediately fixed by the next patch is frowned upon. Better to not even introduce the bug in the first place.

But then, I think that seq might be the better choice, still, you just need to figure out why it gets an incorrect number of parameters.

In the tests,
line 3659 shows _parent_level is getting set correctly to 2:

+ _parent_level=2

and line 3691 shows seq is being used correctly:

++ seq 1 2 /usr/bin/seq: missing operand Try '/usr/bin/seq --help' for more information.

it's just that version of windows (or mingw) isn't supporting it correctly. I'm not up for troubleshooting why 'seq 1 2' doesn't work on that environment of windows. That's why I went with the while loop to replace it... it seems like a reasonable, less fragile, and more portable implementation than 'seq'.

Thoughts?

Hmm. Works here:

$ /usr/bin/seq 1 2 1 2

git-ignore.sh

tstone2077 · 2019-07-01T02:36:36Z

shall i submit this?

The 'git ignore' command modifies a .gitignore file in your path easily. By default, it adds lines to the .gitignore found in the root of your repository. It can, however, add lines to a gitignore anywhere inbetween the file(s) passed in and the root of the repository. The lines added to the gitignore can be based on filename, extension, directory, or recursive glob. Also, you can easily open the gitignore file using your $EDITOR with 'git ignore --edit'. This can make things much easier when ignore files in subdirectories. No longer will you have to run: echo "path/to/the/file.txt" >../../../../../../.gitignore instead: git ignore file.txt Signed-off-by: Thurston Stone <tstone2077@gmail.com>

dscho · 2019-07-01T13:18:45Z

shall i submit this?

I am still not sure that the seq problem has been properly root-caused, but if you are not worried about that as much as I am, I see no obstacle against submitting now.

tstone2077 · 2019-07-17T02:48:39Z

/submit

gitgitgadget · 2019-07-17T02:49:45Z

Submitted as pull.264.git.gitgitgadget@gmail.com

gitgitgadget · 2019-07-17T16:37:22Z

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Thurston via GitGitGadget" <gitgitgadget@gmail.com> writes:

> Instead of managing paths and relative paths such as echo
> "path/to/the/file.txt" >../../../../../../.gitignore git ignore
> path/to/the/file.txt No matter what directory that is in, the correct
> relative path will be added to the gitignore.

Hmph, do you mean you type something like this?

	$ cd path/to/the
	... work in that deep directory ...
	... realize that file.txt in that directory needs ignoring ...
	$ echo path/to/the/file.txt >../../../../../../.gitignore

Wouldn't this simpler to type and less error prone, as you do not
have to count ../?

	$ cd path/to/the
	... work in that deep directory ...
	... realize that file.txt in that directory needs ignoring ...
	$ echo file.txt >.gitignore

gitgitgadget · 2019-07-18T20:22:42Z

On the Git mailing list, Jeff King wrote (reply to this):

On Wed, Jul 17, 2019 at 09:35:34AM -0700, Junio C Hamano wrote:

> "Thurston via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
> > Instead of managing paths and relative paths such as echo
> > "path/to/the/file.txt" >../../../../../../.gitignore git ignore
> > path/to/the/file.txt No matter what directory that is in, the correct
> > relative path will be added to the gitignore.
> 
> Hmph, do you mean you type something like this?
> 
> 	$ cd path/to/the
> 	... work in that deep directory ...
> 	... realize that file.txt in that directory needs ignoring ...
> 	$ echo path/to/the/file.txt >../../../../../../.gitignore
> 
> Wouldn't this simpler to type and less error prone, as you do not
> have to count ../?
> 
> 	$ cd path/to/the
> 	... work in that deep directory ...
> 	... realize that file.txt in that directory needs ignoring ...
> 	$ echo file.txt >.gitignore

It's also much more efficient, at least with our current implementation,
as we do not have to worry about matching this entry when we are dealing
with /some/other/path. See [1] for a pathological case.

I see "with our current implementation" because I could imagine a world
in which we have a more trie-like structure for non-wildcard patterns.
But I don't think anybody is working on such a thing.

-Peff

[1] https://public-inbox.org/git/20120329211136.GA1112@sigill.intra.peff.net/

dscho · 2019-10-01T12:44:10Z

@tstone2077 are you still interested in getting this patch into Git? If so, maybe you can engage in a discussion with Junio and Peff?

tstone2077 force-pushed the master branch 2 times, most recently from 75a3530 to cb32250 Compare June 13, 2019 04:11

dscho mentioned this pull request Jun 13, 2019

Adding git-ignore command, tests, and documentation. git/git#239

Closed

tstone2077 force-pushed the master branch from eadae1f to 96e192f Compare June 13, 2019 13:10

tstone2077 changed the title ~~git-ignore.sh: Adding git-ignore command~~ Adding git-ignore command, tests, and documentation. Jun 13, 2019

tstone2077 force-pushed the master branch from 96e192f to 5c7ae74 Compare June 13, 2019 13:33

dscho reviewed Jun 13, 2019

View reviewed changes

git-ignore.sh Outdated Show resolved Hide resolved

tstone2077 force-pushed the master branch 4 times, most recently from ea2d51e to 57de18a Compare June 15, 2019 14:29

weekly-digest bot mentioned this pull request Jun 16, 2019

Weekly Digest (9 June, 2019 - 16 June, 2019) #268

Closed

weekly-digest bot mentioned this pull request Jun 23, 2019

Weekly Digest (16 June, 2019 - 23 June, 2019) #274

Closed

tstone2077 force-pushed the master branch from 57de18a to 089e58e Compare June 30, 2019 20:45

tstone2077 force-pushed the master branch from 089e58e to b0b4034 Compare July 1, 2019 02:52

herman2018 approved these changes Jul 7, 2019

View reviewed changes

weekly-digest bot mentioned this pull request Jul 14, 2019

Weekly Digest (7 July, 2019 - 14 July, 2019) #286

Closed

weekly-digest bot mentioned this pull request Jul 21, 2019

Weekly Digest (14 July, 2019 - 21 July, 2019) #291

Closed

weekly-digest bot mentioned this pull request Oct 6, 2019

Weekly Digest (29 September, 2019 - 6 October, 2019) #377

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adding git-ignore command, tests, and documentation. #264

Adding git-ignore command, tests, and documentation. #264

tstone2077 commented Jun 13, 2019 •

edited

Loading

gitgitgadget bot commented Jun 13, 2019

dscho commented Jun 13, 2019

dscho commented Jun 13, 2019

gitgitgadget bot commented Jun 13, 2019

dscho commented Jun 13, 2019

dscho Jun 13, 2019

tstone2077 Jun 13, 2019

dscho Jun 13, 2019 •

edited

Loading

tstone2077 Jun 14, 2019

dscho Jun 14, 2019

tstone2077 Jun 15, 2019 •

edited

Loading

dscho Jun 17, 2019

tstone2077 commented Jul 1, 2019

dscho commented Jul 1, 2019

tstone2077 commented Jul 17, 2019

gitgitgadget bot commented Jul 17, 2019

gitgitgadget bot commented Jul 17, 2019

gitgitgadget bot commented Jul 18, 2019

dscho commented Oct 1, 2019

Adding git-ignore command, tests, and documentation. #264

Are you sure you want to change the base?

Adding git-ignore command, tests, and documentation. #264

Conversation

tstone2077 commented Jun 13, 2019 • edited Loading

gitgitgadget bot commented Jun 13, 2019

Welcome to GitGitGadget

Contributing the patches

dscho commented Jun 13, 2019

dscho commented Jun 13, 2019

gitgitgadget bot commented Jun 13, 2019

dscho commented Jun 13, 2019

dscho Jun 13, 2019

Choose a reason for hiding this comment

tstone2077 Jun 13, 2019

Choose a reason for hiding this comment

dscho Jun 13, 2019 • edited Loading

Choose a reason for hiding this comment

tstone2077 Jun 14, 2019

Choose a reason for hiding this comment

dscho Jun 14, 2019

Choose a reason for hiding this comment

tstone2077 Jun 15, 2019 • edited Loading

Choose a reason for hiding this comment

dscho Jun 17, 2019

Choose a reason for hiding this comment

tstone2077 commented Jul 1, 2019

dscho commented Jul 1, 2019

tstone2077 commented Jul 17, 2019

gitgitgadget bot commented Jul 17, 2019

gitgitgadget bot commented Jul 17, 2019

gitgitgadget bot commented Jul 18, 2019

dscho commented Oct 1, 2019

tstone2077 commented Jun 13, 2019 •

edited

Loading

dscho Jun 13, 2019 •

edited

Loading

tstone2077 Jun 15, 2019 •

edited

Loading