From: Pierre Habouzit <madcoder@debian.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Sixt <j.sixt@eudaptics.com>,
Keith Packard <keithp@keithp.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] HEAD, ORIG_HEAD and FETCH_HEAD are really special.
Date: Fri, 07 Sep 2007 23:04:33 +0200 [thread overview]
Message-ID: <20070907210433.GD23483@artemis.corp> (raw)
In-Reply-To: <7vabry43cg.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]
On Fri, Sep 07, 2007 at 08:39:43PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > I'd have added though that maybe update-ref should print a warning for
> > the references that do not match the restriction Junio added. This could
> > be done using the function Junio proposed un update_ref() in refs.c
>
> I would even suggest making it into an error, even if we do not
> error out on the reading side (being liberal when reading but
> more strict when creating, that is).
>
> That confused_ref() needs to be tightened further, by the way.
> It is called only when we are considering to tack the user
> string immediately below $GIT_DIR/ so the only valid cases are
> (1) the string begins with "refs/", or (2) the string is all
> uppercase (or underscore), especially without slash. The one in
> the proposed patch is not strict enough and does not enforce the
> former.
I reckon I didn't checked what the function did in detail, just the
code layout :) And I agree an error is event better, I just don't have
enough knowledge of the scripts that used refs in git for a long time
that such a change could break. I mean, I only use git since the 1.2
(maybe even 1.3) series :)
I'm always all for refusing dangerous layouts rather than trying too
hard to support cumbersome things that are 99% of the times issues :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-09-07 21:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-06 21:48 rebase from ambiguous ref discards changes Keith Packard
2007-09-06 22:37 ` Pierre Habouzit
2007-09-06 23:26 ` Junio C Hamano
2007-09-07 2:58 ` Keith Packard
2007-09-07 6:55 ` Pierre Habouzit
2007-09-07 11:21 ` [PATCH] HEAD, ORIG_HEAD and FETCH_HEAD are really special Junio C Hamano
2007-09-07 12:36 ` Johannes Sixt
2007-09-07 12:42 ` Pierre Habouzit
2007-09-07 20:39 ` Junio C Hamano
2007-09-07 21:04 ` Pierre Habouzit [this message]
2007-09-08 22:20 ` Alex Riesen
2007-09-07 16:03 ` Keith Packard
2007-09-07 16:08 ` Keith Packard
2007-09-07 16:29 ` Nicolas Pitre
2007-09-07 20:32 ` Junio C Hamano
2007-09-07 21:53 ` Carl Worth
2007-09-07 22:08 ` Junio C Hamano
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=20070907210433.GD23483@artemis.corp \
--to=madcoder@debian.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j.sixt@eudaptics.com \
--cc=keithp@keithp.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.