Junio C Hamano <junkio@xxxxxxx> wrote: > 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 ;-). ... > 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. I'm OK with either approach here. Originally I had intended to wipe out everything except git-gui.sh, then do an ancestor-less merge into git.git's top level directory, and finally tweak git.git's master Makefile to add git-gui.sh to the list of known shell scripts. Then I was going to ask you to pull that resulting tree. But it may make a *lot* more sense to treat is a true subproject in its own directory. Unlike Kay, I'm not looking to merge git-gui into git.git to abandon it. I just think we should offer a GUI out of the box, git-gui has the same dependencies as gitk, and I happen to like git-gui. ;-) git-gui development is going to continue past 1.5.0's release. There are still a lot of operations it should support that it currently does not do, and there are certainly user interface improvements that can still be made. It may be saner for all involved if that development happens in the git-gui.git repository, with drops made to git.git by way of merging the "subproject" every so often. It may make patching slightly more interesting though, as some users new to git-gui development may generate a patch in git.git (using a/git-gui/git-gui.sh as the path) which then would not apply as-is to the master git-gui development tree. Entirely your call Junio. -- Shawn. - 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