Re: autoCRLF, git status, git-gui, what is the desired behavior?

["Shawn O. Pearce" <spearce@spearce.org>]

Mark Levedahl <mdl123@verizon.net> wrote:
> Also, if I invoke git-gui on the above repository showing foo as modified...
> 
> 1) foo shows up in the "Changed But Not Updated" list.
> 2) Clicking on foo gives message box with "No differences detected. ...
>    Clicking the "ok" button invokes a rescan, back to step 1.
> 3) Adding foo to the commit list in git-gui works.
> 4) Committing the above from git-gui gives a commit with no
>    changes (commit is made, shows up in git log, but has no
>    changes associated).
> 
> --- I don't think git-gui should make create an empty commit in the 
> above case.

Hmm.  Probably not.  In pg I used to compare HEAD^{tree} to the
tree output by git-write-tree and refuse to make the commit if
they had the same value.  git-gui just blindly assumes that if a
file is staged for committing then it won't make an empty commit;
this is also the behavior in git-commit.sh.

Yet in the case of a merge you may want the same tree and not even
realize it.  Like if I merge a commit from a coworker, get a merge
conflict, pick my version, but that just modified the tree to match
mine, effectively doing an `-s ours` style merge.  Of course here
we have MERGE_HEAD and know we are merging...

-- 
Shawn.