git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
* Re: bug report
       [not found] <CA+2sEepTyrK-iH+VBHVF1i9DuYVzDkTNxuM0-yoWbkC9N4f8HA@mail.gmail.com>
@ 2019-04-15 15:18 ` Nick Steinhauser
  0 siblings, 0 replies; 39+ messages in thread
From: Nick Steinhauser @ 2019-04-15 15:18 UTC (permalink / raw)
  To: git

user$ git checkout -b "environment-logging"
Switched to a new branch ' environment-logging'
user$ git status
On branch  environment-logging
nothing to commit, working tree clean
user$ git checkout develop
Switched to branch 'develop'
Your branch is up to date with 'origin/develop'.
user$ git branch -D environment-logging
error: branch 'environment-logging' not found.


Regular space:
user$ git branch -D " environment-logging"
error: branch ' environment-logging' not found.


Nonbreaking space:
user$ git branch -D " environment-logging"
Deleted branch  environment-logging (was 267ffff).


Non breaking space inserted into my branch name. Above is copy pasted
from terminal with only the user name and directory altered and
extraneous commands removed. Note the space in the std out of the
first command but not included in the command itself. Whereas in the
last command I explicitly typed the nonbreaking space and it does
appear as a visible space. I do not know how to reproduce.


Thanks,

Nick

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2017-08-30 21:25 Bug report Aleksandar Pavic
  2017-08-31  6:36 ` Kevin Daudt
@ 2017-09-02  8:49 ` Jeff King
  1 sibling, 0 replies; 39+ messages in thread
From: Jeff King @ 2017-09-02  8:49 UTC (permalink / raw)
  To: Aleksandar Pavic; +Cc: git

On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote:

>  I have a file
> 
>  app/Controller/CustomerCardVerificationController.php
> 
> And when I take a look at changes log, I get this (no matter which tool I
> use):
> 
> 2017-07-31 19:41 dule             o membership renew payment email
> 2017-06-07 08:59 Dusan Tatic      o cc refund clean
> 2017-04-15 00:16 Miodrag Dragić   o refound admin payment
> 2017-03-20 12:02 Dusan Tatic      o CardVerification card connect
> 2017-03-16 15:59 Aleksandar Pavic o paypal
> 2017-03-10 13:34 Aleksandar Pavic o Production branch
> 2017-03-10 13:01 Aleksandar Pavic I Migrating dev
>
> However if I manually browse thru revisions and open revision from
> 03/27/2017 07:05 PM
> 
> I can see the change in that file which is unlisted above, at revision
> ff9f4946e109bd234d438e4db1d319b1f6cb6580

How are you invoking the log? Are you doing:

  git log app/Controller/CustomerCardVerificationController.php

or similar? If that is the case, then history simplification may be
causing the results you see. And even you don't _see_ any merges in the
output, that is because they were simplified away. And the commit you
are looking for may have been on a side branch that was simplified away.

If you do:

  git log --full-history app/...

does the commit you are interested in show up? If so, then it was
removed due to history simplification. And if you are surprised that a
side branch was simplified away, that is most likely because there is a
mis-merge in your history (some merge which threw away the changes on a
side branch).

Try:

  git log --graph --oneline --name-status --full-history app/...

to see the whole shape of history, including which commits touched the
file.

You can read more about it in the "History Simplification" section of
"git help log".

-Peff

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2017-08-31  6:36 ` Kevin Daudt
  2017-08-31 14:19   ` Dov Grobgeld
@ 2017-08-31 16:23   ` Stephan Beyer
  1 sibling, 0 replies; 39+ messages in thread
From: Stephan Beyer @ 2017-08-31 16:23 UTC (permalink / raw)
  To: Kevin Daudt, Aleksandar Pavic; +Cc: git

On 08/31/2017 08:36 AM, Kevin Daudt wrote:
> On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote:
>>  I have a file
>>
>>  app/Controller/CustomerCardVerificationController.php
>>
>> And when I take a look at changes log, I get this (no matter which tool I
>> use):
>>
>> 2017-07-31 19:41 dule             o membership renew payment email
>> 2017-06-07 08:59 Dusan Tatic      o cc refund clean
>> 2017-04-15 00:16 Miodrag Dragić   o refound admin payment
>> 2017-03-20 12:02 Dusan Tatic      o CardVerification card connect
>> 2017-03-16 15:59 Aleksandar Pavic o paypal
>> 2017-03-10 13:34 Aleksandar Pavic o Production branch
>> 2017-03-10 13:01 Aleksandar Pavic I Migrating dev
>>
>> However if I manually browse thru revisions and open revision from
>> 03/27/2017 07:05 PM
>>
>> I can see the change in that file which is unlisted above, at revision
>> ff9f4946e109bd234d438e4db1d319b1f6cb6580

I am not sure if I fully understand but I guess your commit ff9f4946e1
has been commited at detached HEAD.

You could do
	git log --oneline --graph master ff9f4946e1
to see where the "missing" commit lies.
And probably a
	git cherry-pick ff9f4946e1
might pick your missing feature.

Stephan

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2017-08-31 14:19   ` Dov Grobgeld
@ 2017-08-31 14:55     ` Aleksandar Pavic
  0 siblings, 0 replies; 39+ messages in thread
From: Aleksandar Pavic @ 2017-08-31 14:55 UTC (permalink / raw)
  To: Dov Grobgeld, Kevin Daudt; +Cc: git

Hm, thanks, but the link was not helpful, there are no merge commits to 
master branch.

Those changes should have not been undone, that's how we caught it, 
because 1 line peace of code introduced new feature (+-10% tolerance on 
credit card verification  amount).

So most likeley they were undone, but our tree is pretty simple, we have 
master and production branches.



On 31.08.2017. 16:19, Dov Grobgeld wrote:
> The following answer that I got back in 2015 from Jeff King might be
> relevant to your problem:
>
> https://marc.info/?l=git&m=144178948506788&w=2
>
> Regards,
> Dov
>
> On Thu, Aug 31, 2017 at 9:36 AM, Kevin Daudt <me@ikke.info> wrote:
>> On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote:
>>>   I have a file
>>>
>>>   app/Controller/CustomerCardVerificationController.php
>>>
>>> And when I take a look at changes log, I get this (no matter which tool I
>>> use):
>>>
>>> 2017-07-31 19:41 dule             o membership renew payment email
>>> 2017-06-07 08:59 Dusan Tatic      o cc refund clean
>>> 2017-04-15 00:16 Miodrag Dragić   o refound admin payment
>>> 2017-03-20 12:02 Dusan Tatic      o CardVerification card connect
>>> 2017-03-16 15:59 Aleksandar Pavic o paypal
>>> 2017-03-10 13:34 Aleksandar Pavic o Production branch
>>> 2017-03-10 13:01 Aleksandar Pavic I Migrating dev
>>>
>>> However if I manually browse thru revisions and open revision from
>>> 03/27/2017 07:05 PM
>>>
>>> I can see the change in that file which is unlisted above, at revision
>>> ff9f4946e109bd234d438e4db1d319b1f6cb6580
>>>
>>> And I'm at master branch all the time...
>>>
>>> We wouldn't have noticed that if it weren't one important feature...
>>>
>> What does git branch --contains ff9f4946e109bd234d438e4db1d319b1f6cb6580
>> return?
>>
>> Where did you find this commit?


^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2017-08-31  6:36 ` Kevin Daudt
@ 2017-08-31 14:19   ` Dov Grobgeld
  2017-08-31 14:55     ` Aleksandar Pavic
  2017-08-31 16:23   ` Stephan Beyer
  1 sibling, 1 reply; 39+ messages in thread
From: Dov Grobgeld @ 2017-08-31 14:19 UTC (permalink / raw)
  To: Kevin Daudt; +Cc: Aleksandar Pavic, git

The following answer that I got back in 2015 from Jeff King might be
relevant to your problem:

https://marc.info/?l=git&m=144178948506788&w=2

Regards,
Dov

On Thu, Aug 31, 2017 at 9:36 AM, Kevin Daudt <me@ikke.info> wrote:
> On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote:
>>  I have a file
>>
>>  app/Controller/CustomerCardVerificationController.php
>>
>> And when I take a look at changes log, I get this (no matter which tool I
>> use):
>>
>> 2017-07-31 19:41 dule             o membership renew payment email
>> 2017-06-07 08:59 Dusan Tatic      o cc refund clean
>> 2017-04-15 00:16 Miodrag Dragić   o refound admin payment
>> 2017-03-20 12:02 Dusan Tatic      o CardVerification card connect
>> 2017-03-16 15:59 Aleksandar Pavic o paypal
>> 2017-03-10 13:34 Aleksandar Pavic o Production branch
>> 2017-03-10 13:01 Aleksandar Pavic I Migrating dev
>>
>> However if I manually browse thru revisions and open revision from
>> 03/27/2017 07:05 PM
>>
>> I can see the change in that file which is unlisted above, at revision
>> ff9f4946e109bd234d438e4db1d319b1f6cb6580
>>
>> And I'm at master branch all the time...
>>
>> We wouldn't have noticed that if it weren't one important feature...
>>
>
> What does git branch --contains ff9f4946e109bd234d438e4db1d319b1f6cb6580
> return?
>
> Where did you find this commit?

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2017-08-30 21:25 Bug report Aleksandar Pavic
@ 2017-08-31  6:36 ` Kevin Daudt
  2017-08-31 14:19   ` Dov Grobgeld
  2017-08-31 16:23   ` Stephan Beyer
  2017-09-02  8:49 ` Jeff King
  1 sibling, 2 replies; 39+ messages in thread
From: Kevin Daudt @ 2017-08-31  6:36 UTC (permalink / raw)
  To: Aleksandar Pavic; +Cc: git

On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote:
>  I have a file
> 
>  app/Controller/CustomerCardVerificationController.php
> 
> And when I take a look at changes log, I get this (no matter which tool I
> use):
> 
> 2017-07-31 19:41 dule             o membership renew payment email
> 2017-06-07 08:59 Dusan Tatic      o cc refund clean
> 2017-04-15 00:16 Miodrag Dragić   o refound admin payment
> 2017-03-20 12:02 Dusan Tatic      o CardVerification card connect
> 2017-03-16 15:59 Aleksandar Pavic o paypal
> 2017-03-10 13:34 Aleksandar Pavic o Production branch
> 2017-03-10 13:01 Aleksandar Pavic I Migrating dev
> 
> However if I manually browse thru revisions and open revision from
> 03/27/2017 07:05 PM
> 
> I can see the change in that file which is unlisted above, at revision
> ff9f4946e109bd234d438e4db1d319b1f6cb6580
> 
> And I'm at master branch all the time...
> 
> We wouldn't have noticed that if it weren't one important feature...
> 

What does git branch --contains ff9f4946e109bd234d438e4db1d319b1f6cb6580
return?

Where did you find this commit?

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Bug report
@ 2017-08-30 21:25 Aleksandar Pavic
  2017-08-31  6:36 ` Kevin Daudt
  2017-09-02  8:49 ` Jeff King
  0 siblings, 2 replies; 39+ messages in thread
From: Aleksandar Pavic @ 2017-08-30 21:25 UTC (permalink / raw)
  To: git

  I have a file

  app/Controller/CustomerCardVerificationController.php

And when I take a look at changes log, I get this (no matter which tool 
I use):

2017-07-31 19:41 dule             o membership renew payment email
2017-06-07 08:59 Dusan Tatic      o cc refund clean
2017-04-15 00:16 Miodrag Dragić   o refound admin payment
2017-03-20 12:02 Dusan Tatic      o CardVerification card connect
2017-03-16 15:59 Aleksandar Pavic o paypal
2017-03-10 13:34 Aleksandar Pavic o Production branch
2017-03-10 13:01 Aleksandar Pavic I Migrating dev

However if I manually browse thru revisions and open revision from 
03/27/2017 07:05 PM

I can see the change in that file which is unlisted above, at revision 
ff9f4946e109bd234d438e4db1d319b1f6cb6580

And I'm at master branch all the time...

We wouldn't have noticed that if it weren't one important feature...


^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: bug report
  2016-05-13  8:10             ` Jeff King
@ 2016-05-13 12:05               ` 李本超
  0 siblings, 0 replies; 39+ messages in thread
From: 李本超 @ 2016-05-13 12:05 UTC (permalink / raw)
  To: Jeff King; +Cc: Pranit Bauva, Git List

Thanks for your explanation

>
> The moment where I think you'd like to be notified is when we skipped
> doing anything with patch 1. You'd prefer it to say "woah, the other
> side of the rebase did the same thing as us".
Actually this is the problem where I want to be notified.

> But rebase does not do that by default, because the intent of rebase is
> that you are rebasing your work on an upstream which might be accepting
> part of your work as patches. So it is a feature that rebase says
> "already applied upstream -- let's ignore this one".
>
> I don't think there is a way to ask rebase not to ignore such
> already-applied patches. But I'm not sure if there should be, for two
> reasons:
>
>   1. You should consider just using "git merge" to merge the two
>      branches. That preserves more information about what actually
>      happened, and would find a conflict in a case like this.
>
>   2. Even with merging, you cannot assume that the end result is sane.
>      In your example, there is a textual conflict. But you can easily
>      come up with other examples where a merge is textually sound, but
>      has some semantic conflict (e.g., you update the signature of a
>      function but a colleague adds another call to it using the old
>      signature).
>
>      You have to examine and test the results of merges for sanity. And
>      likewise with rebases.
>
> -Peff
>
> [1] Actually, rebase does not even try to replay the first patch. When
>     it generates the list of commits, it ignores any whose "patch-id" is
>     the same as a commit on the other side. But the end effect is the
>     same.
Your explanation looks reasonable to me.

Thanks a lot for your time and patience. And @Pranit Bauva too.

By the way, many thanks for maintaining this outstanding software Git.


-- 
Benchao Li
School of Electronics Engineering and Computer Science, Peking University
Tel:+86-15650713730
Email: libenchao@gmail.com; libenchao@pku.edu.cn

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: bug report
  2016-05-13  7:41           ` 李本超
@ 2016-05-13  8:10             ` Jeff King
  2016-05-13 12:05               ` 李本超
  0 siblings, 1 reply; 39+ messages in thread
From: Jeff King @ 2016-05-13  8:10 UTC (permalink / raw)
  To: 李本超; +Cc: Pranit Bauva, Git List

On Fri, May 13, 2016 at 03:41:13PM +0800, 李本超 wrote:

> It does not warn me in this case. I replayed it again, below is my process:
> 
> [...setup...]

So after you setup steps you have:

  $ git log --decorate --oneline --raw

  * a3ce3bc (HEAD -> B) modify
  | :100644 100644 94954ab... 23509e0... M        README.md
  * ef702eb add one line too
  | :100644 100644 ce01362... 94954ab... M        README.md
  | * fa8b99e (master, A) add one line
  |/  
  |   :100644 100644 ce01362... 94954ab... M      README.md
  * cf2103b add readme
    :000000 100644 0000000... ce01362... A        README.md

Note that B^ (ef702eb) and A (fa8b99e) introduce the exact same change
(moving README.md from ce01362 to 94954ab). And master is at the same
commit as A (due to your fast-forward merge earlier).

So now when you run:

> $ git rebase master

Git will try to replay the commits on master..B on top of master, in
order.  Those commits are ef702eb and a3ce3bc (your commit names will
differ, because your name and timestamps will differ).

So it replays the first one, and sees that it the patch is a noop[1];
the tree in master already has the same end state. So we skip the patch.
And then we replay the second one, which applies cleanly.

The moment where I think you'd like to be notified is when we skipped
doing anything with patch 1. You'd prefer it to say "woah, the other
side of the rebase did the same thing as us".

But rebase does not do that by default, because the intent of rebase is
that you are rebasing your work on an upstream which might be accepting
part of your work as patches. So it is a feature that rebase says
"already applied upstream -- let's ignore this one".

I don't think there is a way to ask rebase not to ignore such
already-applied patches. But I'm not sure if there should be, for two
reasons:

  1. You should consider just using "git merge" to merge the two
     branches. That preserves more information about what actually
     happened, and would find a conflict in a case like this.

  2. Even with merging, you cannot assume that the end result is sane.
     In your example, there is a textual conflict. But you can easily
     come up with other examples where a merge is textually sound, but
     has some semantic conflict (e.g., you update the signature of a
     function but a colleague adds another call to it using the old
     signature).

     You have to examine and test the results of merges for sanity. And
     likewise with rebases.

-Peff

[1] Actually, rebase does not even try to replay the first patch. When
    it generates the list of commits, it ignores any whose "patch-id" is
    the same as a commit on the other side. But the end effect is the
    same.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: bug report
  2016-05-13  7:10         ` Pranit Bauva
@ 2016-05-13  7:41           ` 李本超
  2016-05-13  8:10             ` Jeff King
  0 siblings, 1 reply; 39+ messages in thread
From: 李本超 @ 2016-05-13  7:41 UTC (permalink / raw)
  To: Pranit Bauva; +Cc: Git List

It does not warn me in this case. I replayed it again, below is my process:

$ mkdir bug_test
$ cd bug_test/
$ git init
Initialized empty Git repository in /home/libenchao/tmp/bug_test/.git/
$ echo 'hello' > README.md
$ git add README.md
$ git commit -m 'Add README.md'
[master (root-commit) 9cdb3a8] Add README.md
 1 file changed, 1 insertion(+)
 create mode 100644 README.md
$ git checkout -b A
Switched to a new branch 'A'
$ echo 'world' >> README.md
$ git commit -a -m 'Add one line'
[A 6f0b0a3] Add one line
 1 file changed, 1 insertion(+)
$ git checkout master
Switched to branch 'master'
$ git checkout -b B
Switched to a new branch 'B'
$ echo 'world' >> README.md
$ git commit -a -m 'Add one line too'
[B d89cf11] Add one line too
 1 file changed, 1 insertion(+)
$ vim README.md                        # in this line, I modify line 2
'world' to 'git'
$ cat README.md
hello
git
$ git commit -a -m 'Modify one line'
[B a674427] Modify one line
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git checkout master
Switched to branch 'master'
$ git merge A
Updating 9cdb3a8..6f0b0a3
Fast-forward
 README.md | 1 +
 1 file changed, 1 insertion(+)
$ git checkout B
Switched to branch 'B'
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: Modify one line
$ cat README.md
hello
git
$

2016-05-13 15:10 GMT+08:00 Pranit Bauva <pranit.bauva@gmail.com>:
> On Fri, May 13, 2016 at 12:27 PM, 李本超 <libenchao@gmail.com> wrote:
>> Yes, you got the right understanding of my problem.
>>
>> You are right, the git behavior is quite correct. But I met this
>> problem in my practical work:
>>
>> My colleague added a method but I didn't know. I also added the same method.
>> Then I found that I didn't need the method actually, so I deleted it.
>> My colleague merged to the master before me. When I wanted to merge, I found
>> conflicts with master. And I rebased to current master. And That method was
>> deleted finally without any warning or information.
>
> I am quite sure that there would be an output to show that there are
> conflicts and it would be suggesting you to first resolve the
> conflicts and there would also be markers in the file like ">>>>>" and
> "======" and the file would be marked with "both modified". After you
> resolve the conflicts, you can add the file by using git-add and then
> "git rebase --continue" to proceed. If you find out that there is some
> problem, then you can always use "git rebase --abort" to abort the
> rebase process and get to the initial state *perfectly* without any
> glitches.
>
>> Do you think Git should output something to warn the user or I just
>> use Git in a wrong way ?
>
> It does warn. I don't know how it got missed in your case. This is
> quite a common problem and even I have faced this quite for quite a
> lot of times now and it always did warn me.
>
>> Thanks.
>
> I will recommend you reading this article[1]. I know its a bit of a
> long read but it will help a lot.
>
> [1]: http://tedfelix.com/software/git-conflict-resolution.html
>
> Regards,
> Pranit Bauva



-- 
Benchao Li
School of Electronics Engineering and Computer Science, Peking University
Tel:+86-15650713730
Email: libenchao@gmail.com; libenchao@pku.edu.cn

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: bug report
  2016-05-13  6:57       ` 李本超
@ 2016-05-13  7:10         ` Pranit Bauva
  2016-05-13  7:41           ` 李本超
  0 siblings, 1 reply; 39+ messages in thread
From: Pranit Bauva @ 2016-05-13  7:10 UTC (permalink / raw)
  To: 李本超; +Cc: Git List

On Fri, May 13, 2016 at 12:27 PM, 李本超 <libenchao@gmail.com> wrote:
> Yes, you got the right understanding of my problem.
>
> You are right, the git behavior is quite correct. But I met this
> problem in my practical work:
>
> My colleague added a method but I didn't know. I also added the same method.
> Then I found that I didn't need the method actually, so I deleted it.
> My colleague merged to the master before me. When I wanted to merge, I found
> conflicts with master. And I rebased to current master. And That method was
> deleted finally without any warning or information.

I am quite sure that there would be an output to show that there are
conflicts and it would be suggesting you to first resolve the
conflicts and there would also be markers in the file like ">>>>>" and
"======" and the file would be marked with "both modified". After you
resolve the conflicts, you can add the file by using git-add and then
"git rebase --continue" to proceed. If you find out that there is some
problem, then you can always use "git rebase --abort" to abort the
rebase process and get to the initial state *perfectly* without any
glitches.

> Do you think Git should output something to warn the user or I just
> use Git in a wrong way ?

It does warn. I don't know how it got missed in your case. This is
quite a common problem and even I have faced this quite for quite a
lot of times now and it always did warn me.

> Thanks.

I will recommend you reading this article[1]. I know its a bit of a
long read but it will help a lot.

[1]: http://tedfelix.com/software/git-conflict-resolution.html

Regards,
Pranit Bauva

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: bug report
  2016-05-13  6:37     ` Pranit Bauva
@ 2016-05-13  6:57       ` 李本超
  2016-05-13  7:10         ` Pranit Bauva
  0 siblings, 1 reply; 39+ messages in thread
From: 李本超 @ 2016-05-13  6:57 UTC (permalink / raw)
  To: Pranit Bauva; +Cc: Git List

Yes, you got the right understanding of my problem.

You are right, the git behavior is quite correct. But I met this
problem in my practical work:

My colleague added a method but I didn't know. I also added the same method.
Then I found that I didn't need the method actually, so I deleted it.
My colleague merged to the master before me. When I wanted to merge, I found
conflicts with master. And I rebased to current master. And That method was
deleted finally without any warning or information.

Do you think Git should output something to warn the user or I just
use Git in a wrong way ?

Thanks.

2016-05-13 14:37 GMT+08:00 Pranit Bauva <pranit.bauva@gmail.com>:
> On Fri, May 13, 2016 at 11:28 AM, 李本超 <libenchao@gmail.com> wrote:
>> git version 2.6.4 (Apple Git-63)
>> system version: OS X EI Capitan 10.11.4
>>
>> below is the steps:
>> $ mkdir test_repo
>> $ cd test_repo
>> $ git init
>> $ echo "hello" > README.md
>> $ git commit -a -m 'Add README.md'
>
> It was my mistake. git-commit -a adds files which are tracked.
> Currently README.md is not tracked. So you will have to first use
> git-add to add them for tracking. Though while trying out your steps I
> used git-add. For further commits one can use -a with git-commit.
>
>> $ git checkout -b A
>> $ echo "world" > README.md
>> $ git commit -a -m 'Add one line'
>
> You are technically not adding a line. You are modifying the previous
> line to the updated line. So the contents of the file will be:
> "world"
> It seems from the further part that you actually wanted to add the
> line rather than modifying it. Better to use ">>" instead of ">". ">>"
> is used for appending.
>
>> $ git checkout master
>> $ git checkout -b B
>> $ echo "world" > README.md
>> $ git commit -a -m 'Add one line too'
>> $ [midify 'world' line to other things like 'git' using vi]
>
> I think you mean modify.
>
>> $ git commit -a -m 'Modify one line'
>>
>> $ git checkout master
>> $ git merge A
>>
>> $ git checkout B
>> $ git rebase master [problem is here, cat README.rd we will get :
>> hello and git instead of hello world git]
>
> The git behavior is quite correct.
> When you are on the B branch and you choose to rebase it on the
> master, it will apply commits as patches. So it first sees that the
> commit on the A branch which is now merged with master ie. "Add one
> line" and the commit on the B branch "Add one line too" are doing the
> same thing which is removing the line "hello" and adding the line
> "world". Then it applies the commit "modify one line" on top of this
> which removes the line "world" and adds the line "git". So finally,
> README.md will contain only "git".
>
> Regards,
> Pranit Bauva



-- 
Benchao Li
School of Electronics Engineering and Computer Science, Peking University
Tel:+86-15650713730
Email: libenchao@gmail.com; libenchao@pku.edu.cn

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: bug report
  2016-05-13  5:58   ` 李本超
@ 2016-05-13  6:37     ` Pranit Bauva
  2016-05-13  6:57       ` 李本超
  0 siblings, 1 reply; 39+ messages in thread
From: Pranit Bauva @ 2016-05-13  6:37 UTC (permalink / raw)
  To: 李本超; +Cc: Git List

On Fri, May 13, 2016 at 11:28 AM, 李本超 <libenchao@gmail.com> wrote:
> git version 2.6.4 (Apple Git-63)
> system version: OS X EI Capitan 10.11.4
>
> below is the steps:
> $ mkdir test_repo
> $ cd test_repo
> $ git init
> $ echo "hello" > README.md
> $ git commit -a -m 'Add README.md'

It was my mistake. git-commit -a adds files which are tracked.
Currently README.md is not tracked. So you will have to first use
git-add to add them for tracking. Though while trying out your steps I
used git-add. For further commits one can use -a with git-commit.

> $ git checkout -b A
> $ echo "world" > README.md
> $ git commit -a -m 'Add one line'

You are technically not adding a line. You are modifying the previous
line to the updated line. So the contents of the file will be:
"world"
It seems from the further part that you actually wanted to add the
line rather than modifying it. Better to use ">>" instead of ">". ">>"
is used for appending.

> $ git checkout master
> $ git checkout -b B
> $ echo "world" > README.md
> $ git commit -a -m 'Add one line too'
> $ [midify 'world' line to other things like 'git' using vi]

I think you mean modify.

> $ git commit -a -m 'Modify one line'
>
> $ git checkout master
> $ git merge A
>
> $ git checkout B
> $ git rebase master [problem is here, cat README.rd we will get :
> hello and git instead of hello world git]

The git behavior is quite correct.
When you are on the B branch and you choose to rebase it on the
master, it will apply commits as patches. So it first sees that the
commit on the A branch which is now merged with master ie. "Add one
line" and the commit on the B branch "Add one line too" are doing the
same thing which is removing the line "hello" and adding the line
"world". Then it applies the commit "modify one line" on top of this
which removes the line "world" and adds the line "git". So finally,
README.md will contain only "git".

Regards,
Pranit Bauva

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: bug report
  2016-05-13  5:23 ` Pranit Bauva
@ 2016-05-13  5:58   ` 李本超
  2016-05-13  6:37     ` Pranit Bauva
  0 siblings, 1 reply; 39+ messages in thread
From: 李本超 @ 2016-05-13  5:58 UTC (permalink / raw)
  To: Pranit Bauva; +Cc: Git List

git version 2.6.4 (Apple Git-63)
system version: OS X EI Capitan 10.11.4

below is the steps:
$ mkdir test_repo
$ cd test_repo
$ git init
$ echo "hello" > README.md
$ git commit -a -m 'Add README.md'

$ git checkout -b A
$ echo "world" > README.md
$ git commit -a -m 'Add one line'

$ git checkout master
$ git checkout -b B
$ echo "world" > README.md
$ git commit -a -m 'Add one line too'
$ [midify 'world' line to other things like 'git' using vi]
$ git commit -a -m 'Modify one line'

$ git checkout master
$ git merge A

$ git checkout B
$ git rebase master [problem is here, cat README.rd we will get :
hello and git instead of hello world git]

2016-05-13 13:23 GMT+08:00 Pranit Bauva <pranit.bauva@gmail.com>:
> Please mention the version no of git you are using and your system.
> I am answering according to git 2.8.1 Lubuntu 15.04
>
> On Fri, May 13, 2016 at 10:34 AM, 李本超 <libenchao@gmail.com> wrote:
>> Hi all,
>>
>>       Yestoday when I worked using Git, I found a bug. It's about
>> rebase. Or I don't know if it is a bug, maybe that is Git. Below is my
>> problem:
>>
>>       There is a master branch, and we develop in our own branch.
>> Let's simplify this: there are two branches created at the same commit
>> point at master. Then branch A add a function X. Branch B add funciton
>> X too (yes, they are very same). Then branch B modify function X to
>> function Y.
>
> What do you mean by this? Did you amend the previous commit, or
> introduced another separate commit ?
>
>>       Branch A finishes it's job first and merged to master
>> successfully and happily without any conflicts. When branch B wants to
>> merge to master, he finds that master has updated. So branch B must
>> rebase to the current master. Then problem happends: git rebase
>> successfully without any conflicts. But branch B cannot see function X
>> from master (or branch A), only its own function Y.
>>       I think that's because Git is based on file instead of patch.
>> But I think Git can report it in this situation.
>>       How do you think ? Thank you anyway for maintaining this amazing software.
>
> Well I tried to reproduce the problem. I did the following steps:
> $ mdkir test_repo
> $ cd test_repo
> $ git init
> $ echo Hello >hi
> $ git commit -a -m "C1"
> $ git checkout -b A
> $ echo Bye >hi
> $ git commit -a -m "C2 - A"
> $ git checkout -
> $ git checkout -b B
> $ echo "Bye." >hi
> $ git commit -a -m "C3 - B"
> $ git checkout -
> $ git merge A
> $ git checkout B
> $ git rebase master
>
> This shows that some merge conflicts needs resolving. Did I follow
> your steps or I missed something? It would be better if you could
> reproduce your steps like I did so as to make things more clear to us.
>
> Regards,
> Pranit Bauva



-- 
Benchao Li
School of Electronics Engineering and Computer Science, Peking University
Tel:+86-15650713730
Email: libenchao@gmail.com; libenchao@pku.edu.cn

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: bug report
  2016-05-13  5:04 bug report 李本超
@ 2016-05-13  5:23 ` Pranit Bauva
  2016-05-13  5:58   ` 李本超
  0 siblings, 1 reply; 39+ messages in thread
From: Pranit Bauva @ 2016-05-13  5:23 UTC (permalink / raw)
  To: 李本超; +Cc: Git List

Please mention the version no of git you are using and your system.
I am answering according to git 2.8.1 Lubuntu 15.04

On Fri, May 13, 2016 at 10:34 AM, 李本超 <libenchao@gmail.com> wrote:
> Hi all,
>
>       Yestoday when I worked using Git, I found a bug. It's about
> rebase. Or I don't know if it is a bug, maybe that is Git. Below is my
> problem:
>
>       There is a master branch, and we develop in our own branch.
> Let's simplify this: there are two branches created at the same commit
> point at master. Then branch A add a function X. Branch B add funciton
> X too (yes, they are very same). Then branch B modify function X to
> function Y.

What do you mean by this? Did you amend the previous commit, or
introduced another separate commit ?

>       Branch A finishes it's job first and merged to master
> successfully and happily without any conflicts. When branch B wants to
> merge to master, he finds that master has updated. So branch B must
> rebase to the current master. Then problem happends: git rebase
> successfully without any conflicts. But branch B cannot see function X
> from master (or branch A), only its own function Y.
>       I think that's because Git is based on file instead of patch.
> But I think Git can report it in this situation.
>       How do you think ? Thank you anyway for maintaining this amazing software.

Well I tried to reproduce the problem. I did the following steps:
$ mdkir test_repo
$ cd test_repo
$ git init
$ echo Hello >hi
$ git commit -a -m "C1"
$ git checkout -b A
$ echo Bye >hi
$ git commit -a -m "C2 - A"
$ git checkout -
$ git checkout -b B
$ echo "Bye." >hi
$ git commit -a -m "C3 - B"
$ git checkout -
$ git merge A
$ git checkout B
$ git rebase master

This shows that some merge conflicts needs resolving. Did I follow
your steps or I missed something? It would be better if you could
reproduce your steps like I did so as to make things more clear to us.

Regards,
Pranit Bauva

^ permalink raw reply	[flat|nested] 39+ messages in thread

* bug report
@ 2016-05-13  5:04 李本超
  2016-05-13  5:23 ` Pranit Bauva
  0 siblings, 1 reply; 39+ messages in thread
From: 李本超 @ 2016-05-13  5:04 UTC (permalink / raw)
  To: git

Hi all,

      Yestoday when I worked using Git, I found a bug. It's about
rebase. Or I don't know if it is a bug, maybe that is Git. Below is my
problem:

      There is a master branch, and we develop in our own branch.
Let's simplify this: there are two branches created at the same commit
point at master. Then branch A add a function X. Branch B add funciton
X too (yes, they are very same). Then branch B modify function X to
function Y.
      Branch A finishes it's job first and merged to master
successfully and happily without any conflicts. When branch B wants to
merge to master, he finds that master has updated. So branch B must
rebase to the current master. Then problem happends: git rebase
successfully without any conflicts. But branch B cannot see function X
from master (or branch A), only its own function Y.
      I think that's because Git is based on file instead of patch.
But I think Git can report it in this situation.
      How do you think ? Thank you anyway for maintaining this amazing software.

-- 

Benchao Li
School of Electronics Engineering and Computer Science, Peking University
Tel:+86-15650713730
Email: libenchao@gmail.com; libenchao@pku.edu.cn

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug Report
  2016-04-03  0:25 Bug Report Benjamin Sandeen
  2016-04-03  2:20 ` Eric N. Vander Weele
@ 2016-04-03  2:22 ` Jacob Keller
  1 sibling, 0 replies; 39+ messages in thread
From: Jacob Keller @ 2016-04-03  2:22 UTC (permalink / raw)
  To: Benjamin Sandeen; +Cc: Git mailing list

Hi,

On Sat, Apr 2, 2016 at 5:25 PM, Benjamin Sandeen
<benjaminsandeen2016@u.northwestern.edu> wrote:
> Today, I managed to create a duplicate branch in a git repository.  While
> this may not be a bug per se, I do think that it is confusing and some way
> of preventing such issues in the future may be helpful.
>
> I first cloned the repository:
>
> $ git clone https://github.com/CodeForChicago/superclass.git
>
> Then, I created a new branch (or so I thought):
>
> $ git checkout -b lesson_page
>
> However, this branch has already existed for about 4 weeks, without my
> knowledge.  I proceeded to do some work on the files it contained, and when
> it came time to commit and push, and when I pushed, I got the following
> message:

The branch existed in the remote repository, but it doesn't exist
locally. You never fetched a copy into refs/remotes/origin since you
didn't say you were interested, and git will fully allow you to create
local branches with the same name as remote branches.

>
> To https://github.com/CodeForChicago/superclass.git
>  ! [rejected]        lesson_page -> lesson_page (non-fast-forward)
> error: failed to push some refs to '
> https://github.com/CodeForChicago/superclass.git'
> hint: Updates were rejected because the tip of your current branch is behind
> hint: its remote counterpart. Integrate the remote changes (e.g.
> hint: 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>

When you tried to push this branch, it will push into
refs/heads/lesson_page on the remote, which already exists. Since it
cannot perform a fast-forward update, as your local work isn't based
directly on the tip of the remote branch, you either need to merge,
rebase, or start from scratch.

> Given that I had believed that I had created the branch just a few hours
> prior and was the first to attempt to push to it, this error was
> consternating.

Let me try to explain. You created your own local branch, which
happened to share the same name as an already existing branch. Had you
know this you could have fetched and checked out that branch. You can
view all branches using "git branch -a" or "git ls-remote".

>
> I may be wrong (I am aware that my understanding of git is limited), but I
> believe that the git checkout -b command is simply supposed to create a new
> branch and then switch to it (I'm not aware of any subtle behavior that goes
> on behind the scenes if the "new" branch that the user is attempting to
> create already exists).  This is why I said it "may not be a bug per se".
> However, I expect most people who use git to expect this command to create a
> new branch and then switch to it (this is what most sources online will tell
> users to do to create a new branch), and as such, it would be extremely
> beneficial if git were to, at the very least, alert the user to the conflict
> in some way or another.

git checkout -b <branch_name> will create a new branch in your local
copy of the repository. Git is distributed. You can do "git checkout
--track <branch>" to attempt to create a local branch which tracks the
upstream branch, and then git status will provide useful information
about the relationship between your local work and the remote work.

It could maybe be improved to notice that a remote has a branch with
the same name. However, git can support multiple remotes, so
determining which remote to care about is difficult.

In your case you have a couple of options to fix it. I would suggest at least

"git branch --set-upstream-to=origin/<branch_name>" so that git status
will give you useful information about the branch relationship. Then
you can merge or rebase your work into the branch.

The issue is in understanding how git distributes branches, and how it
could handle this. I suspect improvements could be made so that it
will attempt to warn you when you create a branch that already exists.
However, often you do this *intending* to make it track the specific
branch so I am not sure how much good a warning would do. Just a
message wouldn't really hurt anything, however.

Thanks,
Jake

>
> Thanks,
> Ben
>

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug Report
  2016-04-03  0:25 Bug Report Benjamin Sandeen
@ 2016-04-03  2:20 ` Eric N. Vander Weele
  2016-04-03  2:22 ` Jacob Keller
  1 sibling, 0 replies; 39+ messages in thread
From: Eric N. Vander Weele @ 2016-04-03  2:20 UTC (permalink / raw)
  To: Benjamin Sandeen; +Cc: git

On Sat, Apr 2, 2016 at 8:25 PM, Benjamin Sandeen
<benjaminsandeen2016@u.northwestern.edu> wrote:
> Today, I managed to create a duplicate branch in a git repository.  While
> this may not be a bug per se, I do think that it is confusing and some way
> of preventing such issues in the future may be helpful.

This can be confusing.  I'll hopefully try to help and explain below.

> I first cloned the repository:
>
> $ git clone https://github.com/CodeForChicago/superclass.git
>
> Then, I created a new branch (or so I thought):
>
> $ git checkout -b lesson_page

At this point, you created a *local* branch called 'lesson_page' which
points to the current HEAD and then switched to that branch .  This
local branch is independent of the remote branch called
'origin/lesson_page'.

> However, this branch has already existed for about 4 weeks, without my
> knowledge.  I proceeded to do some work on the files it contained, and when
> it came time to commit and push, and when I pushed, I got the following
> message:
>
> To https://github.com/CodeForChicago/superclass.git
>  ! [rejected]        lesson_page -> lesson_page (non-fast-forward)
> error: failed to push some refs to '
> https://github.com/CodeForChicago/superclass.git'
> hint: Updates were rejected because the tip of your current branch is behind
> hint: its remote counterpart. Integrate the remote changes (e.g.
> hint: 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>
> Given that I had believed that I had created the branch just a few hours
> prior and was the first to attempt to push to it, this error was
> consternating.

The non-fast-forward push is preventing history being rewritten- this
is a good thing :).

> I may be wrong (I am aware that my understanding of git is limited), but I
> believe that the git checkout -b command is simply supposed to create a new
> branch and then switch to it (I'm not aware of any subtle behavior that goes
> on behind the scenes if the "new" branch that the user is attempting to
> create already exists).  This is why I said it "may not be a bug per se".
> However, I expect most people who use git to expect this command to create a
> new branch and then switch to it (this is what most sources online will tell
> users to do to create a new branch), and as such, it would be extremely
> beneficial if git were to, at the very least, alert the user to the conflict
> in some way or another.

The `git checkout -b` command is working as expected.  `git checkout
-b <name>` is equivalent to `git branch <name> && git checkout
<name>`.  If you were to execute `git checkout lesson_page`, you would
get the desired behavior you were expecting because in the presence of
one remote, git will actually execute `git checkout -b lesson_page
--track origin/lesson_page` - more details can be found in `git help
checkout`.  Effectively, it checkouts 'origin/lesson_page' as a new
local branch named 'lesson_page'.

However, you indicated that you did not know there was a remote
branch already named 'lesson_page'.  After cloning the repository, you
can use `git branch -a` to see all remotes to determine which form of
`git checkout` to use.

> Thanks,
> Ben
>
> Lead Consultant, Northwestern University Information Technology
> Research Assistant, Center for Interdisciplinary Exploration and Research in
> Astrophysics at Northwestern University
> Phsyics, Weinberg College of Arts and Sciences
> Computer Science, Weinberg College of Arts and Sciences
> Classics, Weinberg College of Arts and Sciences
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Bug Report
@ 2016-04-03  0:25 Benjamin Sandeen
  2016-04-03  2:20 ` Eric N. Vander Weele
  2016-04-03  2:22 ` Jacob Keller
  0 siblings, 2 replies; 39+ messages in thread
From: Benjamin Sandeen @ 2016-04-03  0:25 UTC (permalink / raw)
  To: git

Today, I managed to create a duplicate branch in a git repository.  While
this may not be a bug per se, I do think that it is confusing and some way
of preventing such issues in the future may be helpful.

I first cloned the repository:

$ git clone https://github.com/CodeForChicago/superclass.git

Then, I created a new branch (or so I thought):

$ git checkout -b lesson_page

However, this branch has already existed for about 4 weeks, without my
knowledge.  I proceeded to do some work on the files it contained, and when
it came time to commit and push, and when I pushed, I got the following
message:

To https://github.com/CodeForChicago/superclass.git
 ! [rejected]        lesson_page -> lesson_page (non-fast-forward)
error: failed to push some refs to '
https://github.com/CodeForChicago/superclass.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Given that I had believed that I had created the branch just a few hours
prior and was the first to attempt to push to it, this error was
consternating.

I may be wrong (I am aware that my understanding of git is limited), but I
believe that the git checkout -b command is simply supposed to create a new
branch and then switch to it (I'm not aware of any subtle behavior that goes
on behind the scenes if the "new" branch that the user is attempting to
create already exists).  This is why I said it "may not be a bug per se".
However, I expect most people who use git to expect this command to create a
new branch and then switch to it (this is what most sources online will tell
users to do to create a new branch), and as such, it would be extremely
beneficial if git were to, at the very least, alert the user to the conflict
in some way or another.

Thanks,
Ben

Lead Consultant, Northwestern University Information Technology
Research Assistant, Center for Interdisciplinary Exploration and Research in
Astrophysics at Northwestern University
Phsyics, Weinberg College of Arts and Sciences
Computer Science, Weinberg College of Arts and Sciences
Classics, Weinberg College of Arts and Sciences

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: bug report
  2015-01-27 14:43 bug report Albert Akhriev
@ 2015-01-27 14:50 ` Jeff King
  0 siblings, 0 replies; 39+ messages in thread
From: Jeff King @ 2015-01-27 14:50 UTC (permalink / raw)
  To: Albert Akhriev; +Cc: git

On Tue, Jan 27, 2015 at 02:43:31PM +0000, Albert Akhriev wrote:

> My system:                      RedHat 6.5/64-bit (gcc 4.4.7)
> My configuration options:  ./configure --prefix=/home/albert/soft
> 
> Compilation of git 2.2.2 itself was fine, but some tests failed.
> I presume, there might be some network communication restrictions here in
> the lab
> (gitweb had failed as can be seen in the listing below):

The gitweb tests should run locally and not need to touch the network.
It looks like gitweb cannot run at all. Are you sure you have a working
perl (with CGI and other base modules)?

Try running:

  cd t
  ./t9500-gitweb-standaloneno-errors.sh -v -i

which should give more output. Also check the contents of gitweb.log in
"t/trash directory/t9500-...".

-Peff

^ permalink raw reply	[flat|nested] 39+ messages in thread

* bug report
@ 2015-01-27 14:43 Albert Akhriev
  2015-01-27 14:50 ` Jeff King
  0 siblings, 1 reply; 39+ messages in thread
From: Albert Akhriev @ 2015-01-27 14:43 UTC (permalink / raw)
  To: git


Hi All,

My system:                      RedHat 6.5/64-bit (gcc 4.4.7)
My configuration options:  ./configure --prefix=/home/albert/soft

Compilation of git 2.2.2 itself was fine, but some tests failed.
I presume, there might be some network communication restrictions here in
the lab
(gitweb had failed as can be seen in the listing below):

1..14
*** t9400-git-cvsserver-server.sh ***
1..0 # SKIP skipping git-cvsserver tests, Perl SQLite interface unavailable
*** t9401-git-cvsserver-crlf.sh ***
1..0 # SKIP skipping git-cvsserver tests, Perl SQLite interface unavailable
*** t9402-git-cvsserver-refs.sh ***
1..0 # SKIP skipping git-cvsserver tests, Perl SQLite interface unavailable
*** t9500-gitweb-standalone-no-errors.sh ***
not ok 1 - no commits: projects_list (implicit)
#	gitweb_run
not ok 2 - no commits: projects_index
#	gitweb_run "a=project_index"
not ok 3 - no commits: .git summary (implicit)
#	gitweb_run "p=.git"
not ok 4 - no commits: .git commit (implicit HEAD)
#	gitweb_run "p=.git;a=commit"
not ok 5 - no commits: .git commitdiff (implicit HEAD)
#	gitweb_run "p=.git;a=commitdiff"
not ok 6 - no commits: .git tree (implicit HEAD)
#	gitweb_run "p=.git;a=tree"
not ok 7 - no commits: .git heads
#	gitweb_run "p=.git;a=heads"
not ok 8 - no commits: .git tags
#	gitweb_run "p=.git;a=tags"
ok 9 - Make initial commit
not ok 10 - projects_list (implicit)
#	gitweb_run
not ok 11 - projects_index
#	gitweb_run "a=project_index"
not ok 12 - .git summary (implicit)
#	gitweb_run "p=.git"
not ok 13 - .git commit (implicit HEAD)
#	gitweb_run "p=.git;a=commit"
not ok 14 - .git commitdiff (implicit HEAD, root commit)
#	gitweb_run "p=.git;a=commitdiff"
not ok 15 - .git commitdiff_plain (implicit HEAD, root commit)
#	gitweb_run "p=.git;a=commitdiff_plain"
not ok 16 - .git commit (HEAD)
#	gitweb_run "p=.git;a=commit;h=HEAD"
not ok 17 - .git tree (implicit HEAD)
#	gitweb_run "p=.git;a=tree"
not ok 18 - .git blob (file)
#	gitweb_run "p=.git;a=blob;f=file"
not ok 19 - .git blob_plain (file)
#	gitweb_run "p=.git;a=blob_plain;f=file"
not ok 20 - .git commit (non-existent)
#	gitweb_run "p=.git;a=commit;h=non-existent"
not ok 21 - .git commitdiff (non-existent)
#	gitweb_run "p=.git;a=commitdiff;h=non-existent"
not ok 22 - .git commitdiff (non-existent vs HEAD)
#	gitweb_run "p=.git;a=commitdiff;hp=non-existent;h=HEAD"
not ok 23 - .git tree (0000000000000000000000000000000000000000)
#	gitweb_run "p=.git;a=tree;h=0000000000000000000000000000000000000000"
not ok 24 - .git tag (0000000000000000000000000000000000000000)
#	gitweb_run "p=.git;a=tag;h=0000000000000000000000000000000000000000"
not ok 25 - .git blob (non-existent)
#	gitweb_run "p=.git;a=blob;f=non-existent"
not ok 26 - .git blob_plain (non-existent)
#	gitweb_run "p=.git;a=blob_plain;f=non-existent"
not ok 27 - commitdiff(0): root
#	gitweb_run "p=.git;a=commitdiff"
not ok 28 - commitdiff(0): file added
#	echo "New file" > new_file &&
#		 git add new_file &&
#		 git commit -a -m "File added." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 29 - commitdiff(0): mode change
#	test_chmod +x new_file &&
#		 git commit -a -m "Mode changed." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 30 - commitdiff(0): file renamed
#	git mv new_file renamed_file &&
#		 git commit -a -m "File renamed." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 31 - commitdiff(0): file to symlink
#	rm renamed_file &&
#		 test_ln_s_add file renamed_file &&
#		 git commit -a -m "File to symlink." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 32 - commitdiff(0): file deleted
#	git rm renamed_file &&
#		 rm -f renamed_file &&
#		 git commit -a -m "File removed." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 33 - commitdiff(0): file copied / new file
#	cp file file2 &&
#		 git add file2 &&
#		 git commit -a -m "File copied." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 34 - commitdiff(0): mode change and modified
#	echo "New line" >> file2 &&
#		 test_chmod +x file2 &&
#		 git commit -a -m "Mode change and modification." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 35 - commitdiff(0): renamed and modified
#	cat >file2<<EOF &&
#	Dominus regit me,
#	et nihil mihi deerit.
#	In loco pascuae ibi me collocavit,
#	super aquam refectionis educavit me;
#	animam meam convertit,
#	deduxit me super semitas jusitiae,
#	propter nomen suum.
#	EOF
#		 git commit -a -m "File added." &&
#		 git mv file2 file3 &&
#		 echo "Propter nomen suum." >> file3 &&
#		 git commit -a -m "File rename and modification." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 36 - commitdiff(0): renamed, mode change and modified
#	git mv file3 file2 &&
#		 echo "Propter nomen suum." >> file2 &&
#		 test_chmod +x file2 &&
#		 git commit -a -m "File rename, mode change and modification."
&&
#		 gitweb_run "p=.git;a=commitdiff"
ok 37 - setup typechange commits
not ok 38 - commitdiff(2): file renamed from foo to foo/baz
#	gitweb_run
"p=.git;a=commitdiff;hp=initial;h=foo-baz-renamed-from-foo"
not ok 39 - commitdiff(2): file renamed from foo/baz to foo
#	gitweb_run
"p=.git;a=commitdiff;hp=foo-baz-renamed-from-foo;h=initial"
not ok 40 - commitdiff(2): directory becomes file
#	gitweb_run "p=.git;a=commitdiff;hp=foo-becomes-a-directory;h=initial"
not ok 41 - commitdiff(2): file becomes directory
#	gitweb_run "p=.git;a=commitdiff;hp=initial;h=foo-becomes-a-directory"
not ok 42 - commitdiff(2): file becomes symlink
#	gitweb_run "p=.git;a=commitdiff;hp=initial;h=foo-symlinked-to-bar"
not ok 43 - commitdiff(2): symlink becomes file
#	gitweb_run
"p=.git;a=commitdiff;hp=foo-symlinked-to-bar;h=foo-back-to-file"
not ok 44 - commitdiff(2): symlink becomes directory
#	gitweb_run
"p=.git;a=commitdiff;hp=foo-symlinked-to-bar;h=foo-becomes-a-directory"
not ok 45 - commitdiff(2): directory becomes symlink
#	gitweb_run
"p=.git;a=commitdiff;hp=foo-becomes-a-directory;h=foo-symlinked-to-bar"
ok 46 - setup incomplete lines
not ok 47 - commitdiff(1): addition of incomplete line
#
#		gitweb_run "p=.git;a=commitdiff;h=incomplete_lines_add"
#
not ok 48 - commitdiff(1): incomplete line as context line
#
#		gitweb_run "p=.git;a=commitdiff;h=incomplete_lines_ctx"
#
not ok 49 - commitdiff(1): change incomplete line
#
#		gitweb_run "p=.git;a=commitdiff;h=incomplete_lines_chg"
#
not ok 50 - commitdiff(1): removal of incomplete line
#
#		gitweb_run "p=.git;a=commitdiff;h=incomplete_lines_rem"
#
ok 51 - Create a merge
not ok 52 - commit(0): merge commit
#	gitweb_run "p=.git;a=commit"
not ok 53 - commitdiff(0): merge commit
#	gitweb_run "p=.git;a=commitdiff"
ok 54 - Prepare large commit
not ok 55 - commit(1): large commit
#	gitweb_run "p=.git;a=commit;h=b"
not ok 56 - commitdiff(1): large commit
#	gitweb_run "p=.git;a=commitdiff;h=b"
not ok 57 - side-by-side: addition of incomplete line
#
#		gitweb_run
"p=.git;a=commitdiff;h=incomplete_lines_add;ds=sidebyside"
#
not ok 58 - side-by-side: incomplete line as context line
#
#		gitweb_run
"p=.git;a=commitdiff;h=incomplete_lines_ctx;ds=sidebyside"
#
not ok 59 - side-by-side: changed incomplete line
#
#		gitweb_run
"p=.git;a=commitdiff;h=incomplete_lines_chg;ds=sidebyside"
#
not ok 60 - side-by-side: removal of incomplete line
#
#		gitweb_run
"p=.git;a=commitdiff;h=incomplete_lines_rem;ds=sidebyside"
#
not ok 61 - side-by-side: merge commit
#
#		gitweb_run "p=.git;a=commitdiff;h=merge_commit;ds=sidebyside"
#
not ok 62 - tags: list of different types of tags
#	git checkout master &&
#		 git tag -a -m "Tag commit object" tag-commit HEAD &&
#		 git tag -a -m "" tag-commit-nomessage HEAD &&
#		 git tag -a -m "Tag tag object" tag-tag tag-commit &&
#		 git tag -a -m "Tag tree object" tag-tree HEAD^{tree} &&
#		 git tag -a -m "Tag blob object" tag-blob HEAD:file &&
#		 git tag lightweight/tag-commit HEAD &&
#		 git tag lightweight/tag-tag tag-commit &&
#		 git tag lightweight/tag-tree HEAD^{tree} &&
#		 git tag lightweight/tag-blob HEAD:file &&
#		 gitweb_run "p=.git;a=tags"
not ok 63 - tag: Tag to commit object
#	gitweb_run "p=.git;a=tag;h=tag-commit"
not ok 64 - tag: on lightweight tag (invalid)
#	gitweb_run "p=.git;a=tag;h=lightweight/tag-commit"
not ok 65 - logs: log (implicit HEAD)
#	gitweb_run "p=.git;a=log"
not ok 66 - logs: shortlog (implicit HEAD)
#	gitweb_run "p=.git;a=shortlog"
not ok 67 - logs: history (implicit HEAD, file)
#	gitweb_run "p=.git;a=history;f=file"
not ok 68 - logs: history (implicit HEAD, non-existent file)
#	gitweb_run "p=.git;a=history;f=non-existent"
not ok 69 - logs: history (implicit HEAD, deleted file)
#	git checkout master &&
#		 echo "to be deleted" > deleted_file &&
#		 git add deleted_file &&
#		 git commit -m "Add file to be deleted" &&
#		 git rm deleted_file &&
#		 git commit -m "Delete file" &&
#		 gitweb_run "p=.git;a=history;f=deleted_file"
not ok 70 - path_info: project
#	gitweb_run "" "/.git"
not ok 71 - path_info: project/branch
#	gitweb_run "" "/.git/b"
not ok 72 - path_info: project/branch:file
#	gitweb_run "" "/.git/master:file"
not ok 73 - path_info: project/branch:dir/
#	gitweb_run "" "/.git/master:foo/"
not ok 74 - path_info: project/branch (non-existent)
#	gitweb_run "" "/.git/non-existent"
not ok 75 - path_info: project/branch:filename (non-existent branch)
#	gitweb_run "" "/.git/non-existent:non-existent"
not ok 76 - path_info: project/branch:file (non-existent)
#	gitweb_run "" "/.git/master:non-existent"
not ok 77 - path_info: project/branch:dir/ (non-existent)
#	gitweb_run "" "/.git/master:non-existent/"
not ok 78 - path_info: project/branch:/file
#	gitweb_run "" "/.git/master:/file"
not ok 79 - path_info: project/:/file (implicit HEAD)
#	gitweb_run "" "/.git/:/file"
not ok 80 - path_info: project/:/ (implicit HEAD, top tree)
#	gitweb_run "" "/.git/:/"
not ok 81 - feeds: OPML
#	gitweb_run "a=opml"
not ok 82 - feed: RSS
#	gitweb_run "p=.git;a=rss"
not ok 83 - feed: Atom
#	gitweb_run "p=.git;a=atom"
not ok 84 - encode(commit): utf8
#	. "$TEST_DIRECTORY"/t3901-utf8.txt &&
#		 test_when_finished "GIT_AUTHOR_NAME=\"A U Thor\"" &&
#		 test_when_finished "GIT_COMMITTER_NAME=\"C O Mitter\"" &&
#		 echo "UTF-8" >> file &&
#		 git add file &&
#		 git commit -F "$TEST_DIRECTORY"/t3900/1-UTF-8.txt &&
#		 gitweb_run "p=.git;a=commit"
not ok 85 - encode(commit): iso-8859-1
#	. "$TEST_DIRECTORY"/t3901-8859-1.txt &&
#		 test_when_finished "GIT_AUTHOR_NAME=\"A U Thor\"" &&
#		 test_when_finished "GIT_COMMITTER_NAME=\"C O Mitter\"" &&
#		 echo "ISO-8859-1" >> file &&
#		 git add file &&
#		 test_config i18n.commitencoding ISO-8859-1 &&
#		 git commit -F "$TEST_DIRECTORY"/t3900/ISO8859-1.txt &&
#		 gitweb_run "p=.git;a=commit"
not ok 86 - encode(log): utf-8 and iso-8859-1
#	gitweb_run "p=.git;a=log"
not ok 87 - opt: log --no-merges
#	gitweb_run "p=.git;a=log;opt=--no-merges"
not ok 88 - opt: atom --no-merges
#	gitweb_run "p=.git;a=log;opt=--no-merges"
not ok 89 - opt: "file" history --no-merges
#	gitweb_run "p=.git;a=history;f=file;opt=--no-merges"
not ok 90 - opt: log --no-such-option (invalid option)
#	gitweb_run "p=.git;a=log;opt=--no-such-option"
not ok 91 - opt: tree --no-merges (invalid option for action)
#	gitweb_run "p=.git;a=tree;opt=--no-merges"
not ok 92 - URL: no project URLs, no base URL
#	gitweb_run "p=.git;a=summary"
not ok 93 - URL: project URLs via gitweb.url
#	git config --add gitweb.url git://example.com/git/trash.git &&
#	        git config --add gitweb.url http://example.com/git/trash.git
&&
#	        gitweb_run "p=.git;a=summary"
not ok 94 - URL: project URLs via cloneurl file
#	gitweb_run "p=.git;a=summary"
not ok 95 - config override: projects list (implicit)
#	gitweb_run
not ok 96 - config override: tree view, features not overridden in repo
config
#	gitweb_run "p=.git;a=tree"
not ok 97 - config override: tree view, features disabled in repo config
#	git config gitweb.blame no &&
#		 git config gitweb.snapshot none &&
#		 git config gitweb.avatar gravatar &&
#		 gitweb_run "p=.git;a=tree"
not ok 98 - config override: tree view, features enabled in repo config (1)
#	git config gitweb.blame yes &&
#		 git config gitweb.snapshot "zip,tgz, tbz2" &&
#		 gitweb_run "p=.git;a=tree"
not ok 99 - config override: tree view, features enabled in repo config (2)
#	gitweb_run "p=.git;a=tree"
ok 100 - search: preparation
not ok 101 - search: commit author
#	gitweb_run "p=.git;a=search;h=HEAD;st=author;s=A+U+Thor"
not ok 102 - search: commit message
#	gitweb_run "p=.git;a=search;h=HEAD;st=commitr;s=MATCH"
not ok 103 - search: grep
#	gitweb_run "p=.git;a=search;h=HEAD;st=grep;s=MATCH"
not ok 104 - search: pickaxe
#	gitweb_run "p=.git;a=search;h=HEAD;st=pickaxe;s=MATCH"
not ok 105 - search: projects
#	gitweb_run "a=project_list;s=.git"
not ok 106 - README.html with non-ASCII characters (utf-8)
#	echo "<b>UTF-8 example:</b><br />" > .git/README.html &&
#		 cat "$TEST_DIRECTORY"/t3900/1-UTF-8.txt >> .git/README.html &&
#		 gitweb_run "p=.git;a=summary"
Skipping syntax highlighting tests: 'highlight' not found
ok 107 # skip syntax highlighting (no highlight, unknown syntax) (missing
HIGHLIGHT)
ok 108 # skip syntax highlighting (highlighted, shell script) (missing
HIGHLIGHT)
ok 109 - forks: prepare
not ok 110 - forks: projects list
#	gitweb_run
not ok 111 - forks: forks action
#	gitweb_run "p=foo.git;a=forks"
not ok 112 - ctags: tag cloud in projects list
#	mkdir .git/ctags &&
#		 echo "2" > .git/ctags/foo &&
#		 echo "1" > .git/ctags/bar &&
#		gitweb_run
not ok 113 - ctags: search projects by existing tag
#	gitweb_run "by_tag=foo"
not ok 114 - ctags: search projects by non existent tag
#	gitweb_run "by_tag=non-existent"
not ok 115 - ctags: malformed tag weights
#	mkdir -p .git/ctags &&
#		 echo "not-a-number" > .git/ctags/nan &&
#		 echo "not-a-number-2" > .git/ctags/nan2 &&
#		 echo "0.1" >.git/ctags/floating-point &&
#		 gitweb_run
not ok 116 - categories: projects list, only default category
#	echo "\$projects_list_group_categories = 1;" >>gitweb_config.perl &&
#		 gitweb_run
not ok 117 - unborn HEAD: "summary" page (with "heads" subview)
#	git checkout orphan_branch || git checkout --orphan orphan_branch &&
#		 test_when_finished "git checkout master" &&
#		 gitweb_run "p=.git;a=summary"
# failed 108 among 117 test(s)
1..117
make[2]: *** [t9500-gitweb-standalone-no-errors.sh] Error 1
make[2]: Leaving directory
`/home/albert/work/info/install_ver2/git-2.2.2/t'
make[1]: *** [test] Error 2
make[1]: Leaving directory
`/home/albert/work/info/install_ver2/git-2.2.2/t'
make: *** [test] Error 2

Best regards,

Albert Akhriev, PhD
IBM Research - Ireland
Tech. Campus, Bldg 3,  | Mulhuddart, Dublin 15
http://researcher.ibm.com/person/ie-albert_akhriev
albert_akhriev@ie.ibm.com | +353 1 826 91 86

IBM Ireland Limited registered in Ireland under company number 16226.
Registered Office: IBM House, Shelbourne Rd., Ballsbridge, Dublin 4.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Bug Report
       [not found] <CAC34_pT9zwZDnUjo1bTUZabD02M48=_+77-mNCA5adWTgxuYgg@mail.gmail.com>
@ 2013-04-08  5:20 ` Kirk Fraser
  0 siblings, 0 replies; 39+ messages in thread
From: Kirk Fraser @ 2013-04-08  5:20 UTC (permalink / raw)
  To: git

It appears your Amazon download server is too slow.  Perhaps getting
an old used XP system and setting it up as a server will solve this
problem.

Here's the details:


PLATFORM VERSION INFO
	Windows 			: 6.1.7601.65536 (Win32NT)
	Common Language Runtime 	: 4.0.30319.296
	System.Deployment.dll 		: 4.0.30319.1 (RTMRel.030319-0100)
	clr.dll 			: 4.0.30319.296 (RTMGDR.030319-2900)
	dfdll.dll 			: 4.0.30319.1 (RTMRel.030319-0100)

SOURCES
	Deployment url			: http://github-windows.s3.amazonaws.com/GitHub.application
						Server		: AmazonS3
	Application url			:
http://github-windows.s3.amazonaws.com/Application%20Files/GitHub_1_0_41_2/GitHub.exe.manifest
						Server		: AmazonS3

IDENTITIES
	Deployment Identity		: GitHub.application, Version=1.0.41.2,
Culture=neutral, PublicKeyToken=317444273a93ac29,
processorArchitecture=x86
	Application Identity		: GitHub.exe, Version=1.0.41.2,
Culture=neutral, PublicKeyToken=317444273a93ac29,
processorArchitecture=x86, type=win32

APPLICATION SUMMARY
	* Installable application.
	* Trust url parameter is set.
ERROR SUMMARY
	Below is a summary of the errors, details of these errors are listed
later in the log.
	* Activation of
http://github-windows.s3.amazonaws.com/GitHub.application resulted in
exception. Following failure messages were detected:
		+ Downloading http://github-windows.s3.amazonaws.com/Application
Files/GitHub_1_0_41_2/7za.exe.deploy did not succeed.
		+ Unable to read data from the transport connection: An existing
connection was forcibly closed by the remote host.
		+ An existing connection was forcibly closed by the remote host

COMPONENT STORE TRANSACTION FAILURE SUMMARY
	No transaction error was detected.

WARNINGS
	There were no warnings during this operation.

OPERATION PROGRESS STATUS
	* [4/7/2013 9:17:17 PM] : Activation of
http://github-windows.s3.amazonaws.com/GitHub.application has started.
	* [4/7/2013 9:17:30 PM] : Processing of deployment manifest has
successfully completed.
	* [4/7/2013 9:17:30 PM] : Installation of the application has started.
	* [4/7/2013 9:17:34 PM] : Processing of application manifest has
successfully completed.
	* [4/7/2013 9:23:57 PM] : Found compatible runtime version 4.0.30319.
	* [4/7/2013 9:23:57 PM] : Request of trust and detection of platform
is complete.

ERROR DETAILS
	Following errors were detected during this operation.
	* [4/7/2013 9:51:39 PM]
System.Deployment.Application.DeploymentDownloadException (Unknown
subtype)
		- Downloading http://github-windows.s3.amazonaws.com/Application
Files/GitHub_1_0_41_2/7za.exe.deploy did not succeed.
		- Source: System.Deployment
		- Stack trace:
			at System.Deployment.Application.SystemNetDownloader.DownloadSingleFile(DownloadQueueItem
next)
			at System.Deployment.Application.SystemNetDownloader.DownloadAllFiles()
			at System.Deployment.Application.FileDownloader.Download(SubscriptionState
subState)
			at System.Deployment.Application.DownloadManager.DownloadDependencies(SubscriptionState
subState, AssemblyManifest deployManifest, AssemblyManifest
appManifest, Uri sourceUriBase, String targetDirectory, String group,
IDownloadNotification notification, DownloadOptions options)
			at System.Deployment.Application.ApplicationActivator.DownloadApplication(SubscriptionState
subState, ActivationDescription actDesc, Int64 transactionId,
TempDirectory& downloadTemp)
			at System.Deployment.Application.ApplicationActivator.InstallApplication(SubscriptionState&
subState, ActivationDescription actDesc)
			at System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri
activationUri, Boolean isShortcut, String textualSubId, String
deploymentProviderUrlFromExtension, BrowserSettings browserSettings,
String& errorPageUrl)
			at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object
state)
		--- Inner Exception ---
		System.IO.IOException
		- Unable to read data from the transport connection: An existing
connection was forcibly closed by the remote host.
		- Source: System
		- Stack trace:
			at System.Net.ConnectStream.Read(Byte[] buffer, Int32 offset, Int32 size)
			at System.Deployment.Application.SystemNetDownloader.DownloadSingleFile(DownloadQueueItem
next)
		--- Inner Exception ---
		System.Net.Sockets.SocketException
		- An existing connection was forcibly closed by the remote host
		- Source: System
		- Stack trace:
			at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset,
Int32 size, SocketFlags socketFlags)
			at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32
offset, Int32 size)

COMPONENT STORE TRANSACTION DETAILS
	No transaction information is available.



-- 
Kirk W. Fraser
http://freetom.info/TrueChurch - Replace the fraud churches with the
true church.
http://congressionalbiblestudy.org - Fix America by first fixing its
Christian foundation.
http://freetom.info - Example of False Justice common in America

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2012-10-09 17:17           ` John Whitney
@ 2012-10-09 19:00             ` John Whitney
  0 siblings, 0 replies; 39+ messages in thread
From: John Whitney @ 2012-10-09 19:00 UTC (permalink / raw)
  To: Jeff King; +Cc: Phil Hord, git

On 10/9/12 12:17 PM, John Whitney wrote:
> Thank you very much for your detailed explanations. I suspected that 
> efficiency concerns might be preventing a clean solution.
>
> How about this idea... When git stores files, it could include a bit 
> of metadata that tells it whether the file is a binary blob or text. 
> (Perhaps it already does this?) If a binary blob (in the repository) 
> is being compared with a text file (on the filesystem), git could 
> re-process the blob and get the "sha1 of the canonical stripped 
> version". In all other situations, the original SHA1 should be 
> correct, since git already removes CRs from the line endings in files 
> it recognizes as text.
>
> I would think that this solution would have no performance penalty for 
> "fixed" repositories. (It would only have a small performance hit when 
> binary blobs are compared against text files, which is rare even in 
> broken repositories.) Git could even throw a warning like: "File 
> xyz.txt was originally stored as a binary blob."
>
> What do you think?
>
>    ---John
>
I'm going to reply to myself, to save you the trouble of replying. 
(You've been very helpful and I do appreciate it.)

I guess the problem with this idea is that git doesn't have any way to 
distinguish between binary blobs and text files in the repository. I 
think it would be useful information, but I guess that bridge burned a 
long time ago. So any metadata would have to be stored separately. Jeff, 
that's roughly equivalent to your idea of caching, which would take a 
lot of work to implement.

Thank you so much for helping me to understand the reason git behaves 
the way it does. It's a great tool!

    ---John

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2012-10-07 23:52         ` Jeff King
@ 2012-10-09 17:17           ` John Whitney
  2012-10-09 19:00             ` John Whitney
  0 siblings, 1 reply; 39+ messages in thread
From: John Whitney @ 2012-10-09 17:17 UTC (permalink / raw)
  To: Jeff King; +Cc: Phil Hord, git

On 10/7/12 6:52 PM, Jeff King wrote:
>> Yes, but does that really have to be an issue? Is there any technical 
>> or practical reason you can think of that the repository shouldn't 
>> ignore those CRs? 
> It's significantly less efficient. Right now git only has to do the
> conversion when updating the index cache of what's on the filesystem
> (i.e., when it would be doing a sha1 over the file contents _anyway_).
> And then it can compare sha1s internally, because it knows that all of
> the sha1s it has computed are for the canonical in-repo versions of the
> file.
>
> If we assume that the in-repo file might need to have CRs stripped, then
> we need to actually follow up every sha1 mismatch with an actual content
> diff in order to discover if it really is different or not. We could
> cache the "true" sha1 of the canonical stripped version to avoid this,
> but now we are getting much more complex. In most cases it is sufficient
> to just commit the cleaned up contents and then never worry about it
> again.
>
>> You're right, we can't magically avoid all the line ending issues
>> that people will run into. In this case, though, I think git can
>> sidestep a fairly obnoxious problem. My example was simple, but when
>> you've got multiple branches that need to be rebased/merged, it can
>> get pretty hairy. The repository will never be truly "clean" unless
>> you rewrite the whole thing (using filter-branch, for instance).
> Right. Git's current approach is very hairy when you are looking at
> history that crosses a CRLF flag-day boundary. It's definitely a
> weakness of the canonicalization approach. But other approaches also
> have downsides; I don't want to catalogue them all here, but you can
> certainly search the archive for various discussions and flamewars about
> how line endings are handled.
>
>> Maybe my above suggestion is more of a feature request than a bug,
> Fair enough. I think your complaint is real, but I think nobody has been
> clever enough yet to devise a solution that does not have too many other
> downsides. And of course you are free to propose such an approach if you
> have thought of one. :)
>
>> but there is the obvious bug that after changing .gitattributes, git
>> still doesn't notice that files are "modified" until you modify them
>> again in some way (touch works). I only noticed the CRs in our own
>> repository after I tried to rebase a branch and got strange errors.
>> To make git notice all the files, I had to "find . -type f -exec
>> touch {} \;".
> I think the idea has been floated before of unconditionally refreshing
> the index when you update the crlf config via "git config". But of
> course that can only fix a fraction of the cases. You might edit it with
> an editor. Or they may be new lines in .gitattributes. Or a change of
> wildcard lines in .gitattributes.
>
> Really, the issue is that the index contains a cache of what's in the
> files that is considered valid unless the stat information of the file
> changes. But that is obviously not the full story, as the
> canonicalization rules (CRLF handling or smudge/clean filters) can
> change, too, and that is not considered as part of the cache's validity.
> Doing it "right" would mean that anytime the attributes or config files
> changed, we would consider the cache entry dirty and re-read (and
> re-canonicalize) the file.
>
> But that has either:
>
>    1. Bad complexity. It means our cache validity needs to know about
>       exactly which rules were applied to yield the cached sha1. And
>       those rules can be complex, consisting of wildcard matching,
>       cross-referencing custom filters from config, etc.
>
>    2. Bad performance. If you instead just invalidate cached sha1s when
>       the gitattributes or .git/config file changes, you catch way too
>       many cases. E.g., if you checkout a branch that changes
>       .gitattributes, we have to re-read every file in the repository,
>       even though most of them will not be affected.
>
> So I think it's possible to handle this case correctly, but doing it
> right is quite complex. So we have the "just manually poke the files
> when you make such a change". Which is a horrible user experience, but
> works OK in practice (and many people do not run into it at all, because
> on new projects they set the filter attributes very early on, before
> they have an existing history).
>
> IOW, no, it is not pretty, but these are all known issues that nobody
> has felt it worth tackling yet.
>
> -Peff

Thank you very much for your detailed explanations. I suspected that 
efficiency concerns might be preventing a clean solution.

How about this idea... When git stores files, it could include a bit of 
metadata that tells it whether the file is a binary blob or text. 
(Perhaps it already does this?) If a binary blob (in the repository) is 
being compared with a text file (on the filesystem), git could 
re-process the blob and get the "sha1 of the canonical stripped 
version". In all other situations, the original SHA1 should be correct, 
since git already removes CRs from the line endings in files it 
recognizes as text.

I would think that this solution would have no performance penalty for 
"fixed" repositories. (It would only have a small performance hit when 
binary blobs are compared against text files, which is rare even in 
broken repositories.) Git could even throw a warning like: "File xyz.txt 
was originally stored as a binary blob."

What do you think?

    ---John

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2012-10-07  2:23       ` John Whitney
@ 2012-10-07 23:52         ` Jeff King
  2012-10-09 17:17           ` John Whitney
  0 siblings, 1 reply; 39+ messages in thread
From: Jeff King @ 2012-10-07 23:52 UTC (permalink / raw)
  To: John Whitney; +Cc: Phil Hord, git

On Sat, Oct 06, 2012 at 09:23:59PM -0500, John Whitney wrote:

> >You said in your test script:
> >
> >   # Committing test.txt or clearing .gitattributes does clear
> >   # the "modified" status, but those options are undesirable
> >
> >Why is the commit undesirable? You have decided that CRs will no longer
> >be tolerated in your repository (by setting .gitattributes). Now you
> >need to record that change in history with a commit that strips out the
> >CRs.
> In some cases it's undesirable. In my example, all I want to do is
> merge in the change that deletes the file, so I don't want to have to
> add that extra commit when I'm just going to delete the file anyway.

Yes, but that is conflating two operations. You only don't want to do
the commit because you are anticipating what is coming next (the
cherry-picked deletion). But if you want to conflate, then you could
also realize that you can simply delete the file, CRs or no, and you do
not need to care about its modified state.

I think a much stronger argument for your position is that the cherry
pick would not happen without a conflict after such a commit, because it
would be deleting files with two different sets of content (the
cherry-pick would want to delete the CR version, but you would not have
that version).

In other words, you want the cherry-pick to happen and ignore the
modification that could be committed, because you know the modification
is not relevant (but git does not). But there is not a way to do that
(even once you overcome the confusion), because the usual way to do so
is to drop the local modification with "git reset" (which would not work
in this case).

> >It is not about having CRs in the working tree file. Those are now
> >considered uninteresting and stripped by git when comparing to the HEAD.
> >The problem is that what's in your _repository_ has CRs.
> Yes, but does that really have to be an issue? Is there any technical
> or practical reason you can think of that the repository shouldn't
> ignore those CRs?

It's significantly less efficient. Right now git only has to do the
conversion when updating the index cache of what's on the filesystem
(i.e., when it would be doing a sha1 over the file contents _anyway_).
And then it can compare sha1s internally, because it knows that all of
the sha1s it has computed are for the canonical in-repo versions of the
file.

If we assume that the in-repo file might need to have CRs stripped, then
we need to actually follow up every sha1 mismatch with an actual content
diff in order to discover if it really is different or not. We could
cache the "true" sha1 of the canonical stripped version to avoid this,
but now we are getting much more complex. In most cases it is sufficient
to just commit the cleaned up contents and then never worry about it
again.

> You're right, we can't magically avoid all the line ending issues
> that people will run into. In this case, though, I think git can
> sidestep a fairly obnoxious problem. My example was simple, but when
> you've got multiple branches that need to be rebased/merged, it can
> get pretty hairy. The repository will never be truly "clean" unless
> you rewrite the whole thing (using filter-branch, for instance).

Right. Git's current approach is very hairy when you are looking at
history that crosses a CRLF flag-day boundary. It's definitely a
weakness of the canonicalization approach. But other approaches also
have downsides; I don't want to catalogue them all here, but you can
certainly search the archive for various discussions and flamewars about
how line endings are handled.

> Maybe my above suggestion is more of a feature request than a bug,

Fair enough. I think your complaint is real, but I think nobody has been
clever enough yet to devise a solution that does not have too many other
downsides. And of course you are free to propose such an approach if you
have thought of one. :)

> but there is the obvious bug that after changing .gitattributes, git
> still doesn't notice that files are "modified" until you modify them
> again in some way (touch works). I only noticed the CRs in our own
> repository after I tried to rebase a branch and got strange errors.
> To make git notice all the files, I had to "find . -type f -exec
> touch {} \;".

I think the idea has been floated before of unconditionally refreshing
the index when you update the crlf config via "git config". But of
course that can only fix a fraction of the cases. You might edit it with
an editor. Or they may be new lines in .gitattributes. Or a change of
wildcard lines in .gitattributes.

