git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Brodie Rao" <brodie@sf.io>,
	"René Scharfe" <rene.scharfe@lsrfire.ath.cx>,
	"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] archive: fix archive generation for empty trees
Date: Wed, 07 Mar 2012 22:38:07 -0800	[thread overview]
Message-ID: <7vpqcnfvhs.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20120308055520.GB7643@sigill.intra.peff.net> (Jeff King's message of "Thu, 8 Mar 2012 00:55:20 -0500")

Jeff King <peff@peff.net> writes:

>> Now, instead of "", we use a pathspec prefix of NULL. If no path
>> arguments were provided, get_pathspec() will return NULL, and we won't
>> try to verify the existence of any paths in the tree.
>
> Yeah, this looks like the right thing to do. The get_pathspec code
> treats a NULL prefix specially as "no prefix", and I think that is what
> we are trying to say here (i.e., we are interpreting pathspecs from the
> root).

Yes, that sounds sane.

> ... However, prefix_pathspec does a lot of magic parsing;
> it's unclear to me whether this is all in support of properly
> adding the prefix, or if its side effects are important.

These "magic" are for things like :(root)/path that will explicitly
refuse the prefix when run from a subdirectory.

In the longer term, get_pathspec() should be converted to directly
deal with "struct pathspec", but we are not there yet.  There are
too many code left-over, even after Duy's last pathspec related
topic, that still look at ->raw field of "struct pathspec" and they
all need to be taught to work with the unified pathspec matching
machinery.  This is one of the lots of unfinished loose ends, which
might be a good GSoC project but may be a bit too large for a
student to bite and chew.

  reply	other threads:[~2012-03-08  6:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-08  0:09 [PATCH] archive: fix archive generation for empty trees Brodie Rao
2012-03-08  5:55 ` Jeff King
2012-03-08  6:38   ` Junio C Hamano [this message]
2012-03-08  7:15     ` Jeff King
2012-03-08 17:46       ` René Scharfe
2012-03-09  0:06       ` Brodie Rao
2012-03-09  7:30         ` René Scharfe
2012-03-08 17:46 ` René Scharfe
2012-03-09  0:08   ` Brodie Rao

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vpqcnfvhs.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=brodie@sf.io \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    --cc=rene.scharfe@lsrfire.ath.cx \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).