All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David A. Wheeler" <dwheeler@dwheeler.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Junio C Hamano <junkio@cox.net>,
	Linus Torvalds <torvalds@osdl.org>, Andreas Gal <gal@uci.edu>,
	Kay Sievers <kay.sievers@vrfy.org>,
	git@vger.kernel.org
Subject: Re: git and symlinks as tracked content
Date: Wed, 04 May 2005 11:48:22 -0400	[thread overview]
Message-ID: <4278EEC6.2090607@dwheeler.com> (raw)
In-Reply-To: <42780185.7010204@zytor.com>

Linus Torvalds wrote:
 >Also, right now git will actually ignore most of the permission bits 
too.  
 >We can change that, and make it a dynamic setting somewhere (some flag in
 >a ".git/settings" file or something), but it does boil down to the fact
 >that a software development tree tracker wants different things than
 >something that tracks system settings.
...
 >So if you want to track system files, right now "raw git" is _not_ the 
way
 >to do it. You'd want something else.
...
 >But if you'd want to track other system directories with git, you'd
 >probably need to either (a) do serious surgery on git itself, or (probably
 >preferable) by (b) track the extra things you want "manually" using a file
 >(that is tracked in git) that describes the ownership and permission data.
 >
 >Whether git is really suitable for tracking non-source projects is
 >obviously debatable. It's not what it was designed for, and it _may_ be
 >able to do so partly just by luck.

I suspect there's a 95% point which is easily achieved, &
beyond that it's not clear it's worth it.

I recall seeing several source code directories that actually use symlinks
in their source, and thus would want them preserved by the SCM.
(Not arguing that's the BEST plan, merely an observation).
As this discussion has noted, that wouldn't be hard to add symlink
support to git, and WOULD be helpful for its primary purpose as SCM support.

Once you're there, it wouldn't be hard to add logic to add options to
(1) record the REAL permission bits, (2) record "." files, and
(3) recover the permission bits.  That would be enough to
store & recover in a distributed way a single person's home directory.
THAT might be darn useful, for those of us who float between
different systems & would like to use a single system for multiple purposes.
That's clearly beyond the scope of a typical SCM, but since
it's easy to get there, that'd make sense.

I'm ambivalent about supporting dev, uid/gid, and mtime, and how
it should be done; that may be beyond the "worth it" step.

--- David A. Wheeler


  parent reply	other threads:[~2005-05-04 15:42 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-03 18:33 git and symlinks as tracked content Kay Sievers
2005-05-03 19:02 ` Linus Torvalds
2005-05-03 19:10   ` Morten Welinder
2005-05-03 19:50   ` H. Peter Anvin
2005-05-03 19:57   ` Andreas Gal
2005-05-03 20:05     ` Linus Torvalds
2005-05-03 20:09       ` Kay Sievers
2005-05-03 21:30       ` Junio C Hamano
2005-05-03 21:51         ` Andreas Gal
2005-05-03 22:44           ` Junio C Hamano
2005-05-04  0:39             ` Sym-links, b/c-special files, pipes, ... Scope Creep Brian O'Mahoney
2005-05-03 22:56         ` git and symlinks as tracked content H. Peter Anvin
2005-05-03 23:16           ` Junio C Hamano
2005-05-03 23:18             ` H. Peter Anvin
2005-05-03 23:42               ` Linus Torvalds
2005-05-03 23:42               ` Junio C Hamano
2005-05-04 15:48           ` David A. Wheeler [this message]
2005-05-04 23:03             ` Daniel Barkalow
2005-05-05  6:09               ` Alan Chandler
2005-05-05  9:51                 ` read-only git repositories David Lang
2005-05-05 12:39                   ` Sean
2005-05-06  3:01                   ` read-only git repositories (ancient history) David A. Wheeler
2005-05-05 21:23                 ` git and symlinks as tracked content Daniel Barkalow
2005-05-03 20:23   ` Junio C Hamano
2005-05-04 22:35   ` Kay Sievers
2005-05-04 23:16     ` Junio C Hamano
2005-05-05  1:20       ` Kay Sievers
2005-05-05  2:13         ` Junio C Hamano
2005-05-05 12:38           ` Kay Sievers

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=4278EEC6.2090607@dwheeler.com \
    --to=dwheeler@dwheeler.com \
    --cc=gal@uci.edu \
    --cc=git@vger.kernel.org \
    --cc=hpa@zytor.com \
    --cc=junkio@cox.net \
    --cc=kay.sievers@vrfy.org \
    --cc=torvalds@osdl.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.