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

blaming parent uses wrong filename when in subdir #70

Closed
peff opened this issue Jul 26, 2012 · 1 comment
Closed

blaming parent uses wrong filename when in subdir #70

peff opened this issue Jul 26, 2012 · 1 comment

Comments

@peff
Copy link
Contributor

peff commented Jul 26, 2012

If tig is started in a subdirectory of the project, doing tig blame foo.c will work just fine, reading subdir/foo.c. But when using REQ_PARENT to re-blame starting at the parent, tig pulls the filename from git's blame output, which has the full pathname. As a result, we end up trying to blame subdir/subdir/foo.c.

You can replicate easily in tig with:

$ cd contrib
$ tig blame release.sh

and then using , to blame the parent of any modified line (e.g., the copyright line near the top). Tig will die with tig: No blame exist for contrib/contrib/release.sh.

@jonas
Copy link
Owner

jonas commented Aug 10, 2012

Yes, verified.

jonas pushed a commit that referenced this issue Aug 10, 2012
When running "tig blame" from within a subdirectory of a repository, the
"B" and "," commands will fail with "No blame exist for...". The problem
is that the current directory name gets prepended to the filename if
view->prev == NULL, but it should not be in this case.

Steps to reproduce:
1) checkout a copy of tig
2) cd contrib
3) run "tig blame tig-completion.bash"
4) press B
5) observe "tig: No blame exist for contrib/contrib/tig-completion.bash"

Also fixes another minor bug in an expression.

Signed-off-by: Jonas Fonseca <[email protected]>
@jonas jonas closed this as completed Aug 10, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants