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

Git status shows all files as untracked #598

Closed
alistair-broomhead opened this issue Jan 4, 2018 · 2 comments · May be fixed by #601
Closed

Git status shows all files as untracked #598

alistair-broomhead opened this issue Jan 4, 2018 · 2 comments · May be fixed by #601
Labels

Comments

@alistair-broomhead
Copy link
Contributor

This is observed using a fresh pipenv with only dulwich==0.18.6 installed using python3.6 from pyenv on OSX

This is obviously not consistent with the way that git itself describes the repository state. Is this by design or a known issue? Are there any known work-arounds? If not I'm happy to give any spare cycles to have a dig into improving things, even if that's just by contributing docs.

bash-3.2$ > ls -l && \
git status && \
python3 -c 'import dulwich.porcelain; print(dulwich.porcelain.status("."))'
total 16
-rw-r--r--  1 al  staff   166  4 Jan 17:50 Pipfile
-rw-r--r--  1 al  staff  1264  4 Jan 17:50 Pipfile.lock
-rw-r--r--  1 al  staff     0  4 Jan 17:46 bar
-rw-r--r--  1 al  staff     0  4 Jan 17:46 foo
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   bar

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

	Pipfile
	Pipfile.lock

GitStatus(staged={'add': [b'bar'], 'delete': [], 'modify': []}, unstaged=[], untracked=['bar', 'foo', 'Pipfile', 'Pipfile.lock'])
@derSeddy
Copy link

derSeddy commented Jan 5, 2018

I stumbled upon this, too. I'm using python 2.7.6 and the latest dulwich from git on Ubun tu 16.04. This is the test code I wrote:

import os
import tempfile
import shutil

folder = tempfile.mkdtemp()
porcelain.init(folder)

print '1:'
with porcelain.open_repo_closing(folder) as repo:
    print porcelain.status(repo)
os.system('cd ' + folder + '; git status');

f = open(folder + '/test', 'w')
f.close()

print '2:'
with porcelain.open_repo_closing(folder) as repo:
    print porcelain.status(repo)
os.system('cd ' + folder + '; git status');

with porcelain.open_repo_closing(folder) as repo:
    status = porcelain.status(repo)
    repo.stage(status.unstaged + status.untracked)
    porcelain.commit(repo, 'test')
    
print '3:'
with porcelain.open_repo_closing(folder) as repo:
    print porcelain.status(repo)
os.system('cd ' + folder + '; git status');

shutil.rmtree(folder)

This is the output:

1:
GitStatus(staged={'add': [], 'modify': [], 'delete': []}, unstaged=[], untracked=[])
On branch master

Initial commit

nothing to commit (create/copy files and use "git add" to track)
2:
GitStatus(staged={'add': [], 'modify': [], 'delete': []}, unstaged=[], untracked=['test'])
On branch master

Initial commit

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

	test

nothing added to commit but untracked files present (use "git add" to track)
3:
GitStatus(staged={'add': [], 'modify': [], 'delete': []}, unstaged=[], untracked=['test'])
On branch master
nothing to commit, working tree clean

@alistair-broomhead
Copy link
Contributor Author

Glad to hear at least it's not just me - I've not looked at anything today, but I might clone this repo and have a poke around the existing tests tomorrow

alistair-broomhead added a commit to alistair-broomhead/dulwich that referenced this issue Jan 6, 2018
Looking at the code in porcelain.path_to_tree_path,
this looks like there was an attempt at this in
85b5383, however
relpath is non-destructive, and has no effect unless
the result is assigned to something. If this were
assigned when path is relative, then relpath would
assume path was at root, and so we must check that
the path is absolute before calling relpath.

Fixes jelmer#598
alistair-broomhead added a commit to alistair-broomhead/dulwich that referenced this issue Jan 13, 2018
Looking at the code in porcelain.path_to_tree_path,
this looks like there was an attempt at this in
85b5383, however
relpath is non-destructive, and has no effect unless
the result is assigned to something. If this were
assigned when path is relative, then relpath would
assume path was at root, and so we must check that
the path is absolute before calling relpath.

Fixes jelmer#598
@jelmer jelmer added the bug label Jan 22, 2018
@jelmer jelmer closed this as completed in 8d82f4f Jul 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants