Re: Bug Report: git status triggers a file change event

2018-02-23 Thread Johannes Schindelin 
Hi all,

On Thu, 22 Feb 2018, Stefan Beller wrote:

> On Wed, Feb 21, 2018 at 9:22 PM, Jonathan Nieder  wrote:
> > +git-for-windows

First of all, this is clearly not a Windows-specific problem, as the index
file *is* updated, and that is simply the same behavior as on Linux/macOS.

> > Raining Chain wrote:
> >
> >> On Windows 10, git version 2.16.2.windows.1, running the command
> >>
> >> git status
> >>
> >> will trigger a file change event to file C:\myPath\.git  "Attributes
> >> changed."

Correct, because .git\index changed.

> >> This causes problems when using scripts that detect file changes such
> >> as tsc -w (Typescript compiler) and using softwares that regularly
> >> call git status such as VisualStudioCode.

Visual Studio Code most likely does not look at .git for worktree changes.

As to the Typescript compiler: it should only look for .ts files, I would
be very surprised if it was confused by .git's filesystem attributes
changing!

If tsw is still confused, try adding

"exclude": [
".git"
]

to your tsconfig.json.

Ciao,
Johannes

Re: Bug Report: git status triggers a file change event

2018-02-22 Thread Stefan Beller 
On Wed, Feb 21, 2018 at 9:22 PM, Jonathan Nieder  wrote:
> +git-for-windows
> Hi,
>
> Raining Chain wrote:
>
>> On Windows 10, git version 2.16.2.windows.1, running the command
>>
>> git status
>>
>> will trigger a file change event to file C:\myPath\.git  "Attributes 
>> changed."
>>
>> This causes problems when using scripts that detect file changes such
>> as tsc -w (Typescript compiler) and using softwares that regularly
>> call git status such as VisualStudioCode.
>>
>> Thanks.

Does
https://github.com/git/git/commit/27344d6a6c8056664966e11acf674e5da6dd7ee3
help?

>
> Can you say more about how "tsc -w" reacts to the file change?  Is there
> a way to tell it to exclude particular files from the files it watches?
>
> Thanks,
> Jonathan

Re: Bug Report: git status triggers a file change event

2018-02-21 Thread Jonathan Nieder 
+git-for-windows
Hi,

Raining Chain wrote:

> On Windows 10, git version 2.16.2.windows.1, running the command
>
> git status
>
> will trigger a file change event to file C:\myPath\.git  "Attributes changed."
>
> This causes problems when using scripts that detect file changes such
> as tsc -w (Typescript compiler) and using softwares that regularly
> call git status such as VisualStudioCode.
>
> Thanks.

Can you say more about how "tsc -w" reacts to the file change?  Is there
a way to tell it to exclude particular files from the files it watches?

Thanks,
Jonathan

Bug Report: git status triggers a file change event

2018-02-21 Thread Raining Chain 
On Windows 10, git version 2.16.2.windows.1, running the command

git status

will trigger a file change event to file C:\myPath\.git  "Attributes changed."

This causes problems when using scripts that detect file changes such
as tsc -w (Typescript compiler) and using softwares that regularly
call git status such as VisualStudioCode.

Thanks.

Re: Bug#757297: 'git status' output is confusing after 'git add -N'

2014-08-07 Thread Junio C Hamano 
Duy Nguyen pclo...@gmail.com writes:

 On Thu, Aug 7, 2014 at 7:34 AM, Jonathan Nieder jrnie...@gmail.com wrote:
 Package: git
 Version: 1:2.0.0-1
 Tags: upstream

   $ git init foo
   Initialized empty Git repository in /tmp/t/foo/.git/
   $ cd foo
   $ echo hi README
   $ git add -N README
   $ git status
   On branch master

   Initial commit

   Changes to be committed:
 (use git rm --cached file... to unstage)

   new file:   README

   Changes not staged for commit:
 (use git add file... to update what will be committed)
 (use git checkout -- file... to discard changes in working directory)

   modified:   README

 If I then run git commit, it does not actually commit the addition
 of the README file.

 We used to reject such a commit operation before 3f6d56d (commit:
 ignore intent-to-add entries instead of refusing - 2012-02-07) so it
 was harder to misunderstand this case.

 It would be clearer to have a separate section,like so:

   Tracked files not to be committed:
 (use git rm --cached file... to stop tracking)

