git-gui: Don't create empty (same tree as parent) commits.

Mark Levedahl noticed that git-gui will let you create an empty
normal (non-merge) commit if the file state in the index is out
of whack.  The case Mark was looking at was with the new autoCRLF
feature in git enabled and is actually somewhat difficult to create.

I found a different way to create an empty commit:  turn on the
Trust File Modifications flag, touch a file, rescan, then move
the file into the "Changes To Be Committed" list without looking
at the file's diff.  This makes git-gui think there are files
staged for commit, yet the update-index call did nothing other
than refresh the stat information for the affected file.  In
this case git-gui allowed the user to make a commit that did
not actually change anything in the repository.

Creating empty commits is usually a pointless operation; rarely
does it record useful information.  More often than not an empty
commit is actually an indication that the user did not properly
update their index prior to commit.  We should help the user out
by detecting this possible mistake and guiding them through it,
rather than blindly recording it.

After we get the new tree name back from write-tree we compare
it to the parent commit's tree; if they are the same string and
this is a normal (non-merge, non-amend) commit then something
fishy is going on.  The user is making an empty commit, but they
most likely don't want to do that.  We now pop an informational
dialog and start a rescan, aborting the commit.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

0 files changed, 0 insertions, 0 deletions