Skip to content
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.

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

porcelain.add no longer works when run within a directory ignored by a gitignore #550

Open
Julian opened this issue Aug 15, 2017 · 4 comments
Assignees
Labels
Milestone

Comments

@Julian
Copy link
Contributor

Julian commented Aug 15, 2017

porcelain.add appears to use os.path.relpath to try to calculate relative paths relative to a repo root, but that's not what os.path.relpath does. E.g.:

⊙  cd /tmp; python -c 'import os.path; print os.path.relpath("foo", "/foo/bar")'; cd ~; python -c 'import os.path; print os.path.relpath("foo", "/foo/bar")'                                                                                                                                                                                                Julian@Macnetic
../../private/tmp/foo
../../Users/Julian/foo

so if previously something was running porcelain.add(repo=somerepo, paths=["somepath"]) (and since repo.paths are absolute), the file is now ignored incorrectly if cwd happens to be a directory ignored by gitignore.

@jelmer
Copy link
Owner

jelmer commented Aug 18, 2017

The new behaviour is intentional, since it matches the behaviour of the git command line tool. Relative paths are interpreted relative to PWD,but need to be relative to the root of the repository when passed into other Dulwich functions.

However, paths outside of the repository are currently silently ignored, but should probably trigger an exception.

I'll also add a clear warning in NEWS.

@jelmer jelmer added this to the soon milestone Aug 19, 2017
@jelmer jelmer self-assigned this Aug 19, 2017
@Julian
Copy link
Contributor Author

Julian commented Aug 31, 2017

Still have to play around here, but it seems a bit odd to me to be worrying about PWD -- that makes sense for a CLI, but for a library it's unnecessary global state to deal with.

Some other things besides add are giving us trouble in our unit tests now, so some other behavior seems to have changed as well (particularly in porcelain.status as well, where lots of things are being marked as "untracked" now even though they're tracked, so something's getting confused about a relative path).

Realize that's not enough to go on, will have to dig in further to decypher whether it's our fault or not here.

@jelmer
Copy link
Owner

jelmer commented Nov 5, 2017

porcelain is supposed to mostly resemble the cli.

one option would be to require paths are always absolute.

@jelmer jelmer added the bug label Nov 7, 2017
@eschwartz
Copy link

@jelmer - I think I may be hitting this as well, and porcelain is not acting like the git CLI.

I have a global ~/.gitignore file, with the following line:

tmp/

Now, if I run this python code:

# Initialize a git repo in /tmp dir
repo = porcelain.init("/tmp/my-repo")

# Add a file to the repo
f = open('/tmp/my-repo/file.txt', 'w')
f.write('some content')
f.close()

# get the repo status
status = porcelain.status(repo)

assert status.untracked == []  # true

So porcelain does not detect any files within my repo.
However, if I run a git status from repo, the untracked file does show up:

$ cd /tmp/my-repo
$ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	file.txt

If I empty my .gitignore, porcelain works as expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants