Re: .gitattributes on branch behaves unexpected. Should it be more stateless?

From: Max W <max.w.7777777@googlemail.com>
Date: Jan 18, 2015, 17:14 UTC
Message-ID: <CAGJ-DzFos0DHNettfSHp0HfCGKqC8agvqELezi6HLqWpob5f_g@mail.gmail.com>
In-Reply-To: <B551DC4135DC4DA3B8BA5E1BBA36BBEC@PhilipOakley>

Hi philip,

thanks for your reply.

> You don't say which parts you believe should be identical, nor why.

I expected my representation to be identical, nevertheless what path I have taken to come there. e.g. git clone -b <branch> git clone; git checkout <branch> should result in a binary-indentical representation of the files tracked by git. But they don't.

Why did I expect this? Good question. Feels more intuitive for me. Like "don't worry what you have done before. When your HEAD is on a certain commit, git will make sure all your files in your filesystem are they way you (and the other committers) want them to be".

> [..]
> Does that help?

Yes, it helped me to distinguish better between data and representation. New understanding: .gitattributes determines how to represent data.

As .gitattributes is under git control there can be 2 versions of
.gitattributes in 2 branches. So I can tell git
- on branch foo with gitattributes * eol=LF show me all files with LF
- on branch bar with gitattributes * eol=CRLF show me all files with CRLF
But this doesn't work. The representation of the files is
determined/depending on how I cloned or fetched the repo. A "git checkout
bar" does not change the representation.

Does this help to show where my concerns / my issue is?

Best Regards, Max

2015-01-17 14:16 GMT+01:00 Philip Oakley <philipoakley@iee.org>:

Show 139 quoted lines

>> Hi,
>>
>> I am asking myself if git and .gitattributes should be more stateless?
>> i.e.
>> whatever you have done before is irrelevant, when you reach status XYZ
>> with your
>> git repo, it is EXACTLY and BINARY the same all the time and everywhere.
>>
>> It took some time for me to figure out, that depending on HOW you clone,
>> the
>> resulting local repo may differ. I did not expect this. I assumed that
>> when I
>> clone, it is a clone (meaning: 100% identical). And that the things I have
>> done
>> in my local repo before, don't have any relevance at all.
>>
>
> You don't say which parts you believe should be identical, nor why.
>
> Internally Git can represent its object store in many ways based on some
> objects being 'loose' and some objects being 'packed'. However both styles
> of representation are of the same base objects and their contents.
>
> Then we have external OS representation, in particular the end of line
> representations between the three main OS types Win/Mac/'nix. Git gives
> _you_ the ability the use any of these representations for the same base
> objects. Thus the object file with text "Hello World/EOL/Goodbye World" will
> have three different binary representations once you export them to the
> selected file system type (according to you .gitattributes settings).
>
> If you always select LF endings for text files (both on the way in and on
> the way out of the repo), then you will get identical files on the different
> clones. Git has many settings for personalisation.
>
> Does that help?
>
>>
>>
>> ** How to reproduce **
>> 1) create a repo, add a file with LF ending, add a .gitattributes telling
>> git to
>>   do a CRLF conversion
>> 2) clone the repo
>> 3) on brach development, change .gitattributes to LF
>> 4) clone again
>> 5) clone again, directly onto the branch development (git clone -b)
>>
>>
>> ** Expected result, (I) **
>> clone 2) and original repo 1) are bytewise identical
>>
>> ** Actual result (I) **
>> clone 2) and original repo 1) differ, 1) has LF, 2) has CRLF
>> as I have been warned before, I am (more or less) fine/OK with this
>>
>>
>> ** Expected result, (II) **
>> - clone without -b (4) and clone with -b (5) are bytewise identical
>> - I would have expected, that whatever I do, as soon as I have a clone and
>> I am
>>  on branch "development", my file should be LF
>> - I would have expected, that HOW you clone is irrelevant
>>
>> ** Actual result (II) **
>> without -b (4) I have a CRLF file on my disk. with -b (5) I have a LF file
>> on my
>> disk. The clones are not bytewise indentical. It appears as if the
>> .gitattributes in branch development does not have any reliable effect.
>>
>>
>>
>> A potential solution might be be that
>> - checkout
>> - commit (a modified .gitattribues)
>> - <further git commands>
>>  do change the files in the local repo.
>> As of now my understanding is that this is not how .gitattributes (or
>> .gitignore) are designed. .gitattributes only has influence on
>> pushing/fetching.
>>
>> I don't know if and which side effects would occur if this design would be
>> changed. Hence I am glad to hear any feedback on the issue described
>> above. And
>> yes, I agree that this is a minor issue and that all .gitattribute things
>> are
>> kind of edge cases.
>>
>> Thanks and with best regards,
>> Max
>>
>>
>>
>>
>>
>>
>> 1)
>> mkdir git-bug-or-feature
>> cd git-bug-or-feature
>> git init
>> echo "foo.bar eol=crlf" > .gitattributes
>> echo "hello world" > foo.bar
>> git add .
>> git commit -m "now crlf"
>> # [master (root-commit) 7f3f6b0] now crlf
>> # warning: LF will be replaced by CRLF in foo.bar.
>> # The file will have its original line endings in your working directory.
>> file foo.bar
>> # foo.bar: ASCII text
>> cd ..
>>
>> 2)
>> git clone git-bug-or-feature git-bug-or-feature_clone
>> cd git-bug-or-feature_clone
>> file foo.bar
>> # foo.bar: ASCII text, with CRLF line terminators
>> cd ..
>> rm -rf git-bug-or-feature_clone
>>
>> 3)
>> cd git-bug-or-feature
>> git branch development
>> git checkout development
>> echo "foo.bar eol=lf" > .gitattributes
>> git add .
>> git commit -m "now lf on branch development"
>> file foo.bar
>> # foo.bar: ASCII text
>> git checkout master
>> file foo.bar
>> # foo.bar: ASCII text
>> cd ..
>>
>> 4)
>> git clone git-bug-or-feature git-bug-or-feature_clone
>> cd git-bug-or-feature_clone
>> file foo.bar
>> --
>
> philip