From: "Josh England" <jjengla@sandia.gov>
To: "Linus Torvalds" <torvalds@linux-foundation.org>
Cc: git@vger.kernel.org
Subject: tracking perms/ownership [was: empty directories]
Date: Thu, 23 Aug 2007 15:51:19 -0600 [thread overview]
Message-ID: <1187905879.5986.199.camel@beauty> (raw)
In-Reply-To: <alpine.LFD.0.999.0708221618510.30176@woody.linux-foundation.org>
On Wed, 2007-08-22 at 16:25 -0700, Linus Torvalds wrote:
> But if .gitattributes would work, you probably could introduce both full
> permissions and ownership rules there. We read git attributes for *other*
> reasons when checking files out _anyway_, ie we need the CRLF attribute
> stuff, so adding ownership attributes would not be at all odd.
So here's the initial thought. Create two new gitattributes, 'perms'
and 'ownership', which will track perms/ownership for files matching the
given pattern.
Looking at the index struct, it already has fields in it for file mode
uid and gid (woohoo!). It looks like an addition to
builtin-update-index.c could set those fields (if the gitattribute is
set) the same way as how the execute bit is flipped with chmod_path().
I haven't found where the chmod is done at checkout/clone time, but the
question is: If the mode, uid, and gid are stuffed in the index, will
git diff simply just work to recognize permission/ownership changes? Is
this the right approach? What kind of merging issues will need to be
worried about?
-JE
next prev parent reply other threads:[~2007-08-23 21:50 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-21 17:14 empty directories Josh England
2007-08-21 17:40 ` Sean
2007-08-22 21:25 ` Josh England
2007-08-22 23:25 ` Linus Torvalds
2007-08-22 23:55 ` David Kastrup
2007-08-23 15:24 ` Josh England
2007-08-23 21:51 ` Josh England [this message]
2007-08-23 22:08 ` tracking perms/ownership Junio C Hamano
2007-08-23 23:30 ` Linus Torvalds
2007-08-24 6:16 ` David Kastrup
2007-08-24 6:37 ` Linus Torvalds
2007-08-24 7:38 ` Josh England
2007-08-24 7:50 ` David Kastrup
2007-08-24 17:51 ` Linus Torvalds
2007-08-24 18:15 ` Josh England
2007-08-24 18:23 ` Linus Torvalds
2007-08-24 18:56 ` Josh England
2007-08-24 20:37 ` Junio C Hamano
2007-08-24 21:26 ` Josh England
2007-08-24 19:33 ` Robin Rosenberg
2007-08-24 21:30 ` David Kastrup
2007-08-24 7:22 ` Josh England
2007-08-24 7:39 ` Junio C Hamano
2007-08-24 8:19 ` Josh England
2007-08-24 16:11 ` Josh England
2007-08-24 16:27 ` Josh England
2007-08-24 9:38 ` tracking perms/ownership [was: empty directories] Johannes Schindelin
2007-08-24 9:52 ` Jeff King
2007-08-24 15:50 ` Josh England
2007-08-24 20:58 ` Jeff King
2007-08-25 14:31 ` Johannes Schindelin
2007-08-25 14:46 ` tracking perms/ownership Junio C Hamano
2007-08-25 19:35 ` Junio C Hamano
2007-08-24 10:05 ` tracking perms/ownership [was: empty directories] Jeff King
2007-08-25 14:30 ` Johannes Schindelin
2007-08-24 17:10 ` empty directories Jason Garber
2007-08-22 23:40 ` Jakub Narebski
2007-08-22 0:06 ` Jakub Narebski
2007-08-22 4:31 ` Salikh Zakirov
2007-08-22 18:46 ` Linus Torvalds
2007-08-22 19:12 ` David Kastrup
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=1187905879.5986.199.camel@beauty \
--to=jjengla@sandia.gov \
--cc=git@vger.kernel.org \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox