top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

git archive --worktree-attributes doesn't exclude .gitattributes anymore

0 votes
262 views

I write here because since my ubuntu update (quantal to raring) and git update from 1.7.10.4-1ubuntu1 to 1.8.1.2

my export script doesn't work anymore.

I tried to put .gitattributes or .git/info/attributes, the file is the following http://pastebin.com/irngA1L8

the git is

git clone http://boinc.berkeley.edu/git/boinc-v2.git

and the command is

git archive --prefix boinc-7.1.7+dfsg/ --format tgz -o ../boinc_7.1.7+dfsg.orig.tar.gz -9 client_release/7.1/7.1.7

The archive gets created, but every file is inside, no exclusions at all.

I suspect a regression between git 1.7 and 1.8

posted Jun 4, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

Yes, there was a regression with matching directory names in gitattributes in v1.8.1.1. The regression is fixed in v1.8.1.6 and above.

If upgrading is too hard, I think you can work around it by putting "win_build/" instead of "win_build" in your .gitattributes (after v1.8.1.6, both should work for your case).

answer Jun 5, 2013 by anonymous
Similar Questions
0 votes

I bumped into a problem where git grep thinks files in repo/a/data are binary files when it is invoked from repo/a and repo/data/.gitattributes contains "* binary".

I can reproduce this on 1.7.9.5 and 1.7.10.4. Unfortunately I don't have a newer version at hand.

How to reproduce:

[pseudo:~/tmp]% git --version
git version 1.7.10.4
[pseudo:~/tmp]% git init git-test
Initialized empty Git repository in /home/opqdonut/tmp/git-test/.git/
[pseudo:~/tmp]% cd git-test
[pseudo:~/tmp/git-test:master()]% mkdir -p a/data
[pseudo:~/tmp/git-test:master()]% mkdir data
[pseudo:~/tmp/git-test:master()]% echo '* binary' > data/.gitattributes
[pseudo:~/tmp/git-test:master()]% echo foo > a/data/foo
[pseudo:~/tmp/git-test:master()]% git add -A
[pseudo:~/tmp/git-test:master()]% git commit -m "foo"
[master (root-commit) 20fafbb] foo
 2 files changed, 1 insertion(+)
 create mode 100644 a/data/foo
 create mode 100644 data/.gitattributes
[pseudo:~/tmp/git-test:master()]% git grep foo
a/data/foo:foo
[pseudo:~/tmp/git-test:master()]% cd a
[pseudo:~/tmp/git-test/a:master()]% git grep foo
Binary file data/foo matches
+1 vote

I'm using git 1.9.1 in Ubuntu 14.04.

I have a repository on github, a clone on my desktop and bare repo on a private server, in my desktop the remotes looks like this

all git@github.com:user/repo.git (fetch)
all git@github.com:user/repo.git (push)
all user@server.com:user/repo.git (push)
server user@server.com:user/repo.git (fetch)
server user@server.com:user/repo.git (push)
origin git@github.com:user/repo.git (fetch)
origin git@github.com:user/repo.git (push)

If I commit to master in my desktop and run 'git push all master', the github and the server repos are correctly updated, but if I run 'git status' the message says:

Your branch is ahead of 'origin/master' by 1 commit.
 (use "git push" to publish your local commits)

The message won't update unless I run git fetch or git push origin master. I'd expect the git status to give me a updated status message after calling 'git push all master'.

+2 votes

I just want to know why GIT doesnt track read/write permission? What I want is just GIT keep what every I checked in? ( I am OK with the executable permission control)

+1 vote

When run that command immediate after "git bisect start" somebody sees the full commit range as defined in "git bisect start".

However running that command later after few git bisect steps" somebody is just presented with the remaining commit interval. Is this intended ?

–1 vote

Running "git rev-parse --show-toplevel" doesn't print anything when it is run inside .git dir (on all levels)

...