Discussion:
git-diff new files (without using index)
Miles Bader
2007-08-05 03:42:02 UTC
Permalink
One thing I often want to do is generate a complete diff of all changes,
including new/removed files.

If I add things to the index, I can use "git-diff --cached" to do it;
however I'd actually like to be able to do this _without_ updating the
index; in other words, any un-added new file as a change. As it is, the
"non-indexed" state seems kind of a second-class citizen, as you can
never have new files there (or rather, git will never really see them).

Is there anyway to do this currently? If not, maybe something like a
"git-diff -N" (mirroring diff's -N/--new-file option) option could be
added to do this?

Thanks,

-Miles
--
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.
Shawn O. Pearce
2007-08-05 03:52:45 UTC
Permalink
Post by Miles Bader
One thing I often want to do is generate a complete diff of all changes,
including new/removed files.
If I add things to the index, I can use "git-diff --cached" to do it;
however I'd actually like to be able to do this _without_ updating the
index; in other words, any un-added new file as a change. As it is, the
"non-indexed" state seems kind of a second-class citizen, as you can
never have new files there (or rather, git will never really see them).
Use a temporary index:

(export GIT_INDEX_FILE=.git/tempindex;
cp .git/index $GIT_INDEX_FILE;
git add new-file;
git add other-new-file;
git diff --cached)

We pull this trick sometimes in internal tools, when we want to
produce some result but aren't sure we want to keep the resulting
index, or really know we don't want to keep the resulting index.

Another option is to just add everything, then reset the index:

git add new-file
git add other-new-file
git diff --cached
git reset

Granted if you had other files staged they just became unstaged
and will need to be restaged... the temporary index trick above
avoids that.
--
Shawn.
Miles Bader
2007-08-05 04:00:24 UTC
Permalink
Post by Shawn O. Pearce
Post by Miles Bader
If I add things to the index, I can use "git-diff --cached" to do it;
however I'd actually like to be able to do this _without_ updating the
index
...
...
Post by Shawn O. Pearce
Granted if you had other files staged they just became unstaged
and will need to be restaged... the temporary index trick above
avoids that.
Thanks for the tip (I guess I can roll my own "git-diff-uncached"
script)!

The above sort of quirkiness does seem kind of a wart though; in my
(admittedly limited, using git) experience this sort of thing really
reduces the utility of the index, and I often end up feeling like it's
just getting in the way as a result. Does adding something like a
"git-diff -N" option seem a _bad_ idea?

Thanks,

-Miles
--
"Suppose He doesn't give a shit? Suppose there is a God but He
just doesn't give a shit?" [George Carlin]
Shawn O. Pearce
2007-08-05 04:08:41 UTC
Permalink
Post by Miles Bader
Thanks for the tip (I guess I can roll my own "git-diff-uncached"
script)!
Indeed, Git is quite scriptable. ;-)
Post by Miles Bader
The above sort of quirkiness does seem kind of a wart though; in my
(admittedly limited, using git) experience this sort of thing really
reduces the utility of the index, and I often end up feeling like it's
just getting in the way as a result. Does adding something like a
"git-diff -N" option seem a _bad_ idea?
I'm not interested in such an option. Typically if I want a
diff on a new untracked file I actually want that file in my next
commit anyway. So I'm usually staging it into the index along with
everything else that I have modified. In which case this quirkiness
isn't really a quirk at all. Its just not an issue to me.

If you want to try adding it, go right ahead. The source for git
is stored in git and available from many places. :-)
--
Shawn.
Junio C Hamano
2007-08-05 04:20:43 UTC
Permalink
Post by Shawn O. Pearce
Post by Miles Bader
The above sort of quirkiness does seem kind of a wart though; in my
(admittedly limited, using git) experience this sort of thing really
reduces the utility of the index, and I often end up feeling like it's
just getting in the way as a result. Does adding something like a
"git-diff -N" option seem a _bad_ idea?
I'm not interested in such an option. Typically if I want a
diff on a new untracked file I actually want that file in my next
commit anyway.
I suspect that it's probably half superstition and half disease
to wish for "diff /dev/null new-file". Even CVS got this one
right by saying "is a new file, no diff available". The
contents of that new file is available in "less new-file" near
you anyway and it is quite pointless while you are working
toward next commit. It just is not interesting, until you tell
git you _care_ about that file. And the way you tell git about
it is with "git add".

Learn to love the index, run "git-add" and view "git-diff HEAD".
Miles Bader
2007-08-05 04:37:19 UTC
Permalink
Post by Junio C Hamano
I suspect that it's probably half superstition and half disease
to wish for "diff /dev/null new-file".
Er, please, a bit of consideration. It's not superstition, it's not a disease.

I _want to use the index_: I want to stage changes, and then make more
changes, and just generally be able to treat these three states (HEAD,
indexed, non-indexed) as points which can be used as inputs to git-diff
-- and I want _applyable patch files_ as the output from git-diff, not
pretty diffs for browsing.

Thanks,

-Miles
--
Any man who is a triangle, has thee right, when in Cartesian Space, to
have angles, which when summed, come to know more, nor no less, than
nine score degrees, should he so wish. [TEMPLE OV THEE LEMUR]
Loading...