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

From: Shawn O. Pearce <spearce@spearce.org>
Date: Feb 26, 2007, 02:06 UTC
Message-ID: <20070226020657.GA1884@spearce.org>
In-Reply-To: <45E1F6B5.8030907@verizon.net>

Mark Levedahl <mdl123@verizon.net> wrote:

Show 12 quoted lines

> 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.