Really, the issue is that the index contains a cache of what's in the
files that is considered valid unless the stat information of the file
changes. But that is obviously not the full story, as the
canonicalization rules (CRLF handling or smudge/clean filters) can
change, too, and that is not considered as part of the cache's validity.
Doing it "right" would mean that anytime the attributes or config files
changed, we would consider the cache entry dirty and re-read (and
re-canonicalize) the file.

But that has either:

  1. Bad complexity. It means our cache validity needs to know about
     exactly which rules were applied to yield the cached sha1. And
     those rules can be complex, consisting of wildcard matching,
     cross-referencing custom filters from config, etc.

  2. Bad performance. If you instead just invalidate cached sha1s when
     the gitattributes or .git/config file changes, you catch way too
     many cases. E.g., if you checkout a branch that changes
     .gitattributes, we have to re-read every file in the repository,
     even though most of them will not be affected.

So I think it's possible to handle this case correctly, but doing it
right is quite complex. So we have the "just manually poke the files
when you make such a change". Which is a horrible user experience, but
works OK in practice (and many people do not run into it at all, because
on new projects they set the filter attributes very early on, before
they have an existing history).

IOW, no, it is not pretty, but these are all known issues that nobody
has felt it worth tackling yet.

-Peff

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2012-10-06 13:31     ` Jeff King
@ 2012-10-07  2:23       ` John Whitney
  2012-10-07 23:52         ` Jeff King
  0 siblings, 1 reply; 39+ messages in thread
From: John Whitney @ 2012-10-07  2:23 UTC (permalink / raw)
  To: Jeff King; +Cc: Phil Hord, git

On 10/6/12 8:31 AM, Jeff King wrote:
> On Thu, Oct 04, 2012 at 11:10:40AM -0500, John Whitney wrote:
>
>> Thank you for your response. I do see the dilemma, but having
>> no possible "unmodified" state is extremely inconvenient and,
>> as shown, breaks basic git operations.
> But you have asked for an impossible state. You have said "this file
> cannot have CR when you check it in, because we erase them". And yet the
> version of the file in HEAD has CRs in it. So it must appear modified
> with respect to HEAD.  And the solution is to make a commit with the
> normalized content.
I guess I'd really like to see git ignore all line endings of text files 
in the repository. Text files would then never be marked as "modified" 
for this reason and there would be no need to "fix" the line endings. I 
think that should be the default, but just having the option would be nice.

> You said in your test script:
>
>    # Committing test.txt or clearing .gitattributes does clear
>    # the "modified" status, but those options are undesirable
>
> Why is the commit undesirable? You have decided that CRs will no longer
> be tolerated in your repository (by setting .gitattributes). Now you
> need to record that change in history with a commit that strips out the
> CRs.
In some cases it's undesirable. In my example, all I want to do is merge 
in the change that deletes the file, so I don't want to have to add that 
extra commit when I'm just going to delete the file anyway. It's also 
very inconvenient to have to deal with this issue when you're in the 
middle of a complex rebase operation.

>> I guess my thought is that if git doesn't allow CRs to be checked
>> in, then it should strip the CRs when checking the file out, and
>> consider that form (or both forms) as "unmodified". It just
>> doesn't make sense to me that files are considered modified
>> immediately after checkout.
> It is not about having CRs in the working tree file. Those are now
> considered uninteresting and stripped by git when comparing to the HEAD.
> The problem is that what's in your _repository_ has CRs.
Yes, but does that really have to be an issue? Is there any technical or 
practical reason you can think of that the repository shouldn't ignore 
those CRs?

> I wonder if this is a fundamental misunderstanding of how the CRLF
> handling in git works. It is not "magically make me not care about line
> endings anymore". It is "the canonical version in the repo is LF-only.
> Strip anything coming into the repository to match that, and
> (optionally) add CR to anything going out to the filesystem for my
> convenience". But you need a flag day to update the in-repository
> versions to the new scheme.
>
> -Peff
You're right, we can't magically avoid all the line ending issues that 
people will run into. In this case, though, I think git can sidestep a 
fairly obnoxious problem. My example was simple, but when you've got 
multiple branches that need to be rebased/merged, it can get pretty 
hairy. The repository will never be truly "clean" unless you rewrite the 
whole thing (using filter-branch, for instance).

Maybe my above suggestion is more of a feature request than a bug, but 
there is the obvious bug that after changing .gitattributes, git still 
doesn't notice that files are "modified" until you modify them again in 
some way (touch works). I only noticed the CRs in our own repository 
after I tried to rebase a branch and got strange errors. To make git 
notice all the files, I had to "find . -type f -exec touch {} \;".

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2012-10-04 16:10   ` John Whitney
@ 2012-10-06 13:31     ` Jeff King
  2012-10-07  2:23       ` John Whitney
  0 siblings, 1 reply; 39+ messages in thread
From: Jeff King @ 2012-10-06 13:31 UTC (permalink / raw)
  To: John Whitney; +Cc: Phil Hord, git

On Thu, Oct 04, 2012 at 11:10:40AM -0500, John Whitney wrote:

> Thank you for your response. I do see the dilemma, but having
> no possible "unmodified" state is extremely inconvenient and,
> as shown, breaks basic git operations.

But you have asked for an impossible state. You have said "this file
cannot have CR when you check it in, because we erase them". And yet the
version of the file in HEAD has CRs in it. So it must appear modified
with respect to HEAD.  And the solution is to make a commit with the
normalized content.

You said in your test script:

  # Committing test.txt or clearing .gitattributes does clear
  # the "modified" status, but those options are undesirable

Why is the commit undesirable? You have decided that CRs will no longer
be tolerated in your repository (by setting .gitattributes). Now you
need to record that change in history with a commit that strips out the
CRs.

> I guess my thought is that if git doesn't allow CRs to be checked
> in, then it should strip the CRs when checking the file out, and
> consider that form (or both forms) as "unmodified". It just
> doesn't make sense to me that files are considered modified
> immediately after checkout.

It is not about having CRs in the working tree file. Those are now
considered uninteresting and stripped by git when comparing to the HEAD.
The problem is that what's in your _repository_ has CRs.

I wonder if this is a fundamental misunderstanding of how the CRLF
handling in git works. It is not "magically make me not care about line
endings anymore". It is "the canonical version in the repo is LF-only.
Strip anything coming into the repository to match that, and
(optionally) add CR to anything going out to the filesystem for my
convenience". But you need a flag day to update the in-repository
versions to the new scheme.

-Peff

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2012-10-05 10:47   ` cmn
@ 2012-10-05 11:03     ` Муковников Михаил
  0 siblings, 0 replies; 39+ messages in thread
From: Муковников Михаил @ 2012-10-05 11:03 UTC (permalink / raw)
  To: cmn; +Cc: git

Carlos, thank you very much, core.precomposeunicode works just like you said.
And you're right, it seems the problem is in HFS+, 'git add .' worked as well, so did even 'git add test_*'.
The problem seems solved.

05.10.2012, в 14:47, cmn@elego.de (Carlos Martín Nieto) написал(а):

> Konstantin Khomoutov <flatworm@users.sourceforge.net> writes:
> 
>> On Fri, 5 Oct 2012 14:13:49 +0400
>> Муковников Михаил <m.mukovnikov@gmail.com> wrote:
>> 
>>> There's a problem using git with files having cyrillic 'й' in their
>>> name, git just can't track them.
>>> 
>>> uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25
>>> 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 git
>>> version: 1.7.12.1 (from macports)
>>> 
>>> Steps to reproduce:
>>> - git init
>>> - touch test_й
>>> - git status (should be "untracked files present")
>>> - git add test_й
>>> - git status
>>> 
>>> # Untracked files:
>>> #   (use "git add <file>..." to include in what will be committed)
>>> #
>>> #	"test_\320\270\314\206"
>>> nothing added to commit but untracked files present (use "git add" to
>>> track)
>>> 
>>> Could this be helped somehow?--
>> 
>> What "this"?  If you mean displaying escapes for UTF-8 bytes
>> representing that letter "й", then try setting core.quotepath to false
>> for this repository and see if that helps.
> 
> Notice the 'git add test_й'. The problem is that git reports it as untracked.
> 
> Михаил, is this the whole output or do you also see a
> differently-escaped version of the filename under tracked files? Does
> this problem not show up if you use 'git add -A' or 'git add .' instead
> of typing the name? If so, this happens because HFS+ stores and reports
> names differently than the way we told it to store it, so git sees a
> different set of bytes than what it's expecting and considers it a
> different file.
> 
> With a recent version of git, you can set the core.precomposeunicode
> config setting to true, which deals with this situation. This tells git
> to transform the data it gets from the filesystem to the format that
> everyone else uses, which helps not only this, but also the 'git add .'
> case, so git stores the filename in the format the same way that other
> OSs expect to find.
> 
>   cmn

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2012-10-05 10:32 ` Konstantin Khomoutov
  2012-10-05 10:47   ` cmn
@ 2012-10-05 10:52   ` Муковников Михаил
  1 sibling, 0 replies; 39+ messages in thread
From: Муковников Михаил @ 2012-10-05 10:52 UTC (permalink / raw)
  To: git

Hey, Konstantin!
Thanks for your reply. My bad, I described the problem not very well. I don't mind displaying escapes etc. (core.quotepath just makes "\320\270\314\206" be "Ê" and that's it), the problem is that git cannot track files with cyrillic "Ê" in their name. I created a file, added it but git writes it's still untracked, and it seems there's no way to track it.

05.10.2012, × 14:32, Konstantin Khomoutov <flatworm@users.sourceforge.net> ÎÁÐÉÓÁÌ(Á):

> On Fri, 5 Oct 2012 14:13:49 +0400
> íÕËÏ×ÎÉËÏ× íÉÈÁÉÌ <m.mukovnikov@gmail.com> wrote:
> 
>> There's a problem using git with files having cyrillic 'Ê' in their
>> name, git just can't track them.
>> 
>> uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25
>> 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 git
>> version: 1.7.12.1 (from macports)
>> 
>> Steps to reproduce:
>> - git init
>> - touch test_Ê
>> - git status (should be "untracked files present")
>> - git add test_Ê
>> - git status
>> 
>> # Untracked files:
>> #   (use "git add <file>..." to include in what will be committed)
>> #
>> #	"test_\320\270\314\206"
>> nothing added to commit but untracked files present (use "git add" to
>> track)
>> 
>> Could this be helped somehow?--
> 
> What "this"?  If you mean displaying escapes for UTF-8 bytes
> representing that letter "Ê", then try setting core.quotepath to false
> for this repository and see if that helps.
> 
> More info can be found in the git-config manual page.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2012-10-05 10:32 ` Konstantin Khomoutov
@ 2012-10-05 10:47   ` cmn
  2012-10-05 11:03     ` Муковников Михаил
  2012-10-05 10:52   ` Муковников Михаил
  1 sibling, 1 reply; 39+ messages in thread
From: cmn @ 2012-10-05 10:47 UTC (permalink / raw)
  To: Konstantin Khomoutov
  Cc: Муковников
	Михаил,
	git

Konstantin Khomoutov <flatworm@users.sourceforge.net> writes:

> On Fri, 5 Oct 2012 14:13:49 +0400
> Муковников Михаил <m.mukovnikov@gmail.com> wrote:
>
>> There's a problem using git with files having cyrillic 'й' in their
>> name, git just can't track them.
>> 
>> uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25
>> 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 git
>> version: 1.7.12.1 (from macports)
>> 
>> Steps to reproduce:
>> - git init
>> - touch test_й
>> - git status (should be "untracked files present")
>> - git add test_й
>> - git status
>> 
>> # Untracked files:
>> #   (use "git add <file>..." to include in what will be committed)
>> #
>> #	"test_\320\270\314\206"
>> nothing added to commit but untracked files present (use "git add" to
>> track)
>> 
>> Could this be helped somehow?--
>
> What "this"?  If you mean displaying escapes for UTF-8 bytes
> representing that letter "й", then try setting core.quotepath to false
> for this repository and see if that helps.

Notice the 'git add test_й'. The problem is that git reports it as untracked.

Михаил, is this the whole output or do you also see a
differently-escaped version of the filename under tracked files? Does
this problem not show up if you use 'git add -A' or 'git add .' instead
of typing the name? If so, this happens because HFS+ stores and reports
names differently than the way we told it to store it, so git sees a
different set of bytes than what it's expecting and considers it a
different file.

With a recent version of git, you can set the core.precomposeunicode
config setting to true, which deals with this situation. This tells git
to transform the data it gets from the filesystem to the format that
everyone else uses, which helps not only this, but also the 'git add .'
case, so git stores the filename in the format the same way that other
OSs expect to find.

   cmn

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2012-10-05 10:13 Bug report Муковников Михаил
@ 2012-10-05 10:32 ` Konstantin Khomoutov
  2012-10-05 10:47   ` cmn
  2012-10-05 10:52   ` Муковников Михаил
  0 siblings, 2 replies; 39+ messages in thread
From: Konstantin Khomoutov @ 2012-10-05 10:32 UTC (permalink / raw)
  To: Муковников
	Михаил
  Cc: git

