Matthias Urlichs <[EMAIL PROTECTED]> 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 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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to