15 ms·

This is my favourite feature of gitignores. Everytime I need "drafts", sample code, etc, in a repo, I create a folder in that repo, but then I have to remember

by rpigab 4y ago

This is my favourite feature of gitignores. Everytime I need "drafts", sample code, etc, in a repo, I create a folder in that repo, but then I have to remember to not add it to commits, and I don't want to add it to the .gitignore that is versioned, so I do "mkdir drafts && echo '*' > ./drafts/.gitignore", and it ignores my drafts without having to add a new ignored dir in the versioned .gitignores. And obviously, it also "ignores" the .gitignore itself because it matches "*", while still taking it into account, which is what I need.

RupertWiser 4y ago
Do you know about .git/info/exclude? It only exists in your local git file so it isn’t shared with a remote repo and achieves this same purpose.
- rpigab 4y ago
  I didn't! Good to know, even if my way is really quick and simple to set up so I might continue doing the same. Thanks!
- Hamuko 4y ago
  I also (mis)used .gitignore before I realised that there was an easy way to ignore stuff that I have locally without having to commit/ignore a .gitignore file.
- dfee 4y ago
  Not at a term, but would this prevent `git clean -fdx` from removing the dir? That’d be quite useful!
  - deleted 4y ago
    [deleted]
  - CGamesPlay 4y ago
    No, since -x means to “disregard standard ignore rules”, such as .gitignore and .git/info/exclude. > Don’t use the standard ignore rules (see gitignore[5]), but still use the ignore rules given with -e options from the command line.
Dobbs 4y ago
Additionally git supports a global git ignore. $ git config --global core.excludesfile ~/.gitignore Then you can put all the standard things you want to ignore into it: $ cat ~/.gitignore .DS_Store ./drafts/ *.swp And it will apply to all git commands on your computer.
- sph 4y ago
  I also got in my ~/.gitignore: .envrc # direnv, where I store my local project configuration .vscode and when I remember to use them: *.gitlocal *.gitlocal* To store files and directories I don't ever want to push, mostly for scratch files and logs
  - AlfeG 4y ago
    Why to ignore .vscode? We collect there workspace wide team settings.
    - sph 4y ago
      I don't think editor-related settings should be committed, unless it's a company repo and everybody is forced to use the same editor. Otherwise all projects would be littered with .vscode, .atom, .sublime, .dir-locals.el, etc. which isn't great. Anyway, stuff in .gitignore can still be added to the index if you so wish.
      - downsidesabound 4y ago
        If almost everyone uses some editor, then it’s not really “littered”. We do the same and it’s nice for new teammates to quickly get set up. If they are one of the few folks that want to use some other editor, who cares? Files are free.
        pjerem 4y ago
        When almost everyone uses the same editor, it doesn't mean that everyone wants to have the same configuration. Editors and IDEs are crafting tools. Crafting tools are meant to be mastered by workers (here: developers), not to enforce some team/company policy. There are tools that already exists to enforce team policies like formatters, linters and so on. These tools generally integrate well with your editor of choice and can also be integrated on your CI pipelines.
pcthrowaway 4y ago
I'm in the habit of just adding these things directly to .gitignore for repos which I'm a core contributor to. Things like: drafts/ backup/ *.bak ignored/ etc. I don't really see the downside to just adding them to the tracked gitignore. If other people have a different convention and want to add these files/paths for some reason, it's easily discoverable to them why the files can't be added, and then we can have a discussion about what naming conventions we want.
- AndrewThrowaway 4y ago
  The only problem I can see it "leaking" some information? "I see this guy has 'passwords/'" on his local machine, let's somehow sneakily merge new .gitignore to make them available publicly.
  - asddubs 4y ago
    sure, if "this guy" does "git add '*'" and neither reviews the commit, nor even does git status to see a file list of it and just pushes it straight to remote. if that's happening i think your repo might have other problems though
  - pcthrowaway 4y ago
    I mean this doesn't really leak anything; passwords are usually stored in `.env` files anyway
    - naavis 4y ago
      It's not exactly best practice to store passwords in version control.
      - pcthrowaway 4y ago
        yes I'm aware.. this is why .env should always be in .gitignore
alex_smart 4y ago
I mean this is only a problem if your commit work flow is "git add . && git commit". A bad habit, in my opinion.
- TowerTall 4y ago
  This is what I do. Is there a "better" habit?
  - Hamuko 4y ago
    I quite like my habit of adding stuff with `git add --patch` since it forces me to re-read stuff before I commit it. Graphical git clients like Fork or Sourcetree also allow to commit stuff in chunks.
    - kilroy123 4y ago
      Agreed. This is the only way I ever add anything.
  - muhbaasu 4y ago
    Try `git add --patch` (or just `-p`). git will go through each change and you can decide if you want to stage it. You can even stage individual changes in a file. This doesn't cover new files though. For those you can use `git add $filename` or even globs with `git add src/some/dir/*.$extension`.
    - sgammon 4y ago
      came here to say this, git add -p is such a brilliant thing. alias ga="clear ; git add -p" is an alias i always seem to keep
    - fgeiger 4y ago
      For new files I use `git add -N` (if memory serves right; I am on mobile) to mark them as "I want this file to be included in `git add -p`" Edit: The flag is -N or --intent-to-add
AndrewThrowaway 4y ago
I think this is quite genius, never thought about it before.
bhrgunatha 4y ago
Thanks for sharing that idea. I'd simply never thought to do this and I'm adopting this in future. The main drawback is something I do from time-to-time which is nuking and re-creating directories.
Deradon 4y ago
Another comment already mentioned the `.git/info/exclude` directory. For completeness link to the online docs: https://git-scm.com/docs/gitignore https://git-scm.com/docs/gitignore git will take 3 files into consideration for "ignoring" files: > $XDG_CONFIG_HOME/git/ignore, $GIT_DIR/info/exclude, .gitignore How I use them: * ~/.gitignore: stuff I want to ignore everywhere (`/myNotes`, `.DS_STORE`, ...) * <project>/.gitignore: stuff that should be ignore for this projects and shared with others * <project>/.git/info/exclude; stuff for this project that only I want to ignore ** this is also super useful in combination with `git-bisect`
frays 4y ago
This is a fantastic tip, thanks!
rollcat 4y ago
This is my strategy for dotfiles. My home directory has a .gitignore with "*" in it. I will "git add -f" any files I want tracked; git is extremely efficient at ignoring the rest. It doesn't require any frameworks, symlinks, installation scripts, elaborate tutorials/manpages, or any other voodoo. To move in to a new machine - unfortunately you can't git clone into a non-empty directory, but the commands to work around that are simple enough to remember. https://github.com/rollcat/dotfiles https://github.com/rollcat/dotfiles
- JoshTriplett 4y ago
  I prefer to list individual directories and files in my ~/.gitignore so that I see when new files show up and I can decide whether to ignore them, commit them, or prevent them from getting generated.
  - rollcat 4y ago
    It tends to blow up "git status" if some random new piece of software (or random me) makes a random new subfolder, full of random things. You can override .gitignore for specific subfolders like .config, .emacs.d, etc.
    - burntsushi 4y ago
      That's what I used to do, but I switched to Josh's strategy a couple years ago.[1] It doesn't "blow up" git-status. If some new piece of software creates a new directory with a bunch of random stuff in it, git-status will just show you the directory since it is is untracked, and not everything in it. [1]: https://github.com/BurntSushi/dotfiles/blob/965383e6eeb0bad40d10448ce57f040825f735a7/.gitignore https://github.com/BurntSushi/dotfiles/blob/965383e6eeb0bad4...
jerrygoyal 4y ago
> mkdir drafts && echo '' > ./drafts/.gitignore thanks for the tip, is there a way to hide files at root level? I want to hide some .env. files
michaelsalim 4y ago
This is awesome! Will probably use this at some point. Thanks for sharing.
molszanski 4y ago
brilliant! Thank you!
Robin_Message 4y ago
.git/info/exclude is a local .gitignore file which is never committed which you can also use for this kind of purpose.
miskreant 4y ago
You can also add lines to `.git/info/exclude` for permanent, local only ignores for a specific repo.
thayne 4y ago
That's cool! You can also put local gitignore rules in .git/info/exclude , but i have a hard time remembering that exact path for some reason.

by rpigab 4y ago

RupertWiser 4y ago

Do you know about .git/info/exclude? It only exists in your local git file so it isn’t shared with a remote repo and achieves this same purpose.

rpigab 4y ago
I didn't! Good to know, even if my way is really quick and simple to set up so I might continue doing the same. Thanks!
Hamuko 4y ago
I also (mis)used .gitignore before I realised that there was an easy way to ignore stuff that I have locally without having to commit/ignore a .gitignore file.
dfee 4y ago
Not at a term, but would this prevent `git clean -fdx` from removing the dir? That’d be quite useful!
- deleted 4y ago
  [deleted]
- CGamesPlay 4y ago
  No, since -x means to “disregard standard ignore rules”, such as .gitignore and .git/info/exclude. > Don’t use the standard ignore rules (see gitignore[5]), but still use the ignore rules given with -e options from the command line.

Dobbs 4y ago

Additionally git supports a global git ignore. $ git config --global core.excludesfile ~/.gitignore Then you can put all the standard things you want to ignore into it: $ cat ~/.gitignore .DS_Store ./drafts/ *.swp And it will apply to all git commands on your computer.

sph 4y ago
I also got in my ~/.gitignore: .envrc # direnv, where I store my local project configuration .vscode and when I remember to use them: *.gitlocal *.gitlocal* To store files and directories I don't ever want to push, mostly for scratch files and logs
- AlfeG 4y ago
  Why to ignore .vscode? We collect there workspace wide team settings.
  - sph 4y ago
    I don't think editor-related settings should be committed, unless it's a company repo and everybody is forced to use the same editor. Otherwise all projects would be littered with .vscode, .atom, .sublime, .dir-locals.el, etc. which isn't great. Anyway, stuff in .gitignore can still be added to the index if you so wish.
    - downsidesabound 4y ago
      If almost everyone uses some editor, then it’s not really “littered”. We do the same and it’s nice for new teammates to quickly get set up. If they are one of the few folks that want to use some other editor, who cares? Files are free.
      - pjerem 4y ago
        When almost everyone uses the same editor, it doesn't mean that everyone wants to have the same configuration. Editors and IDEs are crafting tools. Crafting tools are meant to be mastered by workers (here: developers), not to enforce some team/company policy. There are tools that already exists to enforce team policies like formatters, linters and so on. These tools generally integrate well with your editor of choice and can also be integrated on your CI pipelines.

pcthrowaway 4y ago

I'm in the habit of just adding these things directly to .gitignore for repos which I'm a core contributor to. Things like: drafts/ backup/ *.bak ignored/ etc. I don't really see the downside to just adding them to the tracked gitignore. If other people have a different convention and want to add these files/paths for some reason, it's easily discoverable to them why the files can't be added, and then we can have a discussion about what naming conventions we want.

AndrewThrowaway 4y ago
The only problem I can see it "leaking" some information? "I see this guy has 'passwords/'" on his local machine, let's somehow sneakily merge new .gitignore to make them available publicly.
- asddubs 4y ago
  sure, if "this guy" does "git add '*'" and neither reviews the commit, nor even does git status to see a file list of it and just pushes it straight to remote. if that's happening i think your repo might have other problems though
- pcthrowaway 4y ago
  I mean this doesn't really leak anything; passwords are usually stored in `.env` files anyway
  - naavis 4y ago
    It's not exactly best practice to store passwords in version control.
    - pcthrowaway 4y ago
      yes I'm aware.. this is why .env should always be in .gitignore

alex_smart 4y ago

I mean this is only a problem if your commit work flow is "git add . && git commit". A bad habit, in my opinion.

TowerTall 4y ago
This is what I do. Is there a "better" habit?
- Hamuko 4y ago
  I quite like my habit of adding stuff with `git add --patch` since it forces me to re-read stuff before I commit it. Graphical git clients like Fork or Sourcetree also allow to commit stuff in chunks.
  - kilroy123 4y ago
    Agreed. This is the only way I ever add anything.
- muhbaasu 4y ago
  Try `git add --patch` (or just `-p`). git will go through each change and you can decide if you want to stage it. You can even stage individual changes in a file. This doesn't cover new files though. For those you can use `git add $filename` or even globs with `git add src/some/dir/*.$extension`.
  - sgammon 4y ago
    came here to say this, git add -p is such a brilliant thing. alias ga="clear ; git add -p" is an alias i always seem to keep
  - fgeiger 4y ago
    For new files I use `git add -N` (if memory serves right; I am on mobile) to mark them as "I want this file to be included in `git add -p`" Edit: The flag is -N or --intent-to-add

AndrewThrowaway 4y ago

I think this is quite genius, never thought about it before.

bhrgunatha 4y ago

Thanks for sharing that idea. I'd simply never thought to do this and I'm adopting this in future. The main drawback is something I do from time-to-time which is nuking and re-creating directories.

Deradon 4y ago

Another comment already mentioned the `.git/info/exclude` directory. For completeness link to the online docs: https://git-scm.com/docs/gitignore https://git-scm.com/docs/gitignore git will take 3 files into consideration for "ignoring" files: > $XDG_CONFIG_HOME/git/ignore, $GIT_DIR/info/exclude, .gitignore How I use them: * ~/.gitignore: stuff I want to ignore everywhere (`/myNotes`, `.DS_STORE`, ...) * <project>/.gitignore: stuff that should be ignore for this projects and shared with others * <project>/.git/info/exclude; stuff for this project that only I want to ignore ** this is also super useful in combination with `git-bisect`

frays 4y ago

This is a fantastic tip, thanks!

rollcat 4y ago

This is my strategy for dotfiles. My home directory has a .gitignore with "*" in it. I will "git add -f" any files I want tracked; git is extremely efficient at ignoring the rest. It doesn't require any frameworks, symlinks, installation scripts, elaborate tutorials/manpages, or any other voodoo. To move in to a new machine - unfortunately you can't git clone into a non-empty directory, but the commands to work around that are simple enough to remember. https://github.com/rollcat/dotfiles https://github.com/rollcat/dotfiles

JoshTriplett 4y ago
I prefer to list individual directories and files in my ~/.gitignore so that I see when new files show up and I can decide whether to ignore them, commit them, or prevent them from getting generated.
- rollcat 4y ago
  It tends to blow up "git status" if some random new piece of software (or random me) makes a random new subfolder, full of random things. You can override .gitignore for specific subfolders like .config, .emacs.d, etc.
  - burntsushi 4y ago
    That's what I used to do, but I switched to Josh's strategy a couple years ago.[1] It doesn't "blow up" git-status. If some new piece of software creates a new directory with a bunch of random stuff in it, git-status will just show you the directory since it is is untracked, and not everything in it. [1]: https://github.com/BurntSushi/dotfiles/blob/965383e6eeb0bad40d10448ce57f040825f735a7/.gitignore https://github.com/BurntSushi/dotfiles/blob/965383e6eeb0bad4...

jerrygoyal 4y ago

> mkdir drafts && echo '' > ./drafts/.gitignore thanks for the tip, is there a way to hide files at root level? I want to hide some .env. files

michaelsalim 4y ago

This is awesome! Will probably use this at some point. Thanks for sharing.

molszanski 4y ago

brilliant! Thank you!

Robin_Message 4y ago

.git/info/exclude is a local .gitignore file which is never committed which you can also use for this kind of purpose.

miskreant 4y ago

You can also add lines to `.git/info/exclude` for permanent, local only ignores for a specific repo.

thayne 4y ago

That's cool! You can also put local gitignore rules in .git/info/exclude , but i have a hard time remembering that exact path for some reason.