git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Kay Sievers <kay.sievers@vrfy.org>, git@vger.kernel.org
Subject: Re: git and symlinks as tracked content
Date: Tue, 03 May 2005 13:23:51 -0700	[thread overview]
Message-ID: <7vy8awt5wo.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.58.0505031151240.26698@ppc970.osdl.org> (Linus Torvalds's message of "Tue, 3 May 2005 12:02:33 -0700 (PDT)")

>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:

LT> On Tue, 3 May 2005, Kay Sievers wrote:
>> Where can we store the link-target? In its own blob-object or directly
>> in the tree-object?

LT>  - directories: S_IFDIR (0040000) point to "tree" objects for contents
LT>  - symlinks: S_IFLNK (0120000) point to "blob" objects
LT>  - executables: S_IFREG | 0755 (0100755) point to "blob" objects
LT>  - regular files: S_IFREG | 0644 (0100644) point to "blob" objects

These and the device nodes you mention would work naturally on
the cache side and I generally like this idea.  You need to
update checkout-cache to (attempt to) create the right kind of
file, but that is about it.

On the diff side, things are a bit more interesting.  Both the
git-diff-tree-helper engine (diff.c) and git-apply-patch-script
need to be told about these new types of objects, or at least
tightened up to ignore them until they know how to support them.

LT> When you think of it that way, the "patch" ends up falling out very 
LT> naturally, I think. It would look like

LT> 	New file: filename (Mode: 0120000)
LT> 	--- /dev/null
LT> 	+++ filename
LT> 	@@ 0,0 1,1
LT> 	+symlink-value

LT> (or something, you get the idea).

I've always wanted to have this from the normal "diff -r"
output, but we have to be careful.  You do not want to
accidentally feed the normal patch that kind of output.  How
about doing something like this?

GIT: filename (mode:120000)
 --- /dev/null
 +++ filename
 @@ -0,0 +1 @@
 +symlink-value

GIT: filename (mode:120000)
 --- filename
 +++ /dev/null
 @@ -1 +0,0 @@
 -symlink-value

GIT: filename (mode:120000->120000)
 --- filename
 +++ filename
 @@ -1 +1 @@
 -old-symlink-value
 +new-symlink-value

That is, to indent them to keep patch from noticing them [*1*].

About the device nodes, the diffed contents would be major and
minor in decimal notation, and the real filesystem permission
bits and ownerships (e.g. changing /dev/audio from 0600 to 0660
or from root:root to root:audio).  I do not know if we would
want owner/group in symbolic or numeric yet.

GIT: filename (mode:0020000->0020000)
 --- dev/audio
 +++ dev/audio
 @@ -1,5 +1,5 @@
  major=14
  minor=4
  owner=root
 -group=root
 -perm=0600
 +group=audio
 +perm=0660

[Footnote]

*1* A careful but not careful enough reader would wonder if the use
of "--- /dev/null" or "+++ /dev/null" to represent an addition
and a deletion may hamper managing the device node "/dev/null",
but this is not a problem.  Such a device node managed by GIT
will appear as "--- dev/null" or "+++ dev/null", without the
leading slash.


  parent reply	other threads:[~2005-05-03 20:17 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
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 [this message]
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

  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=7vy8awt5wo.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --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.
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).