On Fri, 5 Oct 2012 14:13:49 +0400
íÕËÏ×ÎÉËÏ× íÉÈÁÉÌ <m.mukovnikov@gmail.com> wrote:

> There's a problem using git with files having cyrillic 'Ê' in their
> name, git just can't track them.
> 
> uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25
> 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 git
> version: 1.7.12.1 (from macports)
> 
> Steps to reproduce:
> - git init
> - touch test_Ê
> - git status (should be "untracked files present")
> - git add test_Ê
> - git status
> 
> # Untracked files:
> #   (use "git add <file>..." to include in what will be committed)
> #
> #	"test_\320\270\314\206"
> nothing added to commit but untracked files present (use "git add" to
> track)
> 
> Could this be helped somehow?--

What "this"?  If you mean displaying escapes for UTF-8 bytes
representing that letter "Ê", then try setting core.quotepath to false
for this repository and see if that helps.

More info can be found in the git-config manual page.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Bug report
@ 2012-10-05 10:13 Муковников Михаил
  2012-10-05 10:32 ` Konstantin Khomoutov
  0 siblings, 1 reply; 39+ messages in thread
From: Муковников Михаил @ 2012-10-05 10:13 UTC (permalink / raw)
  To: git

There's a problem using git with files having cyrillic 'Ê' in their name, git just can't track them.

uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
git version: 1.7.12.1 (from macports)

Steps to reproduce:
- git init
- touch test_Ê
- git status (should be "untracked files present")
- git add test_Ê
- git status

# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	"test_\320\270\314\206"
nothing added to commit but untracked files present (use "git add" to track)

Could this be helped somehow?

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2012-10-04 16:16   ` John Whitney
  2012-10-04 16:28     ` John Whitney
@ 2012-10-04 17:01     ` Andrew Wong
  1 sibling, 0 replies; 39+ messages in thread
From: Andrew Wong @ 2012-10-04 17:01 UTC (permalink / raw)
  To: John Whitney; +Cc: git

On 10/04/2012 12:16 PM, John Whitney wrote:
> This problem occurs on Mac, Windows, and Linux, and
> with multiple versions of git. Note that in my script a CR
> is appended to test.txt. On the Mac, you can generate this
> in Terminal by pressing Ctrl-V Ctrl-M. Or, alternatively,
> just download and run the script like this: "sh git_failure.sh"
Ah, yes. I can reproduce the problem. I was pasting the lines from your 
script. And I saw a new line in the shell when I pasted, so I thought 
the ^M was kept properly. But somewhere during the pasting, the ^M must 
have got translated to a \n automatically. Silly me.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2012-10-04 16:16   ` John Whitney
@ 2012-10-04 16:28     ` John Whitney
  2012-10-04 17:01     ` Andrew Wong
  1 sibling, 0 replies; 39+ messages in thread
From: John Whitney @ 2012-10-04 16:28 UTC (permalink / raw)
  To: Andrew Wong; +Cc: git

Andrew,

I forgot to say that all of the config settings
are not changed from the default.

    ---John


On 10/4/12 11:16 AM, John Whitney wrote:
> Andrew,
>
> Thanks for checking this on your machine.
>
> This problem occurs on Mac, Windows, and Linux, and
> with multiple versions of git. Note that in my script a CR
> is appended to test.txt. On the Mac, you can generate this
> in Terminal by pressing Ctrl-V Ctrl-M. Or, alternatively,
> just download and run the script like this: "sh git_failure.sh"
>
>    ---John
>
>
> On 10/4/12 10:21 AM, Andrew Wong wrote:
>> On 10/04/2012 12:35 AM, John Whitney wrote:
>>> I just ran into a problem that I'm pretty sure is a bug in git. Just 
>>> read and run this (fairly trivial) shell script to replicate.
>> I tried your steps on a Mac, but I wasn't able to produce the issue. 
>> Perhaps I don't have the right CRLF configs to trigger the issue. 
>> I've tried it on v1.7.9.6, which came with Xcode, and v1.7.7. What 
>> git version are you using? And, if any, what are your configs for 
>> "core.eol", "core.safecrlf", and "core.autocrlf" ?
>>
>> What Phil said also makes sense though.
>>
>
>


-- 
Great support for great users! Please visit http://emsoftware.com/support/ for our support policies, instructions and FAQs.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2012-10-04 15:21 ` Andrew Wong
@ 2012-10-04 16:16   ` John Whitney
  2012-10-04 16:28     ` John Whitney
  2012-10-04 17:01     ` Andrew Wong
  0 siblings, 2 replies; 39+ messages in thread
From: John Whitney @ 2012-10-04 16:16 UTC (permalink / raw)
  To: Andrew Wong; +Cc: git

Andrew,

Thanks for checking this on your machine.

This problem occurs on Mac, Windows, and Linux, and
with multiple versions of git. Note that in my script a CR
is appended to test.txt. On the Mac, you can generate this
in Terminal by pressing Ctrl-V Ctrl-M. Or, alternatively,
just download and run the script like this: "sh git_failure.sh"

    ---John


On 10/4/12 10:21 AM, Andrew Wong wrote:
> On 10/04/2012 12:35 AM, John Whitney wrote:
>> I just ran into a problem that I'm pretty sure is a bug in git. Just 
>> read and run this (fairly trivial) shell script to replicate.
> I tried your steps on a Mac, but I wasn't able to produce the issue. 
> Perhaps I don't have the right CRLF configs to trigger the issue. I've 
> tried it on v1.7.9.6, which came with Xcode, and v1.7.7. What git 
> version are you using? And, if any, what are your configs for 
> "core.eol", "core.safecrlf", and "core.autocrlf" ?
>
> What Phil said also makes sense though.
>


-- 
Great support for great users! Please visit http://emsoftware.com/support/ for our support policies, instructions and FAQs.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2012-10-04 14:19 ` Phil Hord
@ 2012-10-04 16:10   ` John Whitney
  2012-10-06 13:31     ` Jeff King
  0 siblings, 1 reply; 39+ messages in thread
From: John Whitney @ 2012-10-04 16:10 UTC (permalink / raw)
  To: Phil Hord; +Cc: git

Phil,

Thank you for your response. I do see the dilemma, but having
no possible "unmodified" state is extremely inconvenient and,
as shown, breaks basic git operations.

I guess my thought is that if git doesn't allow CRs to be checked
in, then it should strip the CRs when checking the file out, and
consider that form (or both forms) as "unmodified". It just
doesn't make sense to me that files are considered modified
immediately after checkout.

Any thoughts as to why this would not work?

    ---John

On 10/4/12 9:19 AM, Phil Hord wrote:
> On Thu, Oct 4, 2012 at 12:35 AM, John Whitney <jjw@emsoftware.com> wrote:
>> I just ran into a problem that I'm pretty sure is a bug in git. Just read
>> and run this (fairly trivial) shell script to replicate.
> When you added "* text=auto" in the .gitattributes file, you changed
> what git considers to be the checked-in file content state for
> test.txt.  The file contents in your working directory do not match
> what git expects to check in.  Therefore, the file appears to be
> different.  If you commit the file "changes" the problem goes away.
>
> This is more of a workaround than an a satisfying explanation.  If you
> then checkout the original HEAD commit (but with .gitattributes
> present) you will see the problem appear again.  But in a sense,
> adding .gitattributes this way is an act of foot-shooting.   The best
> way forward may be to normalize your repository by removing all CR's
> from files in history.  If you do not have this freedom, your best bet
> may be to normalize the repo in the current commit and move on.
>
> Others with more intimate insight into the CRLF journey in git's past
> may have better advice.
>
> Phil
>


-- 
Great support for great users! Please visit http://emsoftware.com/support/ for our support policies, instructions and FAQs.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2012-10-04  4:35 John Whitney
  2012-10-04 14:19 ` Phil Hord
@ 2012-10-04 15:21 ` Andrew Wong
  2012-10-04 16:16   ` John Whitney
  1 sibling, 1 reply; 39+ messages in thread
From: Andrew Wong @ 2012-10-04 15:21 UTC (permalink / raw)
  To: John Whitney; +Cc: git

On 10/04/2012 12:35 AM, John Whitney wrote:
> I just ran into a problem that I'm pretty sure is a bug in git. Just 
> read and run this (fairly trivial) shell script to replicate.
I tried your steps on a Mac, but I wasn't able to produce the issue. 
Perhaps I don't have the right CRLF configs to trigger the issue. I've 
tried it on v1.7.9.6, which came with Xcode, and v1.7.7. What git 
version are you using? And, if any, what are your configs for 
"core.eol", "core.safecrlf", and "core.autocrlf" ?

What Phil said also makes sense though.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug report
  2012-10-04  4:35 John Whitney
@ 2012-10-04 14:19 ` Phil Hord
  2012-10-04 16:10   ` John Whitney
  2012-10-04 15:21 ` Andrew Wong
  1 sibling, 1 reply; 39+ messages in thread
From: Phil Hord @ 2012-10-04 14:19 UTC (permalink / raw)
  To: John Whitney; +Cc: git

On Thu, Oct 4, 2012 at 12:35 AM, John Whitney <jjw@emsoftware.com> wrote:
> I just ran into a problem that I'm pretty sure is a bug in git. Just read
> and run this (fairly trivial) shell script to replicate.

When you added "* text=auto" in the .gitattributes file, you changed
what git considers to be the checked-in file content state for
test.txt.  The file contents in your working directory do not match
what git expects to check in.  Therefore, the file appears to be
different.  If you commit the file "changes" the problem goes away.

This is more of a workaround than an a satisfying explanation.  If you
then checkout the original HEAD commit (but with .gitattributes
present) you will see the problem appear again.  But in a sense,
adding .gitattributes this way is an act of foot-shooting.   The best
way forward may be to normalize your repository by removing all CR's
from files in history.  If you do not have this freedom, your best bet
may be to normalize the repo in the current commit and move on.

Others with more intimate insight into the CRLF journey in git's past
may have better advice.

Phil

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Bug report
@ 2012-10-04  4:35 John Whitney
  2012-10-04 14:19 ` Phil Hord
  2012-10-04 15:21 ` Andrew Wong
  0 siblings, 2 replies; 39+ messages in thread
From: John Whitney @ 2012-10-04  4:35 UTC (permalink / raw)
  To: git

[-- Attachment #1: Type: text/plain, Size: 171 bytes --]

Hi all!

I just ran into a problem that I'm pretty sure is a bug in git. Just 
read and run this (fairly trivial) shell script to replicate.

Thanks!
    ---John Whitney


[-- Attachment #2: git_failure.sh --]
[-- Type: application/x-sh, Size: 1186 bytes --]

^ permalink raw reply	[flat|nested] 39+ messages in thread

end of thread, back to index

Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CA+2sEepTyrK-iH+VBHVF1i9DuYVzDkTNxuM0-yoWbkC9N4f8HA@mail.gmail.com>
2019-04-15 15:18 ` bug report Nick Steinhauser
2017-08-30 21:25 Bug report Aleksandar Pavic
2017-08-31  6:36 ` Kevin Daudt
2017-08-31 14:19   ` Dov Grobgeld
2017-08-31 14:55     ` Aleksandar Pavic
2017-08-31 16:23   ` Stephan Beyer
2017-09-02  8:49 ` Jeff King
  -- strict thread matches above, loose matches on Subject: below --
2016-05-13  5:04 bug report 李本超
2016-05-13  5:23 ` Pranit Bauva
2016-05-13  5:58   ` 李本超
2016-05-13  6:37     ` Pranit Bauva
2016-05-13  6:57       ` 李本超
2016-05-13  7:10         ` Pranit Bauva
2016-05-13  7:41           ` 李本超
2016-05-13  8:10             ` Jeff King
2016-05-13 12:05               ` 李本超
2016-04-03  0:25 Bug Report Benjamin Sandeen
2016-04-03  2:20 ` Eric N. Vander Weele
2016-04-03  2:22 ` Jacob Keller
2015-01-27 14:43 bug report Albert Akhriev
2015-01-27 14:50 ` Jeff King
     [not found] <CAC34_pT9zwZDnUjo1bTUZabD02M48=_+77-mNCA5adWTgxuYgg@mail.gmail.com>
2013-04-08  5:20 ` Bug Report Kirk Fraser
2012-10-05 10:13 Bug report Муковников Михаил
2012-10-05 10:32 ` Konstantin Khomoutov
2012-10-05 10:47   ` cmn
2012-10-05 11:03     ` Муковников Михаил
2012-10-05 10:52   ` Муковников Михаил
2012-10-04  4:35 John Whitney
2012-10-04 14:19 ` Phil Hord
2012-10-04 16:10   ` John Whitney
2012-10-06 13:31     ` Jeff King
2012-10-07  2:23       ` John Whitney
2012-10-07 23:52         ` Jeff King
2012-10-09 17:17           ` John Whitney
2012-10-09 19:00             ` John Whitney
2012-10-04 15:21 ` Andrew Wong
2012-10-04 16:16   ` John Whitney
2012-10-04 16:28     ` John Whitney
2012-10-04 17:01     ` Andrew Wong

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox