All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Greaves <david@dgreaves.com>
To: "C. Scott Ananian" <cscott@cscott.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Some documentation...
Date: Wed, 20 Apr 2005 18:35:13 +0100	[thread overview]
Message-ID: <426692D1.20304@dgreaves.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0504201321380.2630@cag.csail.mit.edu>

C. Scott Ananian wrote:
> On Wed, 20 Apr 2005, David Greaves wrote:
> 
>> In doing this I noticed a couple of points:
>> * update-cache won't accept ./file or fred/./file
> 
> 
> The comment in update-cache.c reads:
> /*
>  * We fundamentally don't like some paths: we don't want
>  * dot or dot-dot anywhere, and in fact, we don't even want
>  * any other dot-files (.git or anything else). They
>  * are hidden, for chist sake.
>  *
>  * Also, we don't want double slashes or slashes at the
>  * end that can make pathnames ambiguous.
>  */
> 
> It could be argued that './' is a special case... but at the moment this 
> is definitely a designed 'feature' not a 'bug'.

Indeed - I've been reading the code to document it as correctly as possible.

But I actually found this by running:

   find . -type f | xargs git add

for a new project - so I'd class it as user unfriendly...
Yes, I know how to get round it :)

I have ensured that my next perl version of gitadd.pl (that I submitted 
to Petr) doesn't allow these files to be added - and it could even 
cleanse leading ./ and any /./ constructs.

So maybe it's left as documented behaviour and higher level tools must 
manage the data they feed to it...

I hope it's useful to raise these niggles now before changing them is 
too hard.

David

-- 

  reply	other threads:[~2005-04-20 17:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-20 17:08 [PATCH] Some documentation David Greaves
2005-04-20 17:24 ` C. Scott Ananian
2005-04-20 17:35   ` David Greaves [this message]
2005-04-20 20:15     ` Linus Torvalds

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=426692D1.20304@dgreaves.com \
    --to=david@dgreaves.com \
    --cc=cscott@cscott.net \
    --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 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.