git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Sérgio Basto" <sergio@serjux.com>
Cc: Philip Oakley <philipoakley@iee.org>,
	GitList <git@vger.kernel.org>, Duy Nguyen <pclouds@gmail.com>,
	Johannes Sixt <j6t@kdbg.org>
Subject: Re: [PATCH v2] doc: make clear --assume-unchanged's user contract
Date: Tue, 09 Dec 2014 16:44:00 -0800	[thread overview]
Message-ID: <xmqqoarcjpv3.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1418096636.19104.31.camel@segulix> ("Sérgio Basto"'s message of "Tue, 09 Dec 2014 03:43:56 +0000")

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

  parent reply	other threads:[~2014-12-10  0:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-06 15:04 [PATCH v2] Improve --assume-unchanged in the git update-index man page Philip Oakley
2014-12-06 15:04 ` [PATCH v2] doc: make clear --assume-unchanged's user contract Philip Oakley
2014-12-09  3:43   ` Sérgio Basto
2014-12-09  7:59     ` Philip Oakley
2014-12-09  8:13       ` Philip Oakley
2014-12-09  8:30     ` Michael J Gruber
2014-12-09 11:13       ` [PATCH] gitignore.txt: do not suggest assume-unchanged Michael J Gruber
2014-12-10  1:06         ` Jonathan Nieder
2014-12-11 15:13           ` Michael J Gruber
2014-12-10  0:44     ` Junio C Hamano [this message]
2014-12-10  1:49       ` [PATCH v2] doc: make clear --assume-unchanged's user contract Sérgio Basto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqoarcjpv3.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=pclouds@gmail.com \
    --cc=philipoakley@iee.org \
    --cc=sergio@serjux.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).