git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2] doc: make clear --assume-unchanged's user contract

From
Sérgio Basto <sergio@serjux.com>
Date
Dec 10, 2014, 01:49 UTC
Message-ID
<1418176152.8290.9.camel@segulix>
In-Reply-To
<xmqqoarcjpv3.fsf@gitster.dls.corp.google.com>
On Ter, 2014-12-09 at 16:44 -0800, Junio C Hamano wrote: 
Show 13 quoted lines
> Sérgio Basto <sergio@serjux.com> writes:
> 
> > Also don't understand why --assumed-untracked shouldn't deal with
> > changed files instead fallback in "the user promises not to change the
> > file" and sometimes works others not. 
> >
> > Also if this is the contract when a file is different from commit,
> > should warning the user that is not in contract (modify files that are
> > assumed-untracked ) 
> 
> Unfortunately, that is not even possible in the case where
> assume-untracked is meant to be used without breaking the use case
> it was invented to support. 

OK, but when we do: git --assumed-untracked <file> and file is already modified. we could do an warning .

May also should mention in documentation that --assumed-untracked is not to deal with "local versions of tracked config files in git" (if you don't)

Meanwhile I read https://gist.github.com/canton7/1423106 I adopt https://gist.github.com/canton7/1423106#if-you-cant-modify-your-application item 1

Thanks for your patience
Show 34 quoted lines
>  The user flips the bit so that Git does
> not have to traverse the working tree to run lstat(2) on all of them
> in order to see if some have changes relative to the index.
> 
> If we cannot trust that bit and need to verify, how would we do
> that?
> 
> Think.
> 
> Yes, by running lstat(2) on these files that the user promised not
> to touch.  That just defeats the sole objective the feature was
> invented for in the first place.
> 
> Having said all that, I know what you wish to have, and I am not
> fundamentally opposed to a change to add a new feature to order Git
> to pretend that changes that may exist in the working tree are not
> there. 
> It's just that assume-unchanged bit is not that.  It is a
> way to allow Git that it can assume the files in the working tree
> are not changed.  It is a permission, not a command.
> 
> This is a tangent, but somebody may want to check the "Git will fail
> (gracefully)" bit in the documentation Philip's documentation patch
> did not remove.  Such a detection is not absolutely necessary, and
> the paragraph may be describing a wishful thinking by somebody who
> misunderstood --assume-unchanged with a cursory observation of what
> happened for limited test cases back when the documentation was
> added, in which case that paragraph may also want to go.
> 
> 
> 
> 
> 
> 
-- 
Sérgio M. B.
Previous: Junio C Hamano
Message 11 of 11 in “Improve --assume-unchanged in the git update-index man page”
  1. Improve --assume-unchanged in the git update-index man pagePhilip Oakley, Dec 6, 2014
  2. doc: make clear --assume-unchanged's user contractPhilip Oakley, Dec 6, 2014
  3. Sérgio BastoDec 9, 2014
  4. Philip OakleyDec 9, 2014
  5. Philip OakleyDec 9, 2014
  6. Michael J GruberDec 9, 2014
  7. gitignore.txt: do not suggest assume-unchangedMichael J Gruber, Dec 9, 2014
  8. Jonathan NiederDec 10, 2014
  9. Michael J GruberDec 11, 2014
  10. Junio C HamanoDec 10, 2014
  11. Sérgio BastoDec 10, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.