git issue

git issue

[Toralf Förster]

got today :

$ cd ~/devel/trinity; git pull                       
U       blockdevs.c
U       debug.c
U       rand/random-pathname.c
U       rand/random.c
U       shm.c
U       tools/analyze-sockets.c
U       uid.c
Pull is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>'
as appropriate to mark resolution and make a commit.


tfoerste@t44 ~/devel/trinity $ git diff

tfoerste@t44 ~/devel/trinity $ git status
On branch master
Your branch and 'origin/master' have diverged,
and have 3702 and 3711 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both added:      blockdevs.c
        both added:      debug.c
        both added:      rand/random-pathname.c
        both added:      rand/random.c
        both added:      shm.c
        both added:      tools/analyze-sockets.c
        both added:      uid.c

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

tfoerste@t44 ~/devel/trinity $ git diff | patch -R
patch: **** Only garbage was found in the patch input.

tfoerste@t44 ~/devel/trinity $ git diff
tfoerste@t44 ~/devel/trinity $

/me ownders how to solve this - I did not edit loally files AFAICT

-- 
Toralf
pgp key: 7B1A 07F4 EC82 0F90 D4C2  8936 872A E508 0076 E94E

Re: git issue

[Dave Jones]

On Wed, Jul 01, 2015 at 03:37:48PM +0200, Toralf Förster wrote:
 > got today :
 > 
 > $ cd ~/devel/trinity; git pull                       
 > U       blockdevs.c
 > U       debug.c
 > U       rand/random-pathname.c
 > U       rand/random.c
 > U       shm.c
 > U       tools/analyze-sockets.c
 > U       uid.c
 > Pull is not possible because you have unmerged files.
 > Please, fix them up in the work tree, and then use 'git add/rm <file>'
 > as appropriate to mark resolution and make a commit.
 > 
 > 
 > tfoerste@t44 ~/devel/trinity $ git diff
 > 
 > tfoerste@t44 ~/devel/trinity $ git status
 > On branch master
 > Your branch and 'origin/master' have diverged,
 > and have 3702 and 3711 different commits each, respectively.
 >   (use "git pull" to merge the remote branch into yours)
 > You have unmerged paths.
 >   (fix conflicts and run "git commit")

I wondered if anyone would notice this.
I edited history to fix up two broken commit dates.

Just reclone. Shouldn't happen again.

	Dave

Re: git issue

[Toralf Förster]

On 07/01/2015 04:21 PM, Dave Jones wrote:
> I wondered if anyone would notice this.

I use git snapshots of trinity to test here something with user mode linux and KVM.
Not as often as in the past but sometimes I just pull from your repo.

-- 
Toralf
pgp key: 7B1A 07F4 EC82 0F90 D4C2  8936 872A E508 0076 E94E

Git issue

[Halde, Faiz]

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 

Re: Git issue

[Jeff King]

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

Re: Git issue

[Junio C Hamano]

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.

Re: Git issue

[Philip Oakley]

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 

Re: Git issue

[Jeff King]

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

Re: Git issue

[Junio C Hamano]

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.

Re: Git issue

[Jacob Keller]

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