From: Junio C Hamano <gitster@pobox.com>
To: "Stephen Cuppett" <cuppett@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC] Change handling of RelNotes
Date: Fri, 31 Aug 2007 13:25:46 -0700 [thread overview]
Message-ID: <7vhcmfzc1h.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <316a20a40708310552r3d445d03h2ab44508a0608f0c@mail.gmail.com> (Stephen Cuppett's message of "Fri, 31 Aug 2007 08:52:38 -0400")
"Stephen Cuppett" <cuppett@gmail.com> writes:
> Sorry, I didn't mean to imply a demand on anybody, or mandate anybody
> change their workflow...
I have to admit that your "I propose" phrase did raise my
eyebrow, but it's not a big deal. I've grown thicker skins ;-)
As a general principle, I agree it is a good idea to keep
git.git easily accessible by people on different platforms and
environments. After all, you would need to get git.git in order
to obtain newer repository features, so there is a chicken and
egg problem involved that is more severe than other projects.
That is exactly the reason why I do not use subprojects to bind
gitk and git-gui into git.git. It needs to wait until everybody
has 1.5.2 or newer --- otherwise peole cannot clone or fetch
from git.git to get the feature that allows such a fetch to
begin with.
It would have been a different issue if the build procedure
depended on having a tracked symlink foo.h pointing at cache.h
and some source file included foo.h. You cannot build such a
thing on a filesystem without symbolic links. But the RelNotes
symlink is there for people to easily find the notes for the
latest to be released, and that symlink appears as a text file
that records the name of the Documentation file in a checkout
with "core.symlinks = false"; I do not think it is such a big
show stopper, even for people on a filesystem without symbolic
links.
prev parent reply other threads:[~2007-08-31 20:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-31 1:35 [RFC] Change handling of RelNotes Stephen Cuppett
2007-08-31 1:39 ` Petr Baudis
2007-08-31 6:04 ` Junio C Hamano
2007-08-31 2:21 ` Junio C Hamano
2007-08-31 6:08 ` Marius Storm-Olsen
2007-08-31 6:44 ` Nanako Shiraishi
2007-08-31 7:09 ` Junio C Hamano
2007-08-31 7:22 ` [PATCH] autodetect core.symlinks in git-init Junio C Hamano
2007-08-31 8:00 ` Nanako Shiraishi
2007-08-31 8:23 ` Marius Storm-Olsen
[not found] ` <316a20a40708310539w1d20c391w8566a042c7a8679a@mail.gmail.com>
2007-08-31 12:52 ` [RFC] Change handling of RelNotes Stephen Cuppett
2007-08-31 20:25 ` Junio C Hamano [this message]
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=7vhcmfzc1h.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=cuppett@gmail.com \
--cc=git@vger.kernel.org \
/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).