"Shawn O. Pearce" <spearce@xxxxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html