Community
Participate
Working Groups
Would be nice to have an .gitignore created or to have the option in the wizard to do so.
Short version: why? Long version: what's the motivation behind this request?
(In reply to Thomas Wolf from comment #1) > Short version: why? > > Long version: what's the motivation behind this request? IMHO every Git repo needs a .gitignore.
Perhaps... though I can find easily a git repo on Github that doesn't have and doesn't need one. In what way does creating an empty .gitignore help? Until it's filled with actual patterns, it doesn't serve any purpose. It only makes working tree traversals a little slower, and makes the newly created git repo immediately dirty. This is a gratuitous difference to command-line git that's likely to confuse beginners. I don't think this is going to be helpful.
I second Thomas' opinion, I think the decision to create a .gitignore should be left to the user. I checked git repository templates [1] and found that git init --template=<template directory> does not copy dotfiles from the template directory to a newly created repository. [1] https://git-scm.com/docs/git-init#_template_directory
(In reply to Matthias Sohn from comment #4) > I second Thomas' opinion, I think the decision to create a .gitignore should > be left to the user. I expected that, hence the second suggestion:.... or to have the option in the wizard to do so.
(In reply to Lars Vogel from comment #5) > I expected that, hence the second suggestion:.... or to have the option in > the wizard to do so. I had seen that :-) but I don't understand what the benefit of creating an empty .gitignore is.
(In reply to Thomas Wolf from comment #6) > (In reply to Lars Vogel from comment #5) > > I expected that, hence the second suggestion:.... or to have the option in > > the wizard to do so. > > I had seen that :-) but I don't understand what the benefit of creating an > empty .gitignore is. we could add another wizard page asking for the content of .gitignore if the option is set by the user
(In reply to Matthias Sohn from comment #4) > I checked git repository templates [1] and found that git init > --template=<template directory> does not copy dotfiles from the template > directory to a newly created repository. > > [1] https://git-scm.com/docs/git-init#_template_directory Yes, but it could be used to provide a repo-specific exclude file ($GIT_DIR/info/exclude). But templates are copied to $GIT_DIR anyway, not to the working tree, so not likely to be what Lars had in mind.
(In reply to Matthias Sohn from comment #7) > we could add another wizard page asking for the content of .gitignore if the > option is set by the user First, I don't think that makes it any easier than just having the user create the .gitignore file with content once the repo has been created. Second, I think this kind of inverts the workflow. A user would have to define the .gitignore before even populating the repo with real content, but what should be in the .gitignore depends on what the real content will be. (For maven projects, you'd want to exclude target/, but if you don't have maven projects but plain Java projects, it's probably bin/. If you're going to build with bazel, probably /.bazel*/, and so on.) If he knows already (perhaps he has an existing .gitignore file), then he can just as well simply copy that file after having created the repo. I also don't think we should encourage people to copy-paste random examples from the Internet, like these humongous catch-it-all examples one can find that exclude all kinds of IDE- and platform-specific files and folders. git ignore files with superfluous patterns can make file tree traversals needlessly slow, since file names have to be checked against umpteen patterns. Platform-specific patterns can go in the user gitignore (can be set via git config core.excludesfile if the system config doesn't define a location already), and excluding IDE-specific things is IMO a bad idea anyway since it'll make it harder to get everyone working on a repo use consistent settings.
ok, makes sense, then let's respond to this request with won't fix
