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

Matthias Urlichs [off-list ref] 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.

Junio C Hamano wrote:
...

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.

...

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.

Then this should happen sooner rather than later.