Re: Git issue report

[Junio C Hamano]

"xfswi...@163.com"  writes:

> Hi,
>   I met a issue when using git.
> I cannot delete the file by the commond 'git rm'.
> The file name is a little diff from common file.
> I accidentally named the file "filename\r", display such as filename^M. Then 
> I commit the file by 'git add .'.
> After I find this mistake, I remove the file, then try to use commond "git 
> rm" to delete the file, but failed.
>
> My git version is 1.7.9.5.

The following works fine with v1.7.9.5 (I have separate installs of
various versions of Git and use "rungit $version" to choose from
them, so just read "rungit v1.7.9.5" below as if it is "git").

$ rungit v1.7.9.5 init
$ N=$(printf "filename\015")
$ echo >"$N"
$ /bin/ls fil* | od -cx
000   f   i   l   e   n   a   m   e  \r  \n
   6966656c616e656d0a0d
012
$ rungit v1.7.9.5 add .
$ rungit v1.7.9.5 ls-files
"filename\r"
$ rm filename*
$ rungit v1.7.9.5 rm filename*
$ rungit v1.7.9.5 ls-files 
$ /bin/ls
$ exit

and I do not think of any reason why we would have broken it since.

FYI, you do not have to do a separate "rm filename*" in the above
sequence; "git rm filename*" would remove it from both the working
tree and from the index.  I did it in the above illustration in two
separate steps only because you said you removed and then did "git
rm" and I wanted to emulate it.

> Is this issue reported?

I do not recall hearing about it, but you must have looked for one
hard already and I haven't, so...

> If this issue is solved, could you tell me which version I should get.

It appears to me that such an issue did not exist in the first
place.

Re: Git issue - ignoring changes to tracked file with assume-unchanged

[Jakub Narębski]

W dniu 01.11.2016 o 19:11, Junio C Hamano pisze:
> Jeff King  writes:
>> On Tue, Nov 01, 2016 at 10:28:57AM +, Halde, Faiz wrote:
>>
>>> I frequently use the following command to ignore changes done in a file
>>>
>>> git update-index --assume-unchanged somefile
>>>
>>> Now when I do a pull from my remote branch and say the file 'somefile'
>>> was changed locally and in remote, git will abort the merge saying I
>>> need to commit my changes of 'somefile'.
>>>
>>> But isn't the whole point of the above command to ignore the changes
>>> within the file?
>>
>> No. The purpose of --assume-unchanged is to promise git that you will
>> not change the file, so that it may skip checking the file contents in
>> some cases as an optimization.
> 
> That's correct.  
> 
> The next anticipated question is "then how would I tell Git to
> ignore changes done to a file locally by me?", whose short answer is
> "You don't", of course.

Well, you can always use --skip-worktree.  It is a better fit than using
--assume-unchanged, because at least you wouldn't loose your precious
local changes (which happened to me).

OTOH it doesn't solve your issue of --skip-worktree / --assume-unchanged
blocking operation (pull in your case, stash is what I noticed problem
with when using --skip-worktree).

But --skip-worktree is still workaround...

-- 
Jakub Narębski

Re: Git issue

[Jacob Keller]

On Tue, Nov 1, 2016 at 2:23 PM, Junio C Hamano  wrote:
> Jeff King  writes:
>
>> On Tue, Nov 01, 2016 at 08:50:23PM -, Philip Oakley wrote:
>>
>>> > From "git help update-index":
>>> >
>>> >  --[no-]assume-unchanged
>>> >When this flag is specified, the object names recorded for
>>> >the paths are not updated. Instead, this option sets/unsets
>>> >the "assume unchanged" bit for the paths. ...
>>
>> I think the "Instead" is "we are not doing the usual update-index thing
>> of reading the new data from disk; instead, we are _just_ setting the
>> bit". Perhaps that can be spelled out more clearly, but I think just
>> dropping "Instead" is a step backwards.
>
> I tend to agree; the biggest problem with this part of the
> description I think is that it starts by saying what it does not do,
> which may help people who expect the command to do its usual thing
> but otherwise is a secondary information.  How about ripping it out
> and moving it after the primary description, i.e.
>
> Set or unset the "assume unchanged" bit for the paths,
> without changing the object names recorded for them, in the
> index.
>
>>> Given the number of misrepresentations (on the web) of what the bit does,
>>> and the ongoing misunderstandings of users it does feel like the man page
>>> article could be refreshed to be more assertive about the users promise, and
>>> Git's cautions.
>>
>> I dunno. I know this has long been a source of confusion, but I
>> specifically dug in the docs to see what we had, and I thought what I
>> quoted above was pretty clear. That has "only" been around for about 2
>> years, and is fighting against other mis-advice on the Internet, though.
>> So I'm not sure if it is badly worded, or if people simply do not see
>> it.
>
> I share the same reaction, and I find that the update in ccadb25f73
> ("doc: make clear --assume-unchanged's user contract", 2014-12-06)
> that introduced the "the user promises not to change and allows Git
> to assume" is sufficiently clear.
>

This is some what of a tangent, but

One of the primary pieces of advice I've seen that encourages its use
was to set it for a submodule after a repository switched to using
submodules. The reasoning being that users were often running "git
commit -a" and accidentally including changes to their submodule
without realizing it because they were not used to keeping the
submodule up to date.

I saw advice for this and it mostly appeared to work, but I wonder if
there is a better solution. I failed to train people to simply stop
committing everything with "git add ." or "git commit -a" as this was
something they were too used to from using previous version control
systems.

Is there an alternative that would prevent "add everything" from
adding these files so that users wouldn't commit rewinds to
submodules?

Thanks,
Jake

Re: Git issue

[Junio C Hamano]

Jeff King  writes:

> On Tue, Nov 01, 2016 at 08:50:23PM -, Philip Oakley wrote:
>
>> > From "git help update-index":
>> > 
>> >  --[no-]assume-unchanged
>> >When this flag is specified, the object names recorded for
>> >the paths are not updated. Instead, this option sets/unsets
>> >the "assume unchanged" bit for the paths. ...
>
> I think the "Instead" is "we are not doing the usual update-index thing
> of reading the new data from disk; instead, we are _just_ setting the
> bit". Perhaps that can be spelled out more clearly, but I think just
> dropping "Instead" is a step backwards.

I tend to agree; the biggest problem with this part of the
description I think is that it starts by saying what it does not do,
which may help people who expect the command to do its usual thing
but otherwise is a secondary information.  How about ripping it out
and moving it after the primary description, i.e.

Set or unset the "assume unchanged" bit for the paths,
without changing the object names recorded for them, in the
index.

>> Given the number of misrepresentations (on the web) of what the bit does,
>> and the ongoing misunderstandings of users it does feel like the man page
>> article could be refreshed to be more assertive about the users promise, and
>> Git's cautions.
>
> I dunno. I know this has long been a source of confusion, but I
> specifically dug in the docs to see what we had, and I thought what I
> quoted above was pretty clear. That has "only" been around for about 2
> years, and is fighting against other mis-advice on the Internet, though.
> So I'm not sure if it is badly worded, or if people simply do not see
> it.

I share the same reaction, and I find that the update in ccadb25f73
("doc: make clear --assume-unchanged's user contract", 2014-12-06)
that introduced the "the user promises not to change and allows Git
to assume" is sufficiently clear.

Re: Git issue

[Jeff King]

On Tue, Nov 01, 2016 at 08:50:23PM -, Philip Oakley wrote:

> > From "git help update-index":
> > 
> >  --[no-]assume-unchanged
> >When this flag is specified, the object names recorded for
> >the paths are not updated. Instead, this option sets/unsets
> >the "assume unchanged" bit for the paths. When the "assume
> >unchanged" bit is on, the user promises not to change the
> >file and allows Git to assume that the working tree file
> >matches what is recorded in the index. If you want to change
> >the working tree file, you need to unset the bit to tell Git.
> >This is sometimes helpful when working with a big project on
> >a filesystem that has very slow lstat(2) system call (e.g.
> >cifs).
> > 
> >Git will fail (gracefully) in case it needs to modify this
> >file in the index e.g. when merging in a commit; thus, in
> >case the assumed-untracked file is changed upstream, you will
> >need to handle the situation manually.
> > 
> 
> The whole section (including the ones above this quote) are often confused
> between the promises of the user, and the alleged promises of Git. Even in
> the quote above the "Instead" probably shouldn't be there.

I think the "Instead" is "we are not doing the usual update-index thing
of reading the new data from disk; instead, we are _just_ setting the
bit". Perhaps that can be spelled out more clearly, but I think just
dropping "Instead" is a step backwards.

> Given the number of misrepresentations (on the web) of what the bit does,
> and the ongoing misunderstandings of users it does feel like the man page
> article could be refreshed to be more assertive about the users promise, and
> Git's cautions.

I dunno. I know this has long been a source of confusion, but I
specifically dug in the docs to see what we had, and I thought what I
quoted above was pretty clear. That has "only" been around for about 2
years, and is fighting against other mis-advice on the Internet, though.
So I'm not sure if it is badly worded, or if people simply do not see
it.

-Peff

Re: Git issue

[Philip Oakley]

From: "Jeff King" 

On Tue, Nov 01, 2016 at 10:28:57AM +, Halde, Faiz wrote:


I frequently use the following command to ignore changes done in a file

git update-index --assume-unchanged somefile

Now when I do a pull from my remote branch and say the file 'somefile'
was changed locally and in remote, git will abort the merge saying I
need to commit my changes of 'somefile'.

But isn't the whole point of the above command to ignore the changes
within the file?


No. The purpose of --assume-unchanged is to promise git that you will
not change the file, so that it may skip checking the file contents in
some cases as an optimization.


True. However...



From "git help update-index":

 --[no-]assume-unchanged
   When this flag is specified, the object names recorded for
   the paths are not updated. Instead, this option sets/unsets
   the "assume unchanged" bit for the paths. When the "assume
   unchanged" bit is on, the user promises not to change the
   file and allows Git to assume that the working tree file
   matches what is recorded in the index. If you want to change
   the working tree file, you need to unset the bit to tell Git.
   This is sometimes helpful when working with a big project on
   a filesystem that has very slow lstat(2) system call (e.g.
   cifs).

   Git will fail (gracefully) in case it needs to modify this
   file in the index e.g. when merging in a commit; thus, in
   case the assumed-untracked file is changed upstream, you will
   need to handle the situation manually.



The whole section (including the ones above this quote) are often confused 
between the promises of the user, and the alleged promises of Git. Even in 
the quote above the "Instead" probably shouldn't be there.


Given the number of misrepresentations (on the web) of what the bit does, 
and the ongoing misunderstandings of users it does feel like the man page 
article could be refreshed to be more assertive about the users promise, and 
Git's cautions.


My quick rough working on a more assertive update..
-- >8 --
--  
Documentation/git-update-index.txt --

index 7386c93..4ec1711 100644
@@ -84,12 +84,12 @@ OPTIONS
Set the execute permissions on the updated files.

--[no-]assume-unchanged::
 When this flag is specified, the object names recorded
- for the paths are not updated.  Instead, this option
+ for the paths are not updated.  This option
 sets/unsets the "assume unchanged" bit for the
 paths.  When the "assume unchanged" bit is on, the user
- promises not to change the file and allows Git to assume
+ *promises* not to change the file and allows Git to assume
 that the working tree file matches what is recorded in
 the index.  If you want to change the working tree file,
 you need to unset the bit to tell Git.  This is
 sometimes helpful when working with a big project on a
@@ -300,19 +300,25 @@ $ git ls-files -s

Using ``assume unchanged'' bit
--

-Many operations in Git depend on your filesystem to have an
+Many operations in Git depend on your filesystem having a fast and
efficient `lstat(2)` implementation, so that `st_mtime`
information for working tree files can be cheaply checked to see
if the file contents have changed from the version recorded in
the index file.  Unfortunately, some filesystems have
inefficient `lstat(2)`.  If your filesystem is one of them, you
-can set "assume unchanged" bit to paths you have not changed to
-cause Git not to do this check.  Note that setting this bit on a
-path does not mean Git will check the contents of the file to
-see if it has changed -- it makes Git to omit any checking and
-assume it has *not* changed.  When you make changes to working
+can set "assume unchanged" bit to *paths you have not changed* to
+cause Git not to do this check.
+
+Note that setting this bit on a
+path does not mean Git will never check the contents of the file to
+see if it has changed. Though normally it makes Git to omit any checking to
+assume it has not changed.
+Commands which may overwrite local changes (pull/merge etc) are
+likely to check if the contents have changed
+
+If you make desired changes to working
tree files, you have to explicitly tell Git about it by dropping
"assume unchanged" bit, either before or after you modify them.

In order to set "assume unchanged" bit, use `--assume-unchanged`
---
Philip 

Re: Git issue

[Junio C Hamano]

Jeff King  writes:

> On Tue, Nov 01, 2016 at 10:28:57AM +, Halde, Faiz wrote:
>
>> I frequently use the following command to ignore changes done in a file
>> 
>> git update-index --assume-unchanged somefile
>> 
>> Now when I do a pull from my remote branch and say the file 'somefile'
>> was changed locally and in remote, git will abort the merge saying I
>> need to commit my changes of 'somefile'.
>> 
>> But isn't the whole point of the above command to ignore the changes
>> within the file?
>
> No. The purpose of --assume-unchanged is to promise git that you will
> not change the file, so that it may skip checking the file contents in
> some cases as an optimization.

That's correct.  

The next anticipated question is "then how would I tell Git to
ignore changes done to a file locally by me?", whose short answer is
"You don't", of course.

People may however wonder, if Git can make things more automatic if
the user is willing to tell her intention of what should happen to
"somefile" in the example above when an operation requested cannot
proceed while ignoring the local changes.  For example, "ignore my
change and overwrite as needed" could be such an instruction (and it
is obvious what should happen in that case when "git pull" was
done--just clobber it with the version from the other side).

As I do not think of other sensible alternative behaviour, and I do
not think Git should make it easy to lose local changes when the
user is doing things like "pull" [*1*], it leads to the longer
answer to the question, which is again "You don't" ;-).


[Footnote]

*1* Things like "git checkout [] [--] ", "git rm -f" and
"git reset --hard" are ways to explicit request nuking the local
changes, and presence of these commands do not contradict with
"do not make it easy to lose local changes", of course.

Re: Git issue

[Jeff King]

On Tue, Nov 01, 2016 at 10:28:57AM +, Halde, Faiz wrote:

> I frequently use the following command to ignore changes done in a file
> 
> git update-index --assume-unchanged somefile
> 
> Now when I do a pull from my remote branch and say the file 'somefile'
> was changed locally and in remote, git will abort the merge saying I
> need to commit my changes of 'somefile'.
> 
> But isn't the whole point of the above command to ignore the changes
> within the file?

No. The purpose of --assume-unchanged is to promise git that you will
not change the file, so that it may skip checking the file contents in
some cases as an optimization.

>From "git help update-index":

  --[no-]assume-unchanged
   When this flag is specified, the object names recorded for
   the paths are not updated. Instead, this option sets/unsets
   the "assume unchanged" bit for the paths. When the "assume
   unchanged" bit is on, the user promises not to change the
   file and allows Git to assume that the working tree file
   matches what is recorded in the index. If you want to change
   the working tree file, you need to unset the bit to tell Git.
   This is sometimes helpful when working with a big project on
   a filesystem that has very slow lstat(2) system call (e.g.
   cifs).

   Git will fail (gracefully) in case it needs to modify this
   file in the index e.g. when merging in a commit; thus, in
   case the assumed-untracked file is changed upstream, you will
   need to handle the situation manually.

-Peff

Re: Git issue report : issue with capital letter in folder name

[Stefan Beller]

On Thu, Dec 17, 2015 at 7:45 AM, PFDuc
 wrote:
> Hello,
>
> first of all thank you for developping git !
>
> I had an issue with a capital block in the folder name inside my git repo.
> The folder in my local was named "Display" and the one at origin was named
> "display" resulting in error when importing python code from this folder for
> users who got the repo from origin.

By any chance, were different operating systems or file systems
involved in creation of
this problem?

There are file systems which care about the capitalization, and others don't.
So if you have a file system which doesn't care about capitalization
of the folder/file name,
you can use a different capitalization and it still works. If you take
the code to
another system then, which is a bit more careful there are problems of course.

The main question which remains, is how is Git involved? i.e. would it
also happen
if you just transfer a tarball? Did Git itself break anything?

>
> I tried to change the folder name on bitbucket.org but I was unable to (or
> wasn't smart enough to find how to).
>
> I fixed the issue by deleting the file from my local, then commit, then
> push, put the same folder in my local, then commit then push.
>
> I am therefore only writing to tell you that story which is not so
> important, but I had the thought that because it is not so important maybe
> nobody reports that and the bug (if any) cannot be fixed.
>
> Have a good day and happy end of year season!
>
> Regards,
>
> Pierre-François Duc
> PhD candidate Physics McGill university
> --
> 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: Git issue report : issue with capital letter in folder name

[PFDuc]

Le 2015-12-17 13:29, Stefan Beller a écrit :

On Thu, Dec 17, 2015 at 7:45 AM, PFDuc
 wrote:

Hello,

first of all thank you for developping git !

I had an issue with a capital block in the folder name inside my git repo.
The folder in my local was named "Display" and the one at origin was named
"display" resulting in error when importing python code from this folder for
users who got the repo from origin.

By any chance, were different operating systems or file systems
involved in creation of
this problem?

It might be the case, a mix between windows7, ubuntu and macOS

There are file systems which care about the capitalization, and others don't.
So if you have a file system which doesn't care about capitalization
of the folder/file name,
you can use a different capitalization and it still works. If you take
the code to
another system then, which is a bit more careful there are problems of course.

The main question which remains, is how is Git involved? i.e. would it
also happen
if you just transfer a tarball? Did Git itself break anything?
I don't think git broke anything it is just that the folder name was not 
being changed to the one with a capital letter when I pushed on origin, 
the only way out I found was the one I described in my initial email. I 
thought then the problem might occur from git, but as you say it is 
probably a cross platform issue. The folder initially created was named 
display, then I changed it locally but git wouldn't recognize it as 
something to commit (platform windows7)


I just wanted to let you know in case it would have been an issue you 
wouldn't be aware of.


Regards,

Pierre-François

I tried to change the folder name on bitbucket.org but I was unable to (or
wasn't smart enough to find how to).

I fixed the issue by deleting the file from my local, then commit, then
push, put the same folder in my local, then commit then push.

I am therefore only writing to tell you that story which is not so
important, but I had the thought that because it is not so important maybe
nobody reports that and the bug (if any) cannot be fixed.

Have a good day and happy end of year season!

Regards,

Pierre-François Duc
PhD candidate Physics McGill university
--
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: git issue / [PATCH] MIPS: fix invalid symbolic link file

[Ralf Baechle]

On Thu, Sep 19, 2013 at 06:39:08PM +0530, Madhavan Srinivasan wrote:

(Git folks, please read on.)

Commit 3b29aa5ba204c created a symlink file in include/dt-bindings.
Even though commit diff is fine, symlink is invalid.
ls -lb shows a newline character at the end of the filename.
 
 lrwxrwxrwx 1 maddy maddy 35 Sep 19 18:11 dt-bindings -
 ../../../../../include/dt-bindings\n
 
 Signed-off-by: Madhavan Srinivasan ma...@linux.vnet.ibm.com
 ---
  arch/mips/boot/dts/include/dt-bindings |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/mips/boot/dts/include/dt-bindings 
 b/arch/mips/boot/dts/include/dt-bindings
 index 68ae388..08c00e4 12
 --- a/arch/mips/boot/dts/include/dt-bindings
 +++ b/arch/mips/boot/dts/include/dt-bindings
 @@ -1 +1 @@
 -../../../../../include/dt-bindings
 +../../../../../include/dt-bindings
 \ No newline at end of file
 -- 
 1.7.10.4

I applied your patch - but now git-show shows it as an empty commit and

  ls -lb arch/mips/boot/dts/include/dt-bindings

still shows the \n at the end of the link target.  Things are looking ok
now that I manually fixed the link and commited the result.  I hope
git-push and git-pull are going to handle this correct.

So, I wonder if this is a git bug.

The original patch that introduced the symlink with the \n is kernel
commit 3b29aa5ba204c62b3ec8f9f5b1ebd6e5d74f75d3 and is archived in
patchwork at http://patchwork.linux-mips.org/patch/5745/  The patch
file contains a \n at the end - but one would expect that from a
patch file that has been transfered via email, so I'm not sure how this
is supposed to work with emailed patches?!?

Anyway, I'm not too fond of sylinks in the tree or in patches and I'm
wondering if we could get rid of them for something more bullet proof.

  Ralf
--
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: git issue / [PATCH] MIPS: fix invalid symbolic link file

[Johannes Sixt]

Am 19.09.2013 15:39, schrieb Ralf Baechle:
 The original patch that introduced the symlink with the \n is kernel
 commit 3b29aa5ba204c62b3ec8f9f5b1ebd6e5d74f75d3 and is archived in
 patchwork at http://patchwork.linux-mips.org/patch/5745/  The patch
 file contains a \n at the end - but one would expect that from a
 patch file that has been transfered via email, so I'm not sure how this
 is supposed to work with emailed patches?!?

The mbox file I downloaded from this link looks like this:


arch/mips/boot/dts/include/dt-bindings | 1 +
 1 file changed, 1 insertion(+)
 create mode 12 arch/mips/boot/dts/include/dt-bindings

\ No newline at end of file

diff --git a/.../include/dt-bindings b/.../include/dt-bindings
new file mode 12
index 000..08c00e4
--- /dev/null
+++ b/arch/mips/boot/dts/include/dt-bindings
@@ -0,0 +1 @@
+../../../../../include/dt-bindings


but it should look like this:


arch/mips/boot/dts/include/dt-bindings | 1 +
 1 file changed, 1 insertion(+)
 create mode 12 arch/mips/boot/dts/include/dt-bindings

diff --git a/.../include/dt-bindings b/.../include/dt-bindings
new file mode 12
index 000..08c00e4
--- /dev/null
+++ b/arch/mips/boot/dts/include/dt-bindings
@@ -0,0 +1 @@
+../../../../../include/dt-bindings
\ No newline at end of file


Whoever or whatever moved the '\ No newline at end of file' line above
the patch text is to blame.

-- Hannes

--
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: git issue / [PATCH] MIPS: fix invalid symbolic link file

[Stephen Warren]

On 09/19/2013 01:49 PM, Johannes Sixt wrote:
 Am 19.09.2013 15:39, schrieb Ralf Baechle:
 The original patch that introduced the symlink with the \n is kernel
 commit 3b29aa5ba204c62b3ec8f9f5b1ebd6e5d74f75d3 and is archived in
 patchwork at http://patchwork.linux-mips.org/patch/5745/  The patch
 file contains a \n at the end - but one would expect that from a
 patch file that has been transfered via email, so I'm not sure how this
 is supposed to work with emailed patches?!?
 
 The mbox file I downloaded from this link looks like this:
...
 but it should look like this:
...
 Whoever or whatever moved the '\ No newline at end of file' line above
 the patch text is to blame.

That sounds like a patchwork problem; the original copy of the message I
received looks correct.
--
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