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

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

Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > 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...
> 
> git-commit has been raised with all of these logic during its
> evolution.  Is it a possibility to reuse it somehow?
 
Anything's possible.  ;-)

I'd rather not reuse git-commit in git-gui.  git-commit is strictly
porcelain-ish, while git-gui tries hard to only rely on the plumbing
layer[*1*], while also trying to autodetect and honor status data
used in the porcelain-ish (e.g. MERGE_HEAD, MERGE_MSG).

With the exception of this empty-commit case git-gui's commit
path is stable and doing the same actions as git-commit, only the
git-gui way.  I'd rather not churn that code just to avoid an empty
commit case.  Its easy enough to check the trees, and git-gui knows
if there are additional parents (and what those are) at the time of
commit, so its easy enough to not do the tree comparsion if there
is more than one parent.


I actually just found another way to make git-gui create an empty
commit.  I'm going to patch it to check the trees - because this
shouldn't be allowed.


*1*: With the exception of git-fetch, git-push, git-merge and
     git-repack.  The latter two of which I would like to get
	 rewritten in pure Tcl, as I want more control over what
	 is happening.
-- 
Shawn.