How to play around with the filename with colon on Windows?

[Yue Lin Ho]

Hi:

Assume I got one repository which comes from a Linux user, 

and there is one file which have a colon in its filename,

and clone that repository on Windows...

(Actually, I got real one for testing. 

see: https://github.com/t-pascal/tortoisegit-colons)

Because the filename with colon is not allowed in Windows, 

the file is not created/checkout.

Then git will treat it as a deleted file. See:

  User@PC /d/Repo/tortoisegit-colons (master)

  $ git status

  On branch master

  Your branch is up-to-date with 'origin/master'.

  Changes to be committed:

    (use "git reset HEAD <file>..." to unstage)

          deleted:    ifcfg-eth0:0

The first thing I want to try is rename:

  $ git mv ifcfg-eth0:0 ifcfg-eth0_0

  fatal: bad source, source=ifcfg-eth0:0, destination=ifcfg-eth0_0

The next is rename in vagrant:

so I copy the repository to C:\msysgit, and run msys.bat, and...

  $ vagrant up

  $ vagrant ssh

  $ sudo apt-get install python-software-properties

  $ sudo add-apt-repository ppa:git-core/ppa

  $ sudo apt-get update

  $ sudo apt-get install git

  $ git version

  git version 2.3.3

  $ cd ..

  $ cd tortoisegit-colons

  $ git mv ifcfg-eth0:0 ifcfg-eth0_0

  fatal: bad source, source=ifcfg-eth0:0, destination=ifcfg-eth0_0

Consider that the Linux users needs that file, rename is not a good idea.

So, try assume-unchanged

  User@PC /d/Repo/tortoisegit-colons (master)

  $ git update-index --assume-unchanged ifcfg-eth0:0

  Ignoring path ifcfg-eth0:0

Looks good, but...

  User@PC /d/Repo/tortoisegit-colons (master)

  $ git status

  On branch master

  Your branch is up-to-date with 'origin/master'.

  Changes to be committed:

    (use "git reset HEAD <file>..." to unstage)

          deleted:    ifcfg-eth0:0

  User@PC /d/Repo/tortoisegit-colons (master)

  $ git commit -m "check if it is deleted"

  [master f86475e] check if it is deleted

   1 file changed, 6 deletions(-)

   delete mode 100644 ifcfg-eth0:0

And in vagrant:

  vagrant@precise64:/vagrant/tortoisegit-colons$ git update-index --assume-unchanged ifcfg-eth0:0

  fatal: Unable to mark file ifcfg-eth0:0

(BTW, looks like they are different behavior.)

Assume the Windows users never modify that file and the Linux user needs that file.

What am I supposed do on that file?

what if there are many filenames with colon?

No chance on Windows?

Thank you. :)

Yue Lin Ho

[Yue Lin Ho]

Yue Lin Ho於 2015年3月17日星期二 UTC+8下午12時01分56秒寫道：

Further trying - start the re-test from the step of clone:

Test 1:

Using Git Bash Here in folder C:\msysgit\git

Clone

  User@PC /c/msysgit/git (msvc-build-fix)

  $ git version

  git version 1.9.5.msysgit.0

  User@PC /c/msysgit/git (msvc-build-fix)

  $ git clone https://github.com/t-pascal/tortoisegit-colons.git clone_via_bash

  Cloning into 'clone_via_bash'...

  remote: Counting objects: 11, done.

  remote: Compressing objects: 100% (7/7), done.

  remote: Total 11 (delta 2), reused 11 (delta 2), pack-reused 0

  Unpacking objects: 100% (11/11), done.

  Checking connectivity... done.

  error: Invalid path 'ifcfg-eth0:0'

  User@PC /c/msysgit/git (msvc-build-fix)

  $ cd clone_via_bash

  User@PC /c/msysgit/git/clone_via_bash (master)

  $ git status

  On branch master

  Your branch is up-to-date with 'origin/master'.

  Changes to be committed:

    (use "git reset HEAD <file>..." to unstage)

          deleted:    ifcfg-eth0:0

Reset

  User@PC /c/msysgit/git/clone_via_bash (master)

  $ git reset HEAD ifcfg-eth0:0

  error: Invalid path 'ifcfg-eth0:0'

  fatal: make_cache_entry failed for path 'ifcfg-eth0:0'

Assume unchanged

  User@PC /c/msysgit/git/clone_via_bash (master)

  $ git update-index --assume-unchanged ifcfg-eth0:0

  Ignoring path ifcfg-eth0:0

  User@PC /c/msysgit/git/clone_via_bash (master)

  $ git status

  On branch master

  Your branch is up-to-date with 'origin/master'.

  Changes to be committed:

    (use "git reset HEAD <file>..." to unstage)

          deleted:    ifcfg-eth0:0

Test 2:

run msys.bat

  User@PC / (master)

  $ git version

  git version 1.9.5

run vagrant

  User@PC / (master)

  $ vagrant up

  [snip]

  User@PC / (master)

  $ vagrant ssh

  [snip]

Clone

  vagrant@precise64:/vagrant/git$ git clone https://github.com/t-pascal/tortoisegit-colons.git clone_via_vagrant

  Cloning into 'clone_via_vagrant'...

  remote: Counting objects: 11, done.

  remote: Compressing objects: 100% (7/7), done.

  remote: Total 11 (delta 2), reused 11 (delta 2), pack-reused 0

  Unpacking objects: 100% (11/11), done.

  Checking connectivity... done.

  vagrant@precise64:/vagrant/git$ cd clone_via_vagrant

  vagrant@precise64:/vagrant/git/clone_via_vagrant$ git version

  git version 2.3.3

Status

  vagrant@precise64:/vagrant/git/clone_via_vagrant$ git status

  # On branch master

  # Your branch is up-to-date with 'origin/master'.

  #

  # Untracked files:

  #   (use "git add <file>..." to include in what will be committed)

  #

  #       ifcfg-eth0

  #

  nothing added to commit but untracked files present (use "git add" to track)

Yue Lin Ho

[Yue Lin Ho]

Yue Lin Ho於 2015年3月17日星期二 UTC+8下午2時12分57秒寫道：

Continue this test:

List files

  User@PC /c/msysgit/git/clone_via_bash (master)

  $ git ls-files

  README.md

  ifcfg-eth0-0

Change dir to clone_via_grant

  User@PC /c/msysgit/git/clone_via_bash (master)

  $ cd ..

  User@PC /c/msysgit/git (msvc-build-fix)

  $ cd clone_via_vagrant

Status

  User@PC /c/msysgit/git/clone_via_vagrant (master)

  $ git status

  On branch master

  Your branch is up-to-date with 'origin/master'.

  Untracked files:

    (use "git add <file>..." to include in what will be committed)

          ifcfg-eth0

  nothing added to commit but untracked files present (use "git add" to track)

List Files

  User@PC /c/msysgit/git/clone_via_vagrant (master)

  $ git ls-files

  README.md

  ifcfg-eth0-0

  ifcfg-eth0:0

Yue Lin Ho

[Yue Lin Ho]

Yue Lin Ho於 2015年3月17日星期二 UTC+8下午2時28分15秒寫道：

Change dir to clone_via_grant

                         ^^^^^^

Oops! a typo, should be vagrant

[Yue Lin Ho]

Hi:

Finally, I got a workaround.

First, thanks for building of vagrant.

Now, the workaround:

1. install msysgit in C:\msysgit

https://github.com/msysgit/msysgit/releases/download/Git-1.9.5-preview20141217/msysGit-netinstall-1.9.5-preview20141217.exe

(I set the environment LANG=C, because of Chinese version of Win7)

2. run C:\msysgit\msys.bat

3. run vagrant

  $ vagrant up

  $ vagrant ssh

  From now on, the prompt should be "vagrant@precise64:/vagrant/git$"

4. install git

  $ sudo apt-get install python-software-properties

  $ sudo add-apt-repository ppa:git-core/ppa

  $ sudo apt-get update

  $ sudo apt-get install git

  $ git version

  git version 2.3.3

5. clone the repository

  vagrant@precise64:/vagrant/git$ git clone https://github.com/t-pascal/tortoisegit-colons.git clone_via_vagrant

6. change dir to that repository

  vagrant@precise64:/vagrant/git$ cd clone_via_vagrant

7. Do "assume unchanged" on that file

  vagrant@precise64:/vagrant/git/clone_via_vagrant$ git ls-files

  README.md

  ifcfg-eth0-0

  ifcfg-eth0:0

  vagrant@precise64:/vagrant/git/clone_via_vagrant$ git update-index --assume-unchanged ifcfg-eth0:0

8. remove the useless file "ifcfg-eth0"

  vagrant@precise64:/vagrant/git/clone_via_vagrant$ git status

  # On branch master

  # Your branch is up-to-date with 'origin/master'.

  #

  # Untracked files:

  #   (use "git add <file>..." to include in what will be committed)

  #

  #       ifcfg-eth0

  #

  nothing added to commit but untracked files present (use "git add" to track)

  vagrant@precise64:/vagrant/git/clone_via_vagrant$ rm ifcfg-eth0

  vagrant@precise64:/vagrant/git/clone_via_vagrant$ git status

  # On branch master

  # Your branch is up-to-date with 'origin/master'.

  #

  nothing to commit, working directory clean

9. exit vagrant

10. Start to modify other files and commit them.

  User@PC /c/msysgit/git/clone_via_vagrant (master)

  $ git status

  On branch master

  Your branch is up-to-date with 'origin/master'.

  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.md

  no changes added to commit (use "git add" and/or "git commit -a")

  User@PC /c/msysgit/git/clone_via_vagrant (master)

  $ git add README.md

  User@PC /c/msysgit/git/clone_via_vagrant (master)

  $ git status

  On branch master

  Your branch is up-to-date with 'origin/master'.

  Changes to be committed:

    (use "git reset HEAD <file>..." to unstage)

          modified:   README.md

  User@PC /c/msysgit/git/clone_via_vagrant (master)

  $ git commit -m "modified README.md"

  [master 929a989] modified README.md

   1 file changed, 1 insertion(+)

Note:

Once using "git reset --hard" in Git Bash, the issue comes back.

Then do the workaround again.

Yue Lin Ho

[Johannes Schindelin]

Hi,

On 2015-03-17 05:01, Yue Lin Ho wrote:

> Assume I got one repository which comes from a Linux user,
> and there is one file which have a colon in its filename,
> and clone that repository on Windows...
> (Actually, I got real one for testing.
> see: https://github.com/t-pascal/tortoisegit-colons)
>
> Because the filename with colon is not allowed in Windows,
> the file is not created/checkout.

The trick is to use the content from the index first:

git show HEAD:ifcfg-eth0:0 > ifcfg-eth0_0
git add .

If `git mv` had a `--cached` flag, that would work, too. Hint: this
would make for an interesting project for somebody who wants to dabble
with Git's source code.

> The next is rename in vagrant:

If you want to fix this using Vagrant, you will have to re-clone into
the home directory because the original clone is still using the
filesystem that cannot handle colons in the filenames.

> So, try *assume-unchanged*

Well, assume-unchanged is intended for a different use case, where you
can write the file at least once, and then tell Git everytime it
changed...

Ciao,
Johannes

[t_pa...@zennet.com]

Hello, I am the original reporter. I was initially confused about the difference between msysgit and tortoisegit. I have created a test repo on github for verification: https://github.com/t-pascal/tortoisegit-colons and also the original discussion thread with Yue Lin Ho on tortoisegit-users here: https://groups.google.com/forum/#!topic/tortoisegit-users/w9t79l_HFRw

Any questions or concerns or clarification, feel free to ask.

I am most interested in finding a graceful way to handle colons on Windows -- perhaps even just with some messaging or warning at the clone step.

Thanks,

-T

[Philip Oakley]

From: Yue Lin Ho

Try using "Sparse Checkout". It's hidden in the manuals, and you create an "ignore" file that states which files shouln not be checked out into the working tree (so Windows File System doesn't/shouldn't see them). The Index (staging area) knows that they are part of that directory tree, so status and other commands don't get confused, and you should be able to carry on OK.

 

I've not used it my self, but have plans regarding a wider 'Narrow/Sparse' repo functionality for [Enterprise] cases where you don't want Random.J.Coder to actually have a fully copy of your repo, and only have available those specific directories allocated to them, yet still have a fully functional Push/Fetch/Pull capability similar to the Shallow clones.

 

Philip

 

 

[Yue Lin Ho]

Yue Lin Ho於 2015年3月17日星期二 UTC+8下午2時12分57秒寫道：

Yue Lin Ho於 2015年3月17日星期二 UTC+8下午12時01分56秒寫道：

Hi:

Assume I got one repository which comes from a Linux user, 

and there is one file which have a colon in its filename,

and clone that repository on Windows...

(Actually, I got real one for testing. 

see: https://github.com/t-pascal/tortoisegit-colons)

Because the filename with colon is not allowed in Windows, 

the file is not created/checkout.

Then git will treat it as a deleted file. See:

  User@PC /d/Repo/tortoisegit-colons (master)

  $ git status

  On branch master

  Your branch is up-to-date with 'origin/master'.

  Changes to be committed:

    (use "git reset HEAD <file>..." to unstage)

          deleted:    ifcfg-eth0:0

In my opinion, the problem is that file is staged after clone(including checkout).

If a file can not be checkout, its status should be just deleted from working tree, instead of staged.

Yue Lin Ho

 

[Yue Lin Ho]

Philip Oakley於 2015年3月18日星期三 UTC+8上午1時27分34秒寫道：

Assume the Windows users never modify that file and the Linux user needs that file.

What am I supposed do on that file?

Try using "Sparse Checkout". It's hidden in the manuals, and you create an "ignore" file that states which files shouln not be checked out into the working tree (so Windows File System doesn't/shouldn't see them). The Index (staging area) knows that they are part of that directory tree, so status and other commands don't get confused, and you should be able to carry on OK.

 

I've not used it my self, but have plans regarding a wider 'Narrow/Sparse' repo functionality for [Enterprise] cases where you don't want Random.J.Coder to actually have a fully copy of your repo, and only have available those specific directories allocated to them, yet still have a fully functional Push/Fetch/Pull capability similar to the Shallow clones.

I did this test:

  User@PC /d/Temp/tortoisegit-colons (master)

  $ git config core.sparseCheckout true

  User@PC /d/Temp/tortoisegit-colons (master)

  $ echo README.md > .git/info/sparse-checkout

  Dev@DEV-PC /d/Temp/tortoisegit-colons (master)

  $ git read-tree --reset -u  HEAD

  error: Invalid path 'ifcfg-eth0:0'

Not sure I am doing the right thing about sparse checkout. :P

Yue Lin Ho

 

[Johannes Schindelin]

On 2015-03-17 23:55, Yue Lin Ho wrote:
> Yue Lin Ho於 2015年3月17日星期二 UTC+8下午2時12分57秒寫道：
>>>

>>> Changes to be committed:
>>> (use "git reset HEAD <file>..." to unstage)
>>>
>>> deleted: ifcfg-eth0:0
>>>
>>
> In my opinion, the problem is that file is staged after clone(including
> checkout).
> If a file can not be checkout, its status should be just deleted from
> working tree, instead of staged.

That is exactly its status: "deleted".

Maybe I am misunderstanding?

[Johannes Schindelin]

On 2015-03-18 00:13, Yue Lin Ho wrote:
> Philip Oakley於 2015年3月18日星期三 UTC+8上午1時27分34秒寫道：

>
>> Try using "Sparse Checkout".
>

> I did this test:
>
> User@PC /d/Temp/tortoisegit-colons (master)
> $ git config core.sparseCheckout true
>
> User@PC /d/Temp/tortoisegit-colons (master)
> $ echo README.md > .git/info/sparse-checkout
>
> Dev@DEV-PC /d/Temp/tortoisegit-colons (master)
> $ git read-tree --reset -u HEAD
> error: Invalid path 'ifcfg-eth0:0'
>
>
> Not sure I am doing the right thing about sparse checkout. :P

You cannot use the sparse checkout feature to fix the problem when it
already occurred. In other words, if the file has already been "checked
out", i.e. if is part of the staging area and Git tried to write it out,
then it is already too late.

Unfortunately, the sparseCheckout feature only works in conjunction with
a `sparse-checkout` file, otherwise the list of files not to be checked
out is assumed to be empty.

This here procedure works here:

```bash
$ git clone -n https://github.com/t-pascal/tortoisegit-colons
...
$ cd tortoisegit-colons
$ git config -c core.sparseCheckout true
$ echo README.md > .git/info/sparse-checkout
$ git checkout master
```

[Yue Lin Ho]

Johannes Schindelin於 2015年3月18日星期三 UTC+8下午2時54分18秒寫道：

Try this:

  User@PC /d/Repo

  $ git clone https://github.com/t-pascal/tortoisegit-colons.git test-repo

  Cloning into 'test-repo'...

  remote: Counting objects: 17, done.

  remote: Compressing objects: 100% (12/12), done.

  remote: Total 17 (delta 4), reused 16 (delta 3), pack-reused 0

  Unpacking objects: 100% (17/17), done.

  Checking connectivity... done.

  error: Invalid path 'ifcfg-eth0:0'

  User@PC /d/Repo

  $ cd test-repo

  User@PC /d/Repo/test-repo (master)

  $ git status

  On branch master

  Your branch is up-to-date with 'origin/master'.

  Changes to be committed:

    (use "git reset HEAD <file>..." to unstage)

          deleted:    ifcfg-eth0:0

the file "ifcfg-eth0:0" is "deleted" from working tree and staged to index.

  User@PC /d/Repo/test-repo (master)

  $ rm README.md

  User@PC /d/Repo/test-repo (master)

  $ git status

  On branch master

  Your branch is up-to-date with 'origin/master'.

  Changes to be committed:

    (use "git reset HEAD <file>..." to unstage)

          deleted:    ifcfg-eth0:0

  Changes not staged for commit:

    (use "git add/rm <file>..." to update what will be committed)

    (use "git checkout -- <file>..." to discard changes in working directory)

          deleted:    README.md

if a file, ex: README.md, is removed from working tree, it is deleted, but not staged.

I wish the file "ifcfg-eth0:0" is also unsaged after clone.

So, I can commit other changes without commit that deleted file.

(BTW, there is no way to unsaged it.)

Yue Lin Ho

[Yue Lin Ho]

Johannes Schindelin於 2015年3月18日星期三 UTC+8下午3時08分58秒寫道：

On 2015-03-18 00:13, Yue Lin Ho wrote:
> Philip Oakley於 2015年3月18日星期三 UTC+8上午1時27分34秒寫道：
>
>> Try using "Sparse Checkout".
>
> I did this test:
>
>   User@PC /d/Temp/tortoisegit-colons (master)
>   $ git config core.sparseCheckout true
>
>   User@PC /d/Temp/tortoisegit-colons (master)
>   $ echo README.md > .git/info/sparse-checkout
>
>   Dev@DEV-PC /d/Temp/tortoisegit-colons (master)
>   $ git read-tree --reset -u  HEAD
>   error: Invalid path 'ifcfg-eth0:0'
>
>
> Not sure I am doing the right thing about sparse checkout. :P

You cannot use the sparse checkout feature to fix the problem when it
already occurred. In other words, if the file has already been "checked
out", i.e. if is part of the staging area and Git tried to write it out,
then it is already too late.

Agree. I think so. :)

 

Unfortunately, the sparseCheckout feature only works in conjunction with
a `sparse-checkout` file, otherwise the list of files not to be checked
out is assumed to be empty.

This here procedure works here:

```bash
$ git clone -n https://github.com/t-pascal/tortoisegit-colons
...
$ cd tortoisegit-colons
$ git config -c core.sparseCheckout true
$ echo README.md > .git/info/sparse-checkout
$ git checkout master
```

tried it both in bash and vagrant, the same behavior

all file is deleted and staged.

And I tried this:

vagrant@precise64:/vagrant/git$ git clone https://github.com/t-pascal/tortoisegit-colons test2

vagrant@precise64:/vagrant/git$ cd test2

vagrant@precise64:/vagrant/git/test2$ git status

# On branch master

# Your branch is up-to-date with 'origin/master'.

#

# Untracked files:

#   (use "git add <file>..." to include in what will be committed)

#

#       ifcfg-eth0

#

nothing added to commit but untracked files present (use "git add" to track)

vagrant@precise64:/vagrant/git/test2$ rm ifcfg-eth0

vagrant@precise64:/vagrant/git/test2$ git status

# On branch master

# Your branch is up-to-date with 'origin/master'.

#

# Changes not staged for commit:

#   (use "git add/rm <file>..." to update what will be committed)

#   (use "git checkout -- <file>..." to discard changes in working directory)

#

#       deleted:    ifcfg-eth0:0

#

no changes added to commit (use "git add" and/or "git commit -a")

the file is not staged.

That's why I wish that file is not staged also in bash. ^_^

Yue Lin Ho

[Yue Lin Ho]

Yue Lin Ho於 2015年3月18日星期三 UTC+8下午3時27分06秒寫道：

Also tried this:

vagrant@precise64:/vagrant/git$ git clone -n https://github.com/t-pascal/tortoisegit-colons test3

vagrant@precise64:/vagrant/git$ cd test3

vagrant@precise64:/vagrant/git/test3$ git status

# On branch master

# Your branch is up-to-date with 'origin/master'.

#

# Changes to be committed:

#   (use "git reset HEAD <file>..." to unstage)

#

#       deleted:    README.md

#       deleted:    ifcfg-eth0-0

#       deleted:    ifcfg-eth0:0

#

vagrant@precise64:/vagrant/git/test3$ git reset HEAD ifcfg-eth0:0

Unstaged changes after reset:

D       ifcfg-eth0:0

vagrant@precise64:/vagrant/git/test3$ git status

# On branch master

# Your branch is up-to-date with 'origin/master'.

#

# Changes to be committed:

#   (use "git reset HEAD <file>..." to unstage)

#

#       deleted:    README.md

#       deleted:    ifcfg-eth0-0

#

# Changes not staged for commit:

#   (use "git add/rm <file>..." to update what will be committed)

#   (use "git checkout -- <file>..." to discard changes in working directory)

#

#       deleted:    ifcfg-eth0:0

#

This is wanted.

I can modify/delete/do anything on the file README.md, 

then commit the changes with leaving "ifcfg-eth0:0" behind.

Yue Lin Ho

 

[Johannes Schindelin]

On 2015-03-18 08:27, Yue Lin Ho wrote:
> Johannes Schindelin於 2015年3月18日星期三 UTC+8下午3時08分58秒寫道：

>>
>> This here procedure works here:
>>
>> ```bash
>> $ git clone -n https://github.com/t-pascal/tortoisegit-colons
>> ...
>

> tried it both in bash and vagrant, the same behavior
> all file is deleted and staged.

Are you sure you passed the `-n` flag?

[Johannes Schindelin]

On 2015-03-18 08:39, Yue Lin Ho wrote:
> Yue Lin Ho於 2015年3月18日星期三 UTC+8下午3時27分06秒寫道：
>>
>> Johannes Schindelin於 2015年3月18日星期三 UTC+8下午3時08分58秒寫道：
>>>
>>> On 2015-03-18 00:13, Yue Lin Ho wrote:
>>> > Philip Oakley於 2015年3月18日星期三 UTC+8上午1時27分34秒寫道：
>>> >

>>> This here procedure works here:
>>>
>>> ```bash
>>> $ git clone -n https://github.com/t-pascal/tortoisegit-colons
>>> ...
>>> $ cd tortoisegit-colons
>>> $ git config -c core.sparseCheckout true
>>> $ echo README.md > .git/info/sparse-checkout
>>> $ git checkout master
>>> ```
>

> Also tried this:
>
> vagrant@precise64:/vagrant/git$ git clone -n
> https://github.com/t-pascal/tortoisegit-colons test3
> vagrant@precise64:/vagrant/git$ cd test3
> vagrant@precise64:/vagrant/git/test3$ git status
> # On branch master
> # Your branch is up-to-date with 'origin/master'.
> #
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # deleted: README.md
> # deleted: ifcfg-eth0-0
> # deleted: ifcfg-eth0:0
> #
>

> vagrant@precise64:/vagrant/git/test3$ *git reset HEAD ifcfg-eth0:0*

Why reset? After this command, the index is already messed up. You
should set the sparse checkout *directly* after cloning with the `-n`
flag. Before anything else. And then `git checkout master`.

I fear that it might be necessary to get familiar with the index and
with the flags set in it. In particular the details when it is modified,
initialized and how the Git commands interact with the working
directory. As Philip indicated, this is one of the more obscure Git
functions, and it will not be easy to use it without knowing the
internals that are involved in it. So I guess just copy-pasting commands
from my mails will not do any good...

[Yue Lin Ho]

Johannes Schindelin於 2015年3月18日星期三 UTC+8下午5時11分30秒寫道：

I am not sure. re-tried:

In bash:

User@PC /d/Repo

$ git clone -n https://github.com/t-pascal/tortoisegit-colons.git test1

Cloning into 'test1'...

remote: Counting objects: 17, done.

remote: Compressing objects: 100% (12/12), done.

remote: Total 17 (delta 4), reused 16 (delta 3), pack-reused 0

Unpacking objects: 100% (17/17), done.

Checking connectivity... done.

User@PC /d/Repo

$ cd test1

User@PC /d/Repo/test1 (master)

$ git status

On branch master

Your branch is up-to-date with 'origin/master'.

Changes to be committed:

  (use "git reset HEAD <file>..." to unstage)

        deleted:    README.md

        deleted:    ifcfg-eth0-0

        deleted:    ifcfg-eth0:0

User@PC /d/Repo/test1 (master)

$ git config core.sparseCheckout true

User@PC /d/Repo/test1 (master)

$ echo README.md > .git/info/sparse-checkout

User@PC /d/Repo/test1 (master)

$ git checkout master

error: Invalid path 'ifcfg-eth0:0'

D       ifcfg-eth0:0

Already on 'master'

Your branch is up-to-date with 'origin/master'.

User@PC /d/Repo/test1 (master)

$ git status

On branch master

Your branch is up-to-date with 'origin/master'.

Changes to be committed:

  (use "git reset HEAD <file>..." to unstage)

        deleted:    ifcfg-eth0:0

In vagrant:

vagrant@precise64:/vagrant/git$ git clone -n https://github.com/t-pascal/tortoisegit-colons.git test1

Cloning into 'test1'...

remote: Counting objects: 17, done.

remote: Compressing objects: 100% (12/12), done.

remote: Total 17 (delta 4), reused 16 (delta 3), pack-reused 0

Unpacking objects: 100% (17/17), done.

Checking connectivity... done.

vagrant@precise64:/vagrant/git$ cd test1

vagrant@precise64:/vagrant/git/test1$ git config core.sparseCheckout true

vagrant@precise64:/vagrant/git/test1$ echo README.md > .git/info/sparse-checkout

vagrant@precise64:/vagrant/git/test1$ git checkout master

Already on 'master'

Your branch is up-to-date with 'origin/master'.

vagrant@precise64:/vagrant/git/test1$ git status

# On branch master

# Your branch is up-to-date with 'origin/master'.

#

nothing to commit, working directory clean

SORRY, they are different. :P

[Yue Lin Ho]

Johannes Schindelin於 2015年3月18日星期三 UTC+8下午5時16分26秒寫道：

Just another way to not commit the deleted ifcfg-eth0:0 file with other changes.

 

After this command, the index is already messed up. You
should set the sparse checkout *directly* after cloning with the `-n`
flag. Before anything else. And then `git checkout master`.

I fear that it might be necessary to get familiar with the index and
with the flags set in it. In particular the details when it is modified,
initialized and how the Git commands interact with the working
directory. As Philip indicated, this is one of the more obscure Git
functions, and it will not be easy to use it without knowing the
internals that are involved in it. So I guess just copy-pasting commands
from my mails will not do any good...

So, I prefer assume unchanged. :-)

 

[Johannes Schindelin]

On 2015-03-18 10:33, Yue Lin Ho wrote:
> Johannes Schindelin於 2015年3月18日星期三 UTC+8下午5時11分30秒寫道：
>>
> User@PC /d/Repo
> $ *git clone -n https://github.com/t-pascal/tortoisegit-colons.git
> test1*

> Cloning into 'test1'...
> remote: Counting objects: 17, done.
> remote: Compressing objects: 100% (12/12), done.
> remote: Total 17 (delta 4), reused 16 (delta 3), pack-reused 0
> Unpacking objects: 100% (17/17), done.
> Checking connectivity... done.
>
> User@PC /d/Repo

> $ *cd test1*
>
> User@PC /d/Repo/test1 (master)
> $ *git status*

> On branch master
> Your branch is up-to-date with 'origin/master'.
>
> Changes to be committed:
> (use "git reset HEAD <file>..." to unstage)
>
> deleted: README.md
> deleted: ifcfg-eth0-0
> deleted: ifcfg-eth0:0

This is the only difference that I see between what I did and what you
did: I did not call `git status`. Now, `git status` is known to refresh
the index, which I think might be the culprit.

Unfortunately, at this point I need to bow out of the mail thread (too
much other Git for Windows work).

[Yue Lin Ho]

Johannes Schindelin於 2015年3月18日星期三 UTC+8下午6時42分03秒寫道：

Wow~

 

Unfortunately, at this point I need to bow out of the mail thread (too
much other Git for Windows work).

And thanks for your time, help and patience. ^_^

 

[Philip Oakley]

From: Yue Lin Ho

Just to clarify that my proposed use of Sparse checkout was to set the file with a _negative_ pathspec, such that everything bar the colon-in-filename could be checked out , but that the colon file would stay firmly inside the repository's object store, and never try to get into the file system.

 

The index would still know and love it and believe it to be part of the worktree of its parent directory, but Windows wouldn't care.

 

In particular see 'git help read-tree' for the Sparse Checkout explanation and how to ignore the file 'unwanted' ;-)

 

That all said, I haven't used the facility personally.

 

Philip

[Yue Lin Ho]

Philip Oakley於 2015年3月19日星期四 UTC+8上午6時13分54秒寫道：

Johannes Schindelin於 2015年3月18日星期三 UTC+8下午5時16分26秒寫道：

On 2015-03-18 08:39, Yue Lin Ho wrote:
> Yue Lin Ho於 2015年3月18日星期三 UTC+8下午3時27分06秒寫道：
>> Johannes Schindelin於 2015年3月18日星期三 UTC+8下午3時08分58秒寫道：
>>> On 2015-03-18 00:13, Yue Lin Ho wrote:
>>> > Philip Oakley於 2015年3月18日星期三 UTC+8上午1時27分34秒寫道：
>>> This here procedure works here:
>>> ```bash
>>> $ git clone -n https://github.com/t-pascal/tortoisegit-colons
>>> ...
>>> $ cd tortoisegit-colons
>>> $ git config -c core.sparseCheckout true
>>> $ echo README.md > .git/info/sparse-checkout
>>> $ git checkout master
>>> ```

> vagrant@precise64:/vagrant/git$ git clone -n
> https://github.com/t-pascal/tortoisegit-colons test3
> vagrant@precise64:/vagrant/git$ cd test3
> vagrant@precise64:/vagrant/git/test3$ git status

> vagrant@precise64:/vagrant/git/test3$ *git reset HEAD ifcfg-eth0:0*

Why reset?

Just another way to not commit the deleted ifcfg-eth0:0 file with other changes.

 

After this command, the index is already messed up. You
should set the sparse checkout *directly* after cloning with the `-n`
flag. Before anything else. And then `git checkout master`.

I fear that it might be necessary to get familiar with the index and
with the flags set in it. In particular the details when it is modified,
initialized and how the Git commands interact with the working
directory. As Philip indicated, this is one of the more obscure Git
functions, and it will not be easy to use it without knowing the
internals that are involved in it. So I guess just copy-pasting commands
from my mails will not do any good...

So, I prefer assume unchanged. :-)

Just to clarify that my proposed use of Sparse checkout was to set the file with a _negative_ pathspec, such that everything bar the colon-in-filename could be checked out , but that the colon file would stay firmly inside the repository's object store, and never try to get into the file system.

The index would still know and love it and believe it to be part of the worktree of its parent directory, but Windows wouldn't care.

In particular see 'git help read-tree' for the Sparse Checkout explanation and how to ignore the file 'unwanted' ;-)

That all said, I haven't used the facility personally.

Thank you for the idea of sparse checkout. :)

 

Re-tried "-n" of clone

  User@PC /d/Repo

  $ git clone -n https://github.com/t-pascal/tortoisegit-colons.git test10

  Cloning into 'test10'...

  remote: Counting objects: 17, done.

  remote: Compressing objects: 100% (12/12), done.

  remote: Total 17 (delta 4), reused 16 (delta 3), pack-reused 0

  Unpacking objects: 100% (17/17), done.

  Checking connectivity... done.

  User@PC /d/Repo

  $ cd test10

  User@PC /d/Repo/test10 (master)

  $ echo README.md > .git/info/sparse-checkout

  User@PC /d/Repo/test10 (master)

  $ git checkout master

  error: Invalid path 'ifcfg-eth0:0'

  D       ifcfg-eth0:0

  Already on 'master'

  Your branch is up-to-date with 'origin/master'.

  User@PC /d/Repo/test10 (master)

  $ echo xxx > README.md

  User@PC /d/Repo/test10 (master)

  $ git add README.md

  User@PC /d/Repo/test10 (master)

  $ git commit -m "modified README.md"

  [master 66a5d8c] modified README.md

   2 files changed, 1 insertion(+), 20 deletions(-)

   rewrite README.md (100%)

   delete mode 100644 ifcfg-eth0:0

Sad for that file is deleted in new commit. :-/

[Philip Oakley]

From: Yue Lin Ho

This step:

  User@PC /d/Repo/test10 (master)

  $ echo README.md > .git/info/sparse-checkout

 

is the one that I expected to be changed.

You should be setting (as I understand it)

 

$ echo /* > .git/info/sparse-checkout

$ echo !ifcfg-eth0:0 >> .git/info/sparse-checkout

 

so that that file is excluded from the checkout. Without the negative "!" you don't exclude that file from the checkout. Though it maybe that the code isn't selective enough to avoid the file system while it's doing that check.

 

I haven't had chance to check any of this, so ... I may be wrong.

 

Philip

 

 

 

[Yue Lin Ho]

Philip Oakley於 2015年3月19日星期四 UTC+8下午4時39分25秒寫道：



From: Yue Lin Ho

Philip Oakley於 2015年3月19日星期四 UTC+8上午6時13分54秒寫道：

 

Re-tried "-n" of clone

  User@PC /d/Repo

  $ git clone -n https://github.com/t-pascal/tortoisegit-colons.git test10

  [snip]

  User@PC /d/Repo

  $ cd test10

  User@PC /d/Repo/test10 (master)

  $ echo README.md > .git/info/sparse-checkout

  User@PC /d/Repo/test10 (master)

  $ git checkout master

  error: Invalid path 'ifcfg-eth0:0'

  D       ifcfg-eth0:0

  Already on 'master'

  Your branch is up-to-date with 'origin/master'.

  User@PC /d/Repo/test10 (master)

  $ echo xxx > README.md

  User@PC /d/Repo/test10 (master)

  $ git add README.md

  User@PC /d/Repo/test10 (master)

  $ git commit -m "modified README.md"

  [master 66a5d8c] modified README.md

   2 files changed, 1 insertion(+), 20 deletions(-)

   rewrite README.md (100%)

   delete mode 100644 ifcfg-eth0:0

Sad for that file is deleted in new commit. :-/

This step:

  Us...@PC /d/Repo/test10 (master)

  $ echo README.md > .git/info/sparse-checkout

 

is the one that I expected to be changed.

You should be setting (as I understand it)

 

$ echo /* > .git/info/sparse-checkout

$ echo !ifcfg-eth0:0 >> .git/info/sparse-checkout

 

so that that file is excluded from the checkout. Without the negative "!" you don't exclude that file from the checkout. Though it maybe that the code isn't selective enough to avoid the file system while it's doing that check.

 

I haven't had chance to check any of this, so ... I may be wrong.

 

Okey, one more trying:

  User@PC /d/Repo

  $ git clone -n https://github.com/t-pascal/tortoisegit-colons.git test11

  [snip]

  Checking connectivity... done.

  User@PC /d/Repo

  $ cd test11

  User@PC /d/Repo/test11 (master)

  $ echo /* > .git/info/sparse-checkout

  User@PC /d/Repo/test11 (master)

  $ echo !ifcfg-eth0:0 >> .git/info/sparse-checkout

  sh.exe": !ifcfg-eth0: event not found

the content of .git/info/sparse-checkout

```

/Git Bash.vbs /ReleaseNotes.rtf /bin /cmd /doc /etc /git-cheetah /lib /libexec /share /ssl /unins000.dat /unins000.exe

```

Then, I add "!ifcfg-eth0:0" to second line.

  

  User@PC /d/Repo/test11 (master)

  $ git checkout master

  error: Invalid path 'ifcfg-eth0:0'

  D       ifcfg-eth0:0

  Already on 'master'

  Your branch is up-to-date with 'origin/master'.

  User@PC /d/Repo/test11 (master)

  $ echo modify >> README.md

  User@PC /d/Repo/test11 (master)

  $ git commit -m "Just want to commit the change of README.md only"

  [master 72e82b7] Just want to commit the change of README.md only

   1 file changed, 6 deletions(-)

   delete mode 100644 ifcfg-eth0:0

same sad. :P

 

[Philip Oakley]

From: Yue Lin Ho

Philip Oakley於 2015年3月19日星期四 UTC+8上午6時13分54秒寫道：

Johannes Schindelin於 2015年3月18日星期三 UTC+8下午5時16分26秒寫道：

On 2015-03-18 08:39, Yue Lin Ho wrote:
> Yue Lin Ho於 2015年3月18日星期三 UTC+8下午3時27分06秒寫道：
>> Johannes Schindelin於 2015年3月18日星期三 UTC+8下午3時08分58秒寫道：
>>> On 2015-03-18 00:13, Yue Lin Ho wrote:
>>> > Philip Oakley於 2015年3月18日星期三 UTC+8上午1時27分34秒寫道：
>>> This here procedure works here:
>>> ```bash
>>> $ git clone -n https://github.com/t-pascal/tortoisegit-colons
>>> ...
>>> $ cd tortoisegit-colons
>>> $ git config -c core.sparseCheckout true
>>> $ echo README.md > .git/info/sparse-checkout
>>> $ git checkout master
>>> ```

I fear that it might be necessary to get familiar with the index and

Ok so I'm half admitting defeat.

The sparse-checkout file should read

/*
!ifcfg-eth0\:0

 

(note the backslash escaping of the colon)

I tried

Philip@PHILIPOAKLEY /d/Git_repos/tortoisegit-colons (master)
$ git update-index --skip-worktree -- ifcfg-eth0\:0
Ignoring path ifcfg-eth0:0

 

So it says it's ignoring OK but then no amount of attemting to

Philip@PHILIPOAKLEY /d/Git_repos/tortoisegit-colons (master)
$ git checkout -b test 7f35d34bc6160cc
D       ifcfg-eth0:0
Switched to a new branch 'test'

 

Philip@PHILIPOAKLEY /d/Git_repos/tortoisegit-colons (test)
$ git update-index --skip-worktree -- ifcfg-eth0\:0
Ignoring path ifcfg-eth0:0

 

Philip@PHILIPOAKLEY /d/Git_repos/tortoisegit-colons (test)
$ git status
On branch test
Changes to be committed:

  (use "git reset HEAD <file>..." to unstage)

 

        deleted:    ifcfg-eth0:0

 

 

managed to get to the scenario where the sparse checkout worked as I expected.

 

I will report it upstream to g...@vger.kernel.org to see if they can help.

 

Philip

 

 

[Philip Oakley]

Cut and trimmed to make it easy to read 

Philip@PHILIPOAKLEY /d/Git_repos/tortoisegit-colons (master)
$ git update-index --skip-worktree -- ifcfg-eth0\:0
Ignoring path ifcfg-eth0:0

 

So it says it's ignoring OK but then no amount of attemting to

[...]

managed to get to the scenario where the sparse checkout worked as I expected.

 

I will report it upstream to g...@vger.kernel.org to see if they can help.

 

Philip

tl;dr It did not work as expected.