Hello Git
Not sure if this is a feature or a bug, but here it is.
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?
Thanks Faiz Halde
Jeff KingRe: Git issue
On Tue, Nov 01, 2016 at 10:28:57AM +0000, 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
Junio C HamanoRe: Git issue
Jeff King <peff@peff.net> writes:
> On Tue, Nov 01, 2016 at 10:28:57AM +0000, 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 [<tree>] [--] <path>", "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.
Jakub NarębskiRe: Git issue - ignoring changes to tracked file with assume-unchanged
W dniu 01.11.2016 o 19:11, Junio C Hamano pisze:
> Jeff King <peff@peff.net> writes: >> On Tue, Nov 01, 2016 at 10:28:57AM +0000, 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
Philip OakleyRe: Git issue
From: "Jeff King" <peff@peff.net>
> On Tue, Nov 01, 2016 at 10:28:57AM +0000, 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
Jeff KingRe: Git issue
On Tue, Nov 01, 2016 at 08:50:23PM -0000, 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
Junio C HamanoRe: Git issue
Jeff King <peff@peff.net> writes:
> On Tue, Nov 01, 2016 at 08:50:23PM -0000, 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.
Jacob KellerRe: Git issue
On Tue, Nov 1, 2016 at 2:23 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> On Tue, Nov 01, 2016 at 08:50:23PM -0000, 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
Philip Oakley[PATCH] doc: update-index --assume-unchanged
Be more assertive about the User promise, and Git's defensiveness of file changes.
Signed-off-by: Philip Oakley <philipoakley@iee.org> --- Here is a full patch for https://public-inbox.org/git/7CE3166CFD244DAABF554451E8B0800F@PhilipOakley/
--- Documentation/git-update-index.txt | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt index 7386c93..4ec1711 100644 --- a/Documentation/git-update-index.txt +++ b/Documentation/git-update-index.txt @@ -85,10 +85,10 @@ OPTIONS --[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 @@ -301,17 +301,23 @@ $ 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.
-- 2.9.0.windows.1.323.g0305acf