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

Re: [PATCH] diff: resurrect the traditional empty "diff --git" behaviour

From
David Kastrup <dak@gnu.org>
Date
Aug 31, 2007, 21:20 UTC
Message-ID
<85lkbrbdv2.fsf@lola.goethe.zz>
In-Reply-To
<Pine.LNX.4.64.0708312154530.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 29 quoted lines
> On Fri, 31 Aug 2007, Jeff King wrote:
>
>> On Fri, Aug 31, 2007 at 01:13:42PM -0700, Junio C Hamano wrote:
>> 
>> > If you set diff.autorefreshindex configuration variable, it
>> > squelches the empty "diff --git" output, and at the end of the
>> > command, it automatically runs "update-index --refresh" without
>> > even bothering the user.  In other words, with the configuration
>> > variable set, people who do not care about the cache-dirtyness
>> > do not even have to see the warning.
>> 
>> Nice. This is much more sane behavior, IMHO, and I think it should make 
>> everyone happy.
>
> I could even imagine that this will eventually become the standard 
> behaviour.
>
>> >  Same here.  This patch saw only very light testing, but I
>> >  personally think is a sane thing to do before 1.5.3 final.
>> 
>> Passes my light testing as well, but I have a feeling we just tested the
>> same things...;)
>> 
>> One question on the implementation (and remember that I am somewhat
>> ignorant of the structure of this part of the code, so the answer may be
>> "it's too ugly"): is there a good reason to refresh _after_ the diff?
>
> We do not need to do it always.  After the diff, we know if the
> index needs refreshing.  Before, we don't.

Hm. At the moment where it is first noticed, it should be still possible to start a refresh. Is there a particular gain to be expected? One thing I could think of is that when using a pager, the diff might often die of SIGPIPE before being able to refresh.

Show 7 quoted lines
>> It seems like when we are looking through the working tree and
>> index the first time, we notice that the stat information doesn't
>> match; why can't we update it then? That would save an extra
>> working tree traversal.
>
> But that would be intrusive in the diff machinery IMHO.  It should
> stay as read-only as possible.
Hm.  Not sure where the gain is in that, if a refresh is done, anyway.
-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Previous: Johannes SchindelinNext: Alex Riesen
Message 21 of 26 in “parallel make problem with git”
  1. Michael S. TsirkinAug 30, 2007
  2. Junio C HamanoAug 30, 2007
  3. Michael S. TsirkinAug 30, 2007
  4. fix parallel make problemMichael S. Tsirkin, Aug 30, 2007
  5. Junio C HamanoAug 31, 2007
  6. Michael S. TsirkinAug 31, 2007
  7. Junio C HamanoAug 31, 2007
  8. Michael S. TsirkinAug 31, 2007
  9. Junio C HamanoAug 31, 2007
  10. Michael S. TsirkinAug 31, 2007
  11. Junio C HamanoAug 31, 2007
  12. Michael S. TsirkinAug 31, 2007
  13. Johannes SchindelinAug 31, 2007
  14. Junio C HamanoAug 31, 2007
  15. Jeff KingAug 31, 2007
  16. diff: resurrect the traditional empty "diff --git" behaviourJunio C Hamano, Aug 31, 2007
  17. Jeff KingAug 31, 2007
  18. Johannes SchindelinAug 31, 2007
  19. Junio C HamanoAug 31, 2007
  20. Johannes SchindelinAug 31, 2007
  21. David KastrupAug 31, 2007
  22. Alex RiesenAug 31, 2007
  23. Steven GrimmAug 31, 2007
  24. Junio C HamanoSep 1, 2007
  25. Matthieu MoySep 3, 2007
  26. Junio C HamanoSep 3, 2007

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.