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

From: Shawn O. Pearce <spearce@spearce.org>
Date: Feb 26, 2007, 15:54 UTC
Message-ID: <20070226155442.GA1639@spearce.org>
In-Reply-To: <7v649pr60q.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> wrote:

Show 13 quoted lines

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