Re: [PATCH/RFC] "Recursive Make considered harmful"

From: Junio C Hamano <junkio@cox.net>
Date: Jul 28, 2005, 16:38 UTC
Message-ID: <7vk6jac2cv.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <pan.2005.07.28.07.45.31.245357@smurf.noris.de>

Matthias Urlichs <smurf@smurf.noris.de> writes:

> However, I *would* segregate gitk into its own Debian package, because
> it requires wish et al., which would pull a large chunk of X11 stuff,
> which people may not want on their server.

While I agree gitk should not come as part of git package, this brings up a different issue.

Ideally, I'd want to see gitk packaged from its repository kernel.org:/pub/scm/gitk/git.git/ Paul Mackerras maintains, not from GIT one which _will_ lag behind.

We have a copy of gitk in git repository because Linus "merged" it as "the coolest merge ever" example. While I intend to keep updating from gitk repository from time to time only because I do not want to ship ancient version of it, I see a big problem down the road. What happens if someday Paul wanted to have a toplevel Makefile of his own, or if somebody sends him a patch to add debian/rules file to build a separate gitk package from its own source tree? Pulling/merging from gitk repo to update the copy git has suddenly becomes a nightmere.

While I _do_ rely on gitk in my git work, and I _do_ like its simplicity (just a single file right now), my longer term preference is to drop the copy we have in git tree and treat it just like the other repository browser, qgit. Our documentation should point people at it as part of the Porcelain suite.