From: Andreas Gal <gal@uci.edu>
To: Junio C Hamano <junkio@cox.net>
Cc: Linus Torvalds <torvalds@osdl.org>,
Kay Sievers <kay.sievers@vrfy.org>,
git@vger.kernel.org
Subject: Re: git and symlinks as tracked content
Date: Tue, 3 May 2005 14:51:18 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.58.0505031446220.31626@sam.ics.uci.edu> (raw)
In-Reply-To: <7vr7got2tz.fsf@assigned-by-dhcp.cox.net>
Whether you use an explicit "dev" type or an implicit "dev" type that
calls itself "blob" and uses a magic mode flag to tell checkout that it
needs special treatment doesn't make a difference (whatever you
prefer, really). I was only trying to make the point that hashes should remain
hashes and not become a placeholder for minors/majors. However, as
somebody already suggested, the entire issue is probably moot. When was the last
time you tried to version control /dev? ;)
Andreas
On Tue, 3 May 2005, Junio C Hamano wrote:
> >>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
>
> LT> On Tue, 3 May 2005, Andreas Gal wrote:
>
> >> Yuck. Thats really ugly. Right now all files have a uniform
> >> touch to them. For every hash you can locate the file,
> >> determine its type/tag, unpack it, and check the SHA1
> >> hash. The proposal above breaks all that. Why not just
> >> introduce a new object type "dev" and put major minor in
> >> there. It will still always hash to the same SHA1 hash value,
> >> but fits much better in the overall design.
>
> LT> Hey, I don't personally care that much. I don't see anybody using
> LT> character device nodes in the kernel tree, and I don't think most SCM's
> LT> support stuff like that anyway ;)
>
> LT> If you want to make it a blob (and have a use for it), go wild.
>
> Introducing "dev" type, as Andreas suggests, is wrong. This
> this should be done in the same way as you suggested for the
> symlink case. Store a blob object with those chrdev or blkdev
> modes whose contents are of form:
>
> major=14
> minor=4
> owner=root
> group=audio
> perm=0660
>
> This would impact the diff side least, and for the cache side it
> does not matter in storing and merging. checkout-cache still
> needs to know about this.
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2005-05-03 21:50 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 [this message]
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
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=Pine.LNX.4.58.0505031446220.31626@sam.ics.uci.edu \
--to=gal@uci.edu \
--cc=git@vger.kernel.org \
--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.
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).