new file:   README


 Or make the Changes not staged for commit part say new file:
 README (modified is implied)

Yeah, after reading the justification in the quoted commit, I agree
that it is status that is at fault in the above; new file: README
is part of Changes not staged for commit in this case (it is told
to the index, but the user never said it is for commit yet, which
is the whole point of -N), so instead of adding a new section, I
agree that it should be classified as new file not modified
there.



--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug#757297: 'git status' output is confusing after 'git add -N'

2014-08-06 Thread Duy Nguyen 
On Thu, Aug 7, 2014 at 7:34 AM, Jonathan Nieder jrnie...@gmail.com wrote:
 Package: git
 Version: 1:2.0.0-1
 Tags: upstream

   $ git init foo
   Initialized empty Git repository in /tmp/t/foo/.git/
   $ cd foo
   $ echo hi README
   $ git add -N README
   $ git status
   On branch master

   Initial commit

   Changes to be committed:
 (use git rm --cached file... to unstage)

   new file:   README

   Changes not staged for commit:
 (use git add file... to update what will be committed)
 (use git checkout -- file... to discard changes in working directory)

   modified:   README

 If I then run git commit, it does not actually commit the addition
 of the README file.

We used to reject such a commit operation before 3f6d56d (commit:
ignore intent-to-add entries instead of refusing - 2012-02-07) so it
was harder to misunderstand this case.

 It would be clearer to have a separate section,like so:

   Tracked files not to be committed:
 (use git rm --cached file... to stop tracking)

new file:   README


Or make the Changes not staged for commit part say new file:
README (modified is implied)
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Aw: Re: Re: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'

2014-01-14 Thread Keshav Kini 
The following message is a courtesy copy of an article
that has been posted to gmane.comp.version-control.git as well.

Junio C Hamano gits...@pobox.com writes:
 Thomas Ackermann th.ac...@arcor.de writes:
  But for the simple use case where you only have a master
  branch I consider it not really helpful and - at least for me -
  misleading.
 
 I see what you mean, and you're not the only one.
 
 Git follows a rule of never contact another machine unless explicitly
 asked to using a command such as 'git pull' or 'git fetch'.  To
 support this, it makes a distinction between (1) the remote-tracking
 ref origin/master and (2) the actual branch master in the remote
 repository.  The former is what is updated by 'git fetch', and the
 latter is something git does not know about without talking to the
 remote server.
 
 What documentation did you use when first starting to learn git?
 Perhaps it can be fixed to emphasize the distinction between (1) and
 (2) earlier.

 I think it's not the problem of the documentation but of myself
 not having it read thorough enough ;-)

 (This new feature in V1.8.5 of course is not documented in any of the books
 up to now but in the future could be used to explain the above mentioned
 rule.)

 By the way, this is nothing new in 1.8.5; we didn't bother saying
 up-to-date before, so you may not have noticed, but its silence was
 already telling you that your branch was up-to-date with respect to
 what you are building on top of.

Maybe it would be worthwhile to add a message like (last fetched from
upstream branch at [date]), taken from
$GIT_DIR/logs/refs/remotes/foo/bar ?  This would mitigate the confusion
Thomas suffered, I think.

Caveat: pretty ill-defined, since 1) if you've been pushing and not
fetching, the most recent time at which it is known that your
remote-tracking branch was up to date could be much newer than when it
was technically last fetched; 2) the upstream branch might not
even be a remote-tracking branch; 3) probably something else I haven't
thought of.

-Keshav
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Aw: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'

2014-01-06 Thread Thomas Ackermann 
 
Hi Jiang,

this happens with all of my repo clones (I am using V1.8.5.2
on Windows and on Linux). Steps to reproduce:

mkdir repo_a  cd repo_a  git init .
echo 1foo  git add foo  git commit -m 1
cd ..
git clone repo_a repo_b
cd repo_a
echo 2foo  git add foo  git commit -m 2
cd ../repo_b
git status
git checkout -b branch
git checkout master

'git status' and 'git checkout master' in repo_b are now 
reporting Your branch is up-to-date with 'origin/master'
which is obviously wrong.

---
Thomas

- Original Nachricht 
Von: Jiang Xin worldhello@gmail.com
An:  Thomas Ackermann th.ac...@arcor.de
Datum:   06.01.2014 06:31
Betreff: Re: [Bug report] 'git status' always says Your branch is up-to-date
 with 'origin/master'

 2014/1/5 Thomas Ackermann th.ac...@arcor.de:
  Since f223459 status: always show tracking branch even no change
  'git status' (and 'git checkout master' always says
  Your branch is up-to-date with 'origin/master'
  even if 'origin/master' is way ahead from local 'master'.
 
 Hi, Thomas
 
 Can you provide your operations so that I can reproduce this issue?
 
 In the commit you mentioned above, there was a new test case named
 'checkout (up-to-date with upstream)' added in 't6040'. I also add two
 test-cases locally in order to reproduce the issue you report, and run
 them in arbitrary orders, but they all look fine:
 
 ok 4 - checkout (behind upstream)
 ok 5 - checkout (ahead upstream)
 ok 6 - checkout (diverged from upstream)
 ok 7 - checkout with local tracked branch
 ok 8 - checkout (upstream is gone)
 ok 9 - checkout (up-to-date with upstream)
 ok 10 - checkout (upstream is gone)
 ok 11 - checkout with local tracked branch
 ok 12 - checkout (diverged from upstream)
 ok 13 - checkout (ahead upstream)
 ok 14 - checkout (behind upstream)
 ok 15 - checkout (diverged from upstream)
 ok 16 - checkout (upstream is gone)
 ok 17 - checkout (ahead upstream)
 ok 18 - checkout with local tracked branch
 ok 19 - checkout (behind upstream)
 
 
 The two additional test cases I used locally are:
 
 checkout_test1() {
 test_expect_success 'checkout (behind upstream)' '
 (
 cd test  git checkout b3
 ) actual 
 test_i18ngrep is behind .* by 1 commit, and can be
 fast-forwarded actual
 '
 }
 
 checkout_test_2() {
 test_expect_success 'checkout (ahead upstream)' '
 (
 cd test  git checkout b4
 ) actual 
 test_i18ngrep is ahead of .* by 2 commits actual
 '
 }
 
 -- 
 Jiang Xin
 

---
Thomas
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'

2014-01-06 Thread Bryan Turner 
On 6 January 2014 01:24, Thomas Ackermann th.ac...@arcor.de wrote:


 Hi Jiang,

 this happens with all of my repo clones (I am using V1.8.5.2
 on Windows and on Linux). Steps to reproduce:

 mkdir repo_a  cd repo_a  git init .
 echo 1foo  git add foo  git commit -m 1
 cd ..
 git clone repo_a repo_b
 cd repo_a
 echo 2foo  git add foo  git commit -m 2
 cd ../repo_b
 git status
 git checkout -b branch
 git checkout master

 'git status' and 'git checkout master' in repo_b are now
 reporting Your branch is up-to-date with 'origin/master'
 which is obviously wrong.


Unfortunately that's not true. In repo_b your ref for origin/master
has not moved. It has remotely (meaning refs/heads/master in repo_a
has moved), but git status is not hitting the remote to find out; it
only looks at the local state. To see what I mean, run git fetch in
repo_b. Once you do that, you'll see that git status correctly reports
you're behind.


 ---
 Thomas

 - Original Nachricht 
 Von: Jiang Xin worldhello@gmail.com
 An:  Thomas Ackermann th.ac...@arcor.de
 Datum:   06.01.2014 06:31
 Betreff: Re: [Bug report] 'git status' always says Your branch is up-to-date
  with 'origin/master'

  2014/1/5 Thomas Ackermann th.ac...@arcor.de:
   Since f223459 status: always show tracking branch even no change
   'git status' (and 'git checkout master' always says
   Your branch is up-to-date with 'origin/master'
   even if 'origin/master' is way ahead from local 'master'.
 
  Hi, Thomas
 
  Can you provide your operations so that I can reproduce this issue?
 
  In the commit you mentioned above, there was a new test case named
  'checkout (up-to-date with upstream)' added in 't6040'. I also add two
  test-cases locally in order to reproduce the issue you report, and run
  them in arbitrary orders, but they all look fine:
 
  ok 4 - checkout (behind upstream)
  ok 5 - checkout (ahead upstream)
  ok 6 - checkout (diverged from upstream)
  ok 7 - checkout with local tracked branch
  ok 8 - checkout (upstream is gone)
  ok 9 - checkout (up-to-date with upstream)
  ok 10 - checkout (upstream is gone)
  ok 11 - checkout with local tracked branch
  ok 12 - checkout (diverged from upstream)
  ok 13 - checkout (ahead upstream)
  ok 14 - checkout (behind upstream)
  ok 15 - checkout (diverged from upstream)
  ok 16 - checkout (upstream is gone)
  ok 17 - checkout (ahead upstream)
  ok 18 - checkout with local tracked branch
  ok 19 - checkout (behind upstream)
 
 
  The two additional test cases I used locally are:
 
  checkout_test1() {
  test_expect_success 'checkout (behind upstream)' '
  (
  cd test  git checkout b3
  ) actual 
  test_i18ngrep is behind .* by 1 commit, and can be
  fast-forwarded actual
  '
  }
 
  checkout_test_2() {
  test_expect_success 'checkout (ahead upstream)' '
  (
  cd test  git checkout b4
  ) actual 
  test_i18ngrep is ahead of .* by 2 commits actual
  '
  }
 
  --
  Jiang Xin
 

 ---
 Thomas
 --
 To unsubscribe from this list: send the line unsubscribe git in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'

2014-01-06 Thread Jiang Xin 
2014/1/6 Thomas Ackermann th.ac...@arcor.de:

 Hi Jiang,

 this happens with all of my repo clones (I am using V1.8.5.2
 on Windows and on Linux). Steps to reproduce:

 mkdir repo_a  cd repo_a  git init .
 echo 1foo  git add foo  git commit -m 1
 cd ..
 git clone repo_a repo_b
 cd repo_a
 echo 2foo  git add foo  git commit -m 2
 cd ../repo_b
 git status
 git checkout -b branch

Oops. Do

git fetch

then

git checkout master

You will get what you want.

 git checkout master

 'git status' and 'git checkout master' in repo_b are now
 reporting Your branch is up-to-date with 'origin/master'
 which is obviously wrong.


--
Jiang Xin
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Aw: Re: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'

2014-01-06 Thread Thomas Ackermann 
 
 
 Unfortunately that's not true. In repo_b your ref for origin/master
 has not moved. It has remotely (meaning refs/heads/master in repo_a
 has moved), but git status is not hitting the remote to find out; it
 only looks at the local state. To see what I mean, run git fetch in
 repo_b. Once you do that, you'll see that git status correctly reports
 you're behind.
 

OK; my expectation was, that the remote is checked for this ...
I see that this feature is useful for all non-trivial use cases
where you have several branches beside master for which the
remotes will be updated by git fetch.
But for the simple use case where you only have a master
branch I consider it not really helpful and - at least for me -
misleading.

---
Thomas
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'

2014-01-06 Thread Jonathan Nieder 
Hi,

Thomas Ackermann wrote:

In repo_b your ref for origin/master
 has not moved. It has remotely (meaning refs/heads/master in repo_a
 has moved), but git status is not hitting the remote to find out; it
 only looks at the local state.
[...]
 But for the simple use case where you only have a master
 branch I consider it not really helpful and - at least for me -
 misleading.

I see what you mean, and you're not the only one.

Git follows a rule of never contact another machine unless explicitly
asked to using a command such as 'git pull' or 'git fetch'.  To
support this, it makes a distinction between (1) the remote-tracking
ref origin/master and (2) the actual branch master in the remote
repository.  The former is what is updated by 'git fetch', and the
latter is something git does not know about without talking to the
remote server.

What documentation did you use when first starting to learn git?
Perhaps it can be fixed to emphasize the distinction between (1) and
(2) earlier.

Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Aw: Re: Re: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'

2014-01-06 Thread Thomas Ackermann 
 
  But for the simple use case where you only have a master
  branch I consider it not really helpful and - at least for me -
  misleading.
 
 I see what you mean, and you're not the only one.
 
 Git follows a rule of never contact another machine unless explicitly
 asked to using a command such as 'git pull' or 'git fetch'.  To
 support this, it makes a distinction between (1) the remote-tracking
 ref origin/master and (2) the actual branch master in the remote
 repository.  The former is what is updated by 'git fetch', and the
 latter is something git does not know about without talking to the
 remote server.
 
 What documentation did you use when first starting to learn git?
 Perhaps it can be fixed to emphasize the distinction between (1) and
 (2) earlier.

I think it's not the problem of the documentation but of myself
not having it read thorough enough ;-)

(This new feature in V1.8.5 of course is not documented in any of the books
up to now but in the future could be used to explain the above mentioned
rule.)

Thanks to you, Bryan and Jiang for your help!

---
Thomas
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'

2014-01-05 Thread Jiang Xin 
2014/1/5 Thomas Ackermann th.ac...@arcor.de:
 Since f223459 status: always show tracking branch even no change
 'git status' (and 'git checkout master' always says
 Your branch is up-to-date with 'origin/master'
 even if 'origin/master' is way ahead from local 'master'.

Hi, Thomas

Can you provide your operations so that I can reproduce this issue?

In the commit you mentioned above, there was a new test case named
'checkout (up-to-date with upstream)' added in 't6040'. I also add two
test-cases locally in order to reproduce the issue you report, and run
them in arbitrary orders, but they all look fine:

ok 4 - checkout (behind upstream)
ok 5 - checkout (ahead upstream)
ok 6 - checkout (diverged from upstream)
ok 7 - checkout with local tracked branch
ok 8 - checkout (upstream is gone)
ok 9 - checkout (up-to-date with upstream)
ok 10 - checkout (upstream is gone)
ok 11 - checkout with local tracked branch
ok 12 - checkout (diverged from upstream)
ok 13 - checkout (ahead upstream)
ok 14 - checkout (behind upstream)
ok 15 - checkout (diverged from upstream)
ok 16 - checkout (upstream is gone)
ok 17 - checkout (ahead upstream)
ok 18 - checkout with local tracked branch
ok 19 - checkout (behind upstream)


The two additional test cases I used locally are:

checkout_test1() {
test_expect_success 'checkout (behind upstream)' '
(
cd test  git checkout b3
) actual 
test_i18ngrep is behind .* by 1 commit, and can be
fast-forwarded actual
'
}

checkout_test_2() {
test_expect_success 'checkout (ahead upstream)' '
(
cd test  git checkout b4
) actual 
test_i18ngrep is ahead of .* by 2 commits actual
'
}

-- 
Jiang Xin
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bug in git status

2012-12-25 Thread Michael Haggerty 
I think I have found a bug in git status --untracked-files=all
--ignored, in both 1.8.0 and in master:

$ git init status-test
Initialized empty Git repository in
/home/mhagger/self/proj/git/status-test/.git/
$ cd status-test
$ touch x
$ touch x.ignore-me
$ mkdir y
$ touch y/foo
$ touch y/foo.ignore-me
$ git status --porcelain --untracked-files=all --ignored
?? x
?? x.ignore-me
?? y/foo
?? y/foo.ignore-me

The above output is what I expect.  But if I add a .gitignore file, the
output of y/foo.ignore-me is incorrectly suppressed:

$ echo '*.ignore-me' .gitignore
$ git status --porcelain --untracked-files=all --ignored
?? .gitignore
?? x
?? y/foo
!! x.ignore-me

I came across this problem when trying to use the results of the above
command to build a more flexible git clean type of script.

I don't have time to look into this at the moment, if somebody wants to
jump in.

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

bug report: git status --porcelain inconsistent quoting

2012-07-07 Thread Leonid Volnitsky 
mkdir D
cd D
git init
Initialized empty Git repository in /tmp/D/.git/
echo 1  with space
git status --porcelain
?? with space    NO QOUTES
git add with\ space
git status --porcelain
A  with space - WITH QOUTES

git --version
git version 1.7.9.7

git config -l |grep quote
core.quotepath=on
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html