Browse Source
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>maint gitgui-0.6.2
Shawn O. Pearce
18 years ago
1 changed files with 18 additions and 0 deletions
Loading…
Reference in new issue