Re: Merge git-gui into 1.5.0 ?

From: Junio C Hamano <junkio@cox.net>
Date: Feb 11, 2007, 22:27 UTC
Message-ID: <7vwt2oba8s.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070211084030.GE2082@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

> One of my goals for git-gui is to get it merged into core Git, so
> there is a GUI tool available out-of-the-box for commit creation,
> (some) branch manipulation, basic merging, and pushing/fetching
> changes.

I do not have objection per-se, but I have two choices on the procedure, and I hate having choices this close to the final release ;-).

(1) I can do the usual 'no common ancestor' merge, and treat it
    just like gitk.  I would probably place git-gui as a
    subdirectory in git.git (just like I did to gitweb/), and
    tweak the main Makefile to chdir down to git-gui, and let
    the git-gui/Makefile (the toplevel Makefile from your point
    of view) do its work.  Your current git-gui repository that
    does not have rest of git.git will _remain_ git-less.  In
    addition, git-gui repository remains to be the authoritative
    place its improvements take place.  git.git pull from there
    from time to time to get updates.

(2) After the 'no common ancestor' merge above, you fast forward
    git-gui to git.git and two repositories can cross pull from
    each other from that point on.

I have a suspicion that doing the former may turn out to be a good demonstration that git supports subprojects already. The toplevel project _knows_ about subproject, but the subproject does not have to be aware of the toplevel project. Granted, the toplevel project knows which specific version of the subproject is bound to each of its commit, which is tighter integration than what usually is desired, but still it is a form of subproject support that may be useful.

I was actually hoping I can do so with Kay, but from his point of view merging gitweb to git.git was so that he does not have to worry about it anymore, so it did not work well.