New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Global .gitignore not respected #87

Closed

arxanas opened this issue Feb 26, 2022 · 2 comments

Contributor

arxanas commented Feb 26, 2022

Expected Behavior

jj status shows files which should be globally ignored:

$ jj status
...
A bin/.DS_Store
A tests/.DS_Store

Actual Behavior

jj status should respect global .gitignore file by default.

Steps to Reproduce the Problem

git config --global core.excludesfile ~/.gitignore_global
jj init --git-repo=.
touch .DS_Store
jj st

The same problem happens even if I create ~/.gitignore.

Specifications

Version: jj 0.2.0 @ aadab1982dd7deaca7c20ba9d4c5e908115d7ba0
Platform: macOS 11.6.4

The text was updated successfully, but these errors were encountered:

Member

martinvonz commented Feb 26, 2022 •

edited

Loading

Git's config in general is ignored, so step 1 will have no effect. We should probably respect some of them to make transitioning easier.

~/.gitignore should be respected, however. If you edited it after the file had already been added to the working copy commit, try running jj untrack <paths>.

Member

martinvonz commented Mar 4, 2022

I just found realized that ~/.gitignore doesn't seem to be anywhere in Git's documentation of how ignores work, so I suspect I just hard-coded the location it happened to have on my system. Oops.

By the way, this bug is very closely related to #65, so I'll probably fix both at around the same time (but probably not the same commit).

martinvonz added a commit that referenced this issue


          gitignore: move function for chaining .gitignore to central place (#65,

9bf2ffd

#87)

I want to be able to reuse the code for chaining two `.gitignore`
files outside of `working_copy.rs`.

martinvonz added a commit that referenced this issue


          cli: add a WorkspaceCommandHelper::edit_diff() proxy (#65, #87)

50bdba9

I'm about to make callers pass in "base" Git ignores when writing a
tree from the working copy. `edit_diff()` will then need to pass
that. It'll be easier to do that if we have a proxy on
`WorkspaceCommandHelper`.

martinvonz added a commit that referenced this issue


          gitignore: move function for chaining .gitignore to central place (#65,

4772b97

#87)

I want to be able to reuse the code for chaining two `.gitignore`
files outside of `working_copy.rs`.

martinvonz added a commit that referenced this issue


          cli: add a WorkspaceCommandHelper::edit_diff() proxy (#65, #87)

71bef02

I'm about to make callers pass in "base" Git ignores when writing a
tree from the working copy. `edit_diff()` will then need to pass
that. It'll be easier to do that if we have a proxy on
`WorkspaceCommandHelper`.

martinvonz added a commit that referenced this issue


          working_copy: let caller pass in base Git ignores (#65, #87)

20f90da

The library crate shouldn't look up the user's `$HOME` directory
(maybe the library is used by a server process), so let's have the
caller pass it into the library crate instead.

martinvonz added a commit that referenced this issue


          cli: respect Git's core.excludesFile config (#87)

4af842d

It probably doesn't make sense to respect Git's `core.excludesFile`
config when not running in a Git-backed repo, but we also already
respect `.gitignore` files in the working copy regardless of backend,
so at least it's consistent with that. We can revisit it when the
native backend becomes a reasonable choice.

Closes #87.

martinvonz added a commit that referenced this issue


          gitignore: move function for chaining .gitignore to central place (#65,

9f36faa

#87)

I want to be able to reuse the code for chaining two `.gitignore`
files outside of `working_copy.rs`.

martinvonz added a commit that referenced this issue


          cli: add a WorkspaceCommandHelper::edit_diff() proxy (#65, #87)

7f8270c

I'm about to make callers pass in "base" Git ignores when writing a
tree from the working copy. `edit_diff()` will then need to pass
that. It'll be easier to do that if we have a proxy on
`WorkspaceCommandHelper`.

martinvonz added a commit that referenced this issue


          working_copy: let caller pass in base Git ignores (#65, #87)

81c769b

The library crate shouldn't look up the user's `$HOME` directory
(maybe the library is used by a server process), so let's have the
caller pass it into the library crate instead.

martinvonz added a commit that referenced this issue


          cli: respect Git's core.excludesFile config (#87)

60503ff

It probably doesn't make sense to respect Git's `core.excludesFile`
config when not running in a Git-backed repo, but we also already
respect `.gitignore` files in the working copy regardless of backend,
so at least it's consistent with that. We can revisit it when the
native backend becomes a reasonable choice.

Closes #87.

martinvonz added a commit that referenced this issue


          gitignore: move function for chaining .gitignore to central place (#65,

b63e8d1

#87)

I want to be able to reuse the code for chaining two `.gitignore`
files outside of `working_copy.rs`.

martinvonz added a commit that referenced this issue


          cli: add a WorkspaceCommandHelper::edit_diff() proxy (#65, #87)

7f3ee6c

I'm about to make callers pass in "base" Git ignores when writing a
tree from the working copy. `edit_diff()` will then need to pass
that. It'll be easier to do that if we have a proxy on
`WorkspaceCommandHelper`.

martinvonz added a commit that referenced this issue


          working_copy: let caller pass in base Git ignores (#65, #87)

92329b2

The library crate shouldn't look up the user's `$HOME` directory
(maybe the library is used by a server process), so let's have the
caller pass it into the library crate instead.

martinvonz added a commit that referenced this issue


          cli: respect Git's core.excludesFile config (#87)

It probably doesn't make sense to respect Git's `core.excludesFile`
config when not running in a Git-backed repo, but we also already
respect `.gitignore` files in the working copy regardless of backend,
so at least it's consistent with that. We can revisit it when the
native backend becomes a reasonable choice.

Closes #87.

martinvonz added a commit that referenced this issue


          cli: respect Git's core.excludesFile config (#87)

1c611a0

It probably doesn't make sense to respect Git's `core.excludesFile`
config when not running in a Git-backed repo, but we also already
respect `.gitignore` files in the working copy regardless of backend,
so at least it's consistent with that. We can revisit it when the
native backend becomes a reasonable choice.

Closes #87.

martinvonz added a commit that referenced this issue


          gitignore: move function for chaining .gitignore to central place (#65,

5926a1e

#87)

I want to be able to reuse the code for chaining two `.gitignore`
files outside of `working_copy.rs`.

martinvonz added a commit that referenced this issue


          cli: add a WorkspaceCommandHelper::edit_diff() proxy (#65, #87)

f5ee4a3

I'm about to make callers pass in "base" Git ignores when writing a
tree from the working copy. `edit_diff()` will then need to pass
that. It'll be easier to do that if we have a proxy on
`WorkspaceCommandHelper`.

martinvonz added a commit that referenced this issue


          working_copy: let caller pass in base Git ignores (#65, #87)

0171f5f

The library crate shouldn't look up the user's `$HOME` directory
(maybe the library is used by a server process), so let's have the
caller pass it into the library crate instead.

martinvonz added a commit that referenced this issue


          cli: respect Git's core.excludesFile config (#87)

8b9cc1b

It probably doesn't make sense to respect Git's `core.excludesFile`
config when not running in a Git-backed repo, but we also already
respect `.gitignore` files in the working copy regardless of backend,
so at least it's consistent with that. We can revisit it when the
native backend becomes a reasonable choice.

Closes #87.

martinvonz added a commit that referenced this issue


          cli: respect Git's core.excludesFile config (#87)

f93c369

It probably doesn't make sense to respect Git's `core.excludesFile`
config when not running in a Git-backed repo, but we also already
respect `.gitignore` files in the working copy regardless of backend,
so at least it's consistent with that. We can revisit it when the
native backend becomes a reasonable choice.

Closes #87.

martinvonz added a commit that referenced this issue


          cli: respect Git's core.excludesFile config (#87)

d57d31f

It probably doesn't make sense to respect Git's `core.excludesFile`
config when not running in a Git-backed repo, but we also already
respect `.gitignore` files in the working copy regardless of backend,
so at least it's consistent with that. We can revisit it when the
native backend becomes a reasonable choice.

Closes #87.

martinvonz added a commit that referenced this issue


          gitignore: move function for chaining .gitignore to central place (#65,

51da2a2

#87)

I want to be able to reuse the code for chaining two `.gitignore`
files outside of `working_copy.rs`.

martinvonz added a commit that referenced this issue


          cli: add a WorkspaceCommandHelper::edit_diff() proxy (#65, #87)

2291bff

I'm about to make callers pass in "base" Git ignores when writing a
tree from the working copy. `edit_diff()` will then need to pass
that. It'll be easier to do that if we have a proxy on
`WorkspaceCommandHelper`.

martinvonz added a commit that referenced this issue


          working_copy: let caller pass in base Git ignores (#65, #87)

d56ae79

The library crate shouldn't look up the user's `$HOME` directory
(maybe the library is used by a server process), so let's have the
caller pass it into the library crate instead.

martinvonz closed this as completed in

martinvonz added a commit that referenced this issue


          docs: Update section about support for .gitignores

4e55f56

Issues #65 and #87 were both fixed almost a year ago.

martinvonz mentioned this issue

docs: Update section about support for .gitignores #1327

Merged

4 tasks

martinvonz added a commit that referenced this issue


          docs: Update section about support for .gitignores

e3a9617

Issues #65 and #87 were both fixed almost a year ago.

arxanas mentioned this issue

FR: Support git status-based working copy snapshotting #2920

Open

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