Re: git-diff on touched files: bug or feature?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Matthieu Moy <Matthieu.Moy@xxxxxxx> writes:

> $ touch bar
> $ git diff
> diff --git a/bar b/bar         <--- here ---<
> $ git status
> # On branch master
> nothing to commit (working directory clean)
> $ git diff                     <--- status updated
>                                     the stat in the index.
>
> Is this intended,

Yes.  Very much so, intentionally, from very early days of git.
This serves as a reminder to the user that he started editing
but changed his mind to end up with the same contents as the
original, until the next "update-index --refresh" (which is
internally invoked from "status").

If the feature still makes sense in the modern world is a
different story, but I do find it useful.

Not the made-up "touch" example, but often in real life, I
explore a solution by first making changes to one part of the
system, realizing a better way is to change the caller of what I
initially thought should be changed, edit the file back and
modify the caller which is in another file.  The former file
will show that empty "header-only" diff as the reminder of what
I did.

After that, when I reach the point to run "git status", because
I have been reminded, I already know about these "tried but
discarded" changes, and I find the fact that the they are forgot
by that operation very convenient.


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux