From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: .git/info/attributes not cloned Date: Thu, 27 Mar 2008 00:29:25 -0400 Message-ID: <20080327042925.GA6426@coredump.intra.peff.net> References: <47EB0FAE.5000102@rea-group.com> <20080327033341.GB5417@coredump.intra.peff.net> <47EB213F.1020503@rea-group.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: git@vger.kernel.org To: Toby Corkindale X-From: git-owner@vger.kernel.org Thu Mar 27 05:30:12 2008 Return-path: Envelope-to: gcvg-git-2@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1Jejkh-0002EU-AE for gcvg-git-2@gmane.org; Thu, 27 Mar 2008 05:30:11 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751063AbYC0E32 (ORCPT ); Thu, 27 Mar 2008 00:29:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751146AbYC0E32 (ORCPT ); Thu, 27 Mar 2008 00:29:28 -0400 Received: from 66-23-211-5.clients.speedfactory.net ([66.23.211.5]:1033 "EHLO peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750893AbYC0E32 (ORCPT ); Thu, 27 Mar 2008 00:29:28 -0400 Received: (qmail 4268 invoked by uid 111); 27 Mar 2008 04:29:26 -0000 Received: from coredump.intra.peff.net (HELO coredump.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.32) with SMTP; Thu, 27 Mar 2008 00:29:26 -0400 Received: by coredump.intra.peff.net (sSMTP sendmail emulation); Thu, 27 Mar 2008 00:29:25 -0400 Content-Disposition: inline In-Reply-To: <47EB213F.1020503@rea-group.com> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Thu, Mar 27, 2008 at 03:23:27PM +1100, Toby Corkindale wrote: > Ah, OK. > I was hoping not to use .gitattributes, as then the attributes are > ignored when doing something like: > git archive --remote=example.com:/path/to/repo release/v2.1 | tar xf - I vaguely recall some discussion of this in the past, so maybe it isn't a good idea. But I would think changing git-archive to respect .gitattributes might be worth doing (presumably the version of .gitattributes from the tree that is being exported). > That gives a clue that the /info/ files are repo-specific. > However in gitignore(5) and gitattributes(5), there is no explanation of > this - it simply mentions that the info version is a higher priority than > the .git{ignore,attributes} version. > > I suggest that the individual docs/man-pages should mention that too. > I'll submit a patch in a separate email, as long as I'm not still > misunderstanding the mechanism. I think you understand what is going on. A clarification to both pages would be helpful, I think, just saying "here is why you might use one over the other." > Is there a recommended way to make attributes apply to commands run on a > remote repository, or is that a different bug? I'm not sure what you mean here. Very few commands talk to remote repositories. I had assumed in your git-archive example that you wanted .gitattributes on the remote repo to affect the tarfile generated by that repo. But now it sounds like you want to edit a local file to impact the archive generated remotely. I don't think there is a way to do that. -Peff