git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Torsten Bögershausen" <tboegi@web.de>
To: tvie@ivision.de, git@vger.kernel.org
Subject: Re: end-of-line diff checkout direction dependence problem
Date: Tue, 30 Jun 2015 16:41:23 +0200	[thread overview]
Message-ID: <5592AA93.9090002@web.de> (raw)
In-Reply-To: <5592A3D9.3080706@ivision.de>

On 2015-06-30 16.12, Thomas Vieten wrote:
> We face a very inconvenient problem with end-of-line diffs which are not "real".
> We know the end-of-line problem very well as we thought.
> But now we found a new phenomenon and nobody mentioning it.
> 
> Consider the following repository structure:
> 
>           -----------|----|------------->branch1
>         /
> master
>         \
> ----------|-------|---------|--------------->branch2
> 
> The branches are based on master/head.
> We just consider one branch here, e.g. branch1 .
> 
> Working with the head of branch1 gives no problems. No end-of-line diffs.
> Also going back in the direction of master - no problems.
> Only in the case if we do a checkout from branch1 to master, then
> all of a sudden end-of-line diffs appear.
> The files might be changed, but the end-of-line attributes in gitattributes are
> not changed in the branch.
> 
> It seems to be the case that since the last change to the files which pop up
> with eol differences, gittattributes where changed and touch their extensions.
> 
> With the operation
> 
> git ls-files -z | xargs -0 rm -f  # delete all the files of this version - here
> master/head
> git reset --hard                  # force checkout of master/head and reset index
> 
> The problem disappears! No eol problems anymore. Something like a brute force
> checkout.
> 
> Also checking out versions in the direction of branch1 give never end-of-line
> diffs.
> 
> What has changed somewhen are the gitattributes.
> 
> We estimate that this becomes a problem when applying the diffs from branch1 in
> the direction of
> the master. Finally then the diffs result in a different state from the master.
> 
> But when the master is checked out freshly, this difference does not appear.
> 
> Very, very annoying.
> 
> We check now every time when these end-of-line diffs appear, if they are really
> end of line diffs
> 
> git diff --ignore-space-at-eol
> 
> and then try the procedure above.
> 
> But to have a dependence from the direction of the checkout is somewhat irritating.
> 
> If this is not a bug - then how to avoid it ?
> 
> bye for now
> 
> Thomas
> 
The things which are described don't sound unfamilar.
First some questions:
Which Git/OS are you running on ?

CYGWIN ?
Git-for-Windows ?
Linux ?
Other ?

Which versions ?
How does your .gitattribute file look like ?

It may be, that you need to "nornalize" your repo:

https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
The search for this text
"When text=auto normalization"
and follow the instructions:

  reply	other threads:[~2015-06-30 14:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-30 14:12 end-of-line diff checkout direction dependence problem Thomas Vieten
2015-06-30 14:41 ` Torsten Bögershausen [this message]
     [not found] ` <5593F73E.60305@ivision.de>
2015-07-02 14:00   ` Thomas Vieten
2015-07-06  6:53     ` Torsten Bögershausen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5592AA93.9090002@web.de \
    --to=tboegi@web.de \
    --cc=git@vger.kernel.org \
    --cc=tvie@ivision.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).