From: "Shawn O. Pearce" <spearce@spearce.org>
To: Eygene Ryabinkin <rea-git@codelabs.ru>
Cc: git@vger.kernel.org
Subject: Re: [CORRECTED PATCH] Introduce file with the common default build-time items.
Date: Thu, 14 Jun 2007 23:22:04 -0400 [thread overview]
Message-ID: <20070615032204.GC18491@spearce.org> (raw)
In-Reply-To: <20070614190739.GA3779@void.codelabs.ru>
Eygene Ryabinkin <rea-git@codelabs.ru> wrote:
> Thu, Jun 14, 2007 at 11:09:29AM -0400, Shawn O. Pearce wrote:
> > Eygene Ryabinkin <rea-git@codelabs.ru> wrote:
> > No, because Junio has already stated a desire to remove git-gui.git
> > from git.git and convert it to a proper subproject by the time of
> > Git 1.6. That means the git-gui/ subdirectory will become optional,
> > though I imagine most git-gui users will still have it. But not
> > all Git users are git-gui users. ;-)
>
> OK, it means that git-gui will be totally separated from the
> git.git? And one will download it as the separate tarball?
That's one option. But Junio and I are also considering keeping
it inside the git tarball as well, as many users have gotten used
to it being in the core Git distribution. I think it all depends
on if myself (or someone else) adds subproject recursion support
into git-archive. ;-)
No subproject recusion in git-archive will probably mean git-gui
would get dropped from the core git tarball. Given we're talking
about 1.6 timeframe I think we might be able to get that feature
working by then.
> > The best we can do is let the user pick their TCL_PATH and
> > TCLTK_PATH up in git's own Makefile, and have it pass down into
> > git-gui's Makefile when git-gui is being built from within git.
> > That is the arrangement we currently have.
>
> OK, fine, thanks for the explanations. The corrected patch follows.
...
> Makefile | 17 +++++++++++------
> common-make-vars.def | 11 +++++++++++
> configure.ac | 4 +++-
> 3 files changed, 25 insertions(+), 7 deletions(-)
> create mode 100644 common-make-vars.def
...
I dunno. 25 insertions and 7 deletions to reduce two uses of 'wish'
into one use of 'wish'? That hardly seems worth the additional
18 lines of code. Feels like code churn to me. And I rarely feel
code churn. I'm usually a lot more caviler about changing things
than Junio, Dscho, Nico, Linus, ...
--
Shawn.
next prev parent reply other threads:[~2007-06-15 3:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-13 5:43 [PATCH] Introduce file with the common default build-time items Eygene Ryabinkin
2007-06-14 4:36 ` Shawn O. Pearce
2007-06-14 9:56 ` Eygene Ryabinkin
2007-06-14 15:09 ` Shawn O. Pearce
2007-06-14 19:07 ` [CORRECTED PATCH] " Eygene Ryabinkin
2007-06-15 3:22 ` Shawn O. Pearce [this message]
2007-06-15 5:40 ` Eygene Ryabinkin
2007-06-15 5:58 ` Shawn O. Pearce
2007-06-15 6:07 ` Eygene Ryabinkin
2007-06-15 7:15 ` Johannes Sixt
2007-06-15 10:28 ` Eygene Ryabinkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070615032204.GC18491@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=rea-git@codelabs.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).