Would make sense to create .gitignore with good de...

# kotlin-toolchain

[Marius Barbulescu]

Would make sense to create .gitignore with good defaults when running kotlin init? Or update existing if one is already available.

[joffrey]

While I get the sentiment, I wouldn't want this to happen if init doesn't generate a git repository. So it should either not do anything git-related like now, or also generate a git repo. But not everyone wants a git repo. Maybe we could add this as an option like --init-git or something.

[joffrey]

And to be fair, you only need to add build to your .gitignore at the moment. A default .gitattributes would arguably be more useful.

[Fedor Ihnatkevich]

But not everyone wants a git repo

It's a very popular need though. So it's a good default. And if in some cases there are no plans to create a git repo, the .gitignore file will not hurt anybody.

[mbonnin]

+1 to .gitignore. Make it another question in the interactive CLI? Create a git repository? [*y*/n] (defaults to true)

[mbonnin]

I’d also put a good .idea default in .gitignore as well if that’s possible

[joffrey]

Generating only a .gitignore would be incorrect IMO. Either we generate .gitattributes as well or nothing, and maybe we should actually create a git repo (as in git init), but that's a bit more controversial.

[joffrey]

I like the idea of an interactive question, since I'm assuming this operation will rarely be used by "common users" in non-interactive places (maybe it will be used in some automation but then the defaults matter less).
Another possibility is to detect an existing .git folder and generate the git files automatically in that case (as a default behavior), then we could force-disable or force-enable explicitly.

[joffrey]

I'd like to understand better the real flow people follow when creating a new project with git.

@Marius Barbulescu @mbonnin @Fedor Ihnatkevich could you please share how you usually proceed? Would you create a project locally, then add a git repo, then push to GitHub (or some other service)? Would you first create the repo on GitHub (or other), then clone the empty repo, then add files locally? Something else?

[mbonnin]

I will use it all the time.

[mbonnin]

My typical use case for this is to create quick reproducers for issues.

[joffrey]

Then no git repo needed, just a zip to attach to an issue

[mbonnin]

I always publish those to github

[joffrey]

(I'm actually thinking of implementing a command to automatically report an issue on the last build, attach logs, and optionally the zipped sources)

[mbonnin]

Just because being able to do branches and PRs has tremendous value

[mbonnin]

But all my projects are in git really

[mbonnin]

It's very rare that I create a project without a matching git repo

[mbonnin]

The only place where that wouldn't be needed is for projects created in CI or automation because they're going to be deleted and you don't need the extra .git folder

[mbonnin]

But I never do this. All my code is under git

[joffrey]

Thanks for sharing Martin. So how do you usually proceed? Do you create the repo from the GitHub UI, then clone, then fill it up locally, commit, push? Or do you create everything locally (with git init) and then create the target repo on GitHub, add the remote, and push?

[mbonnin]

typical thing I do:

mkdir reproducer-1011
cd reproducer-1011
touch settings.gradle.kts
touch build.gradle.kts
idea .
# edit the code, idea will pull a Gradle wrapper, etc...
git init 
git add .
git commit -m "initial commit"
gh repo create
# push the repo to github

I want kotlin init to do steps 1-8 automagically. Then I only have to call gh repo create

[joffrey]

Thanks! Maybe one day I'll install the GitHub CLI 😅

[mbonnin]

It's quite handy

[mbonnin]

In the middle of all those steps above, I usually do something like this:

cp ../apollo-kotlin/.gitignore .

Because I spent some time fine tuning my Apollo Kotlin gitignore. But it'd be even better if kotlin init provides one

[mbonnin]

(I always get confused about how to commit the .idea/codeStyles directory mainly)

[mbonnin]

Maybe the decision is that we shouldn't use .idea/codeStyles but .editorconfig and this is fine by me.

[joffrey]

> I’d also put a good .idea default in .gitignore as well if that’s possible
While it's possible I would certainly not want to do that for 2 main reasons.

1. If you personally use IDEA and generally want to ignore .idea, that should be in your global config, so you don't pollute individual repos with IDE-specific config (not everyone uses this one, and the ones who do can ignore it on their machine)
2. .idea is a bastard folder that actually contains things you might want to share, so better add a .idea/.gitignore with proper settings depending on what you want to share in each project

[mbonnin]

Yea, agree it's complicated... but kotlin init is a great way to share an opinionated best practice there

[mbonnin]

not everyone uses this one, and the ones who do can ignore it on their machine

I don't like having every developer having to tune their machine. Ideally a checkout should work for all devs in the team regardless of the rest of the machine

[mbonnin]

Same reason we need JDK provisioning etc...

[joffrey]

But the problem is that there is no single best practice, because it depends on what you want to share in the specific project. Do you share run configs? Code style? Copyright config? I would ignore by default, personally, and add as I go.

[mbonnin]

it depends on what you want to share in the specific project. Do you share run configs? Code style? Copyright config?

Sounds like all of that needs to be shared?

[joffrey]

> I don't like having every developer having to tune their machine
It's not the same, because it's not project specific. The choice of IDE is a user choice, not a project choice. This is why I have my personal global gitignore and git config for my machines for the things that I choose to use.

[joffrey]

For example, I wouldn't want to gitignore the macOS (e.g. .DS_Store) in my project. It's something a responsible macOS user should globally ignore, not a project thing

[mbonnin]

I do have DS_store in my .gitignore 😄

[joffrey]

In your global machine-wide .gitignore is exactly where it should be, yes

[mbonnin]

I agree with the theory. In practice, it's a very small price to pay for Window users and helps a lot of folks

[joffrey]

There is no single project where you want this, no matter who maintains the project

[mbonnin]

But I'm not dying on this hill. I'm fine if .idea is not in .gitignore

[mbonnin]

I will die on the "git" hill though

[joffrey]

That's just my opinion, by the way, not the position of the team

[mbonnin]

code format is probably my main concern

[mbonnin]

If kotlin init could come with good defaults, that'd be great

[joffrey]

that will eventually be solved by ktfmt I guess

[mbonnin]

Yea, especially now that there is ktfmt

[François]

You mean just like swift init CLI does? it creates a working .gitignore

.DS_Store
/.build
/Packages
xcuserdata/
DerivedData/
.swiftpm/configuration/registries.json
.swiftpm/xcode/package.xcworkspace/contents.xcworkspacedata
.netrc

[mbonnin]

That is what create-react-app is doing:

/node_modules
/.pnp
.pnp.js

# testing
/coverage

# production
/build

# misc
.DS_Store
.env.local
.env.development.local
.env.test.local
.env.production.local

npm-debug.log*
yarn-debug.log*
yarn-error.log*

[Marius Barbulescu]

I usually create a github repo in the browser, run git clone ... and then I create the project.

[joffrey]

> I usually create a github repo in the browser, run git clone ... and then I create the project.
Same flow for me usually. The reason I'm asking is that, in that case, we can detect the presence of an existing git repo, and we could generate git config files accordingly.

But it also shows the conflicting responsibilities: on GitHub you'll get to choose a gitignore template. It makes sense because they are responsible for the git stuff, so they let you configure git. The Kotlin CLI is responsible for the Kotlin project config, and that's why so far we stuck with Kotlin Toolchain config files. So philosophically, we're not supposed to do that. But of course we want to be pragmatic here, and help where we can.

[Marius Barbulescu]

Maybe this is a particular case on customization hooks for a particular individual or a large organization (e.g. custom maven repo, custom release process, ...).

[mbonnin]

I'd like kotlin init to take a dir parameter:

kotlin init my-app

and fail if the directory already exists

[mbonnin]

Actually, it's more kotlin create in that case

[mbonnin]

kotlin create my-app

[mbonnin]

This removes any ambiguity conflicting state, etc...

[mbonnin]

It's all functional without side effects!

[joffrey]

Yeah I'm also mildly annoyed by the current behavior of init 🙂 We'll surely do something about it. It's also so easy to run kotlin init in a parent directory by mistake and create a mess

[joffrey]

So yes, maybe we could introduce a new command or a new option to create the project in a given directory. But also I think it might be worth improving kotlin init to detect existing files and ask for confirmation or fail in this case (we could exclude common files from that check, like README[.md], LICENSE[.md], .git, .gitignore, .gitattributes, etc.).