Re: Merge git-gui into 1.5.0 ?

[Junio C Hamano <junkio@cox.net>]

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