All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: git@vger.kernel.org, Samuel Tardieu <sam@rfc1149.net>
Subject: Re: [PATCH] Permit refspec source side to parse as a sha1
Date: Thu, 20 Mar 2008 23:26:49 -0700	[thread overview]
Message-ID: <7v3aqksic6.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.LNX.1.00.0803210134070.19665@iabervon.org> (Daniel Barkalow's message of "Fri, 21 Mar 2008 01:57:52 -0400 (EDT)")

Daniel Barkalow <barkalow@iabervon.org> writes:

> On Thu, 20 Mar 2008, Junio C Hamano wrote:
> ...
>> In any case, don't you agree that the patch you responded to is much
>> easier to understand what we are (and we are not) checking than the
>> original code?
>
> No, I think it's much more complicated. It mixes the semantics of what an 
> empty side means for a particular use of refspecs into the parsing of the 
> string. At the very least, the checks should be outside of _internal() in 
> the functions for particular uses.

The thing is, the syntax is the same between fetch and push only to a
degree.  They are both <LHS> ':' <RHS>.  What is allowed on LHS and RHS
are quite different even at the syntactic level.

I already know our criteria when judging if a particular code is clean or
complex are _vastly_ different, from the experience working with you in
other parts of the system (namely, read-tree 3-way rules and
unpack_trees() rewrite that happened quite a long time ago).

While I would note that you thought my version is more complex to read, I
would not argue about this issue with you anymore, except saying that I
strongly disagree.

  reply	other threads:[~2008-03-21  6:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-21  0:54 [PATCH] Permit refspec source side to parse as a sha1 Daniel Barkalow
2008-03-21  4:10 ` Junio C Hamano
2008-03-21  4:50   ` Junio C Hamano
2008-03-21  5:09   ` Daniel Barkalow
2008-03-21  5:30     ` Junio C Hamano
2008-03-21  5:57       ` Daniel Barkalow
2008-03-21  6:26         ` Junio C Hamano [this message]
2008-03-21 16:08           ` Daniel Barkalow
2008-03-21 22:17             ` [PATCH] remote.c: Fix overtight refspec validation Junio C Hamano
2008-03-21 23:12               ` Daniel Barkalow
2008-03-21 23:59                 ` Junio C Hamano
2008-03-22  0:36                   ` Daniel Barkalow
2008-03-22 19:48                     ` Junio C Hamano
2008-03-22 20:45                       ` Daniel Barkalow
2008-03-26  1:45               ` Linus Torvalds
2008-03-26  3:31                 ` Junio C Hamano
2008-03-26  4:11                   ` Junio C Hamano
2008-03-26  5:42                     ` Daniel Barkalow
2008-03-26  5:46                       ` Junio C Hamano
2008-03-26  6:22                         ` Jeff King

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=7v3aqksic6.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=sam@rfc1149.net \
    /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.