Re: Terminology
> So what's the converse of "fetch" (to rename git-ssh-push to)? > Maybe "ship"? The opposite of "fetch" is "throw" or "toss". (Just avoid tossing cookies or off.) - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Handling renames.
> One option for optimising this, if we really need to, might be to track > the file back to its _first_ ancestor and use that as an identification. > The SCM could store that identifier in the blob itself, or we could > consider it an 'inode number' and store it in git's tree objects. This suggestion (and this whole discussion about renames) has issues with file copies, which form a branch in the revision history. If I copy foo.c to foo2.c (or fs/ext2/ to fs/ext3/), then the oldest ancestor isn't a "unique inode number". I've written a lot of programs by debugging hello.c. Thinking about this can give you all sorts of exciting merge possibilities. If branch1 renames a.c to b.c, and branch2 patches a.c, it seems obvious that the patch should be merged into b.c. But what if branch1 copies a.c to b.c? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [darcs-devel] Darcs and git: plan of action
> Hell no. > > The commit _does_ specify the patch uniquely and exactly, so I really > don't see the point. You can always get the patch by just doing a > > git diff $parent_tree $thistree > > so putting the patch in the comment is not an option. Er... no. One of darcs' big points is that it has at least two fundamentally different *kinds* of patches. One is the classic diff(1) style. The other is "replace very instace of identifier `foo` with identifier`bar`". Note that merging such a patch with another that adds a new instance of "foo" has a quite different effect from a similar diff-style patch. Even though both have identical effects on the tree to which they were initially merged. And darcs is specifically intended to support additional kinds of patches. Again, all in order that the patch can work better when applied to trees *other* that the one it was originally developed against. Anyway, the point is that, in the darcs world, it is NOT possible to reconstruct a patch from the before and after trees. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: enforcing DB immutability
[A discussion on the git list about how to provide a hardlinked file that *cannot* me modified by an editor, but must be replaced by a new copy.] [EMAIL PROTECTED] wrote all of: >>> perhaps having a new 'immutable hardlink' feature in the Linux VFS >>> would help? I.e. a hardlink that can only be readonly followed, and >>> can be removed, but cannot be chmod-ed to a writeable hardlink. That i >>> think would be a large enough barrier for editors/build-tools not to >>> play the tricks they already do that makes 'readonly' files virtually >>> meaningless. >> >> immutable hardlinks have the following advantage: a hardlink by design >> hides the information where the link comes from. So even if an editor >> wanted to play stupid games and override the immutability - it doesnt >> know where the DB object is. (sure, it could find it if it wants to, >> but that needs real messing around - editors wont do _that_) > > so the only sensible thing the editor/tool can do when it wants to > change the file is precisely what we want: it will copy the hardlinked > files's contents to a new file, and will replace the old file with the > new file - a copy on write. No accidental corruption of the DB's > contents. This is not a horrible idea, but it touches on another sore point I've worried about for a while. The obvious way to do the above *without* changing anything is just to remove all write permission to the file. But because I'm the owner, some piece of software running with my permissions can just deicde to change the permissions back and modify the file anyway. Good old 7th edition let you give files away, which could have addressed that (chmod a-w; chown phantom_user), but BSD took that ability away to make accounting work. The upshot is that, while separate users keeps malware from harming the *system*, if I run a piece of malware, it can blow away every file I own and make me unhappy. When (notice I'm not saying "if") commercial spyware for Linux becomes common, it can also read every file I own. Unless I have root access, Linux is no safer *for me* than Redmondware! Since I *do* have root access, I often set up sandbox users and try commercial binaries in that environment, but it's a pain and laziness often wins. I want a feature that I can wrap in a script, so that I can run a commercial binary in a nicely restricted enviromment. Or maybe I even want to set up a "personal root" level, and run my normal interactive shells in a slightly restricted enviroment (within which I could make a more-restricted world to run untrusted binaries). Then I could solve the immutable DB issue by having a "setuid" binary that would make checked-in files unwriteable at my normal permission level. Obviously, a fundamental change to the Unix permissions model won't be available to solve short-term problems, but I thought I'd raise the issue to get people thinking about longer-term solutions. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Thu, Apr 24, 2014 at 09:41:06AM -0400, Theodore Ts'o wrote: > On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote: > Creating a ~/.gitconfig file if one doesn't already is one I agree > with, and at least on Unix systems, telling them that the config file > lives in ~/.gitconfig, or where ever it might happen to be on other > platforms, is a good one. If it's in some really weird place on > Windows, then sure, we can tell them about "git config -e". But the > point is to let the user look at the default .gitconfig file, where we > can put in comments to help explain what is going on, and perhaps have > links to web pages for more information. I think the idea of a commented gitconfig is a good solution. We could include default aliases commented, so that a new user would just have to uncomment them. That way, he will understand they are aliases and not commands, learn how to tune them to its own needs and it won't annoy anyone because they will be commented by default, ideally with explicit commentaries around them. Furthermore, this could be a good way to show a new user all the possibilities of git, or at least its configuration. Documentation is a good thing when you know what you are looking for, but when you are beginning, you don't know what can be done, and reading a complete and commented example configuration could be a good way to discover it. pgpbPbeQEGNjc.pgp Description: PGP signature
Re: gitignore vs. exclude vs assume-unchanged?
On Fri, Apr 25, 2014 at 04:09:47PM -0700, a...@bellandwhistle.net wrote: > >Andrew Ardill writes: > > > >As a data point, I have seen people add ".gitignore" to their > >.gitignore file, as they don't want to share the file. > > Right, I've seen that too. That something I am actually doing in my projects, because I didn't know they were other way to exclude files like .gitignore. > It confused the heck out of me. It only lends > credence to my point about the docs. Those users want the functionality of a > pattern in '$GIT_DIR/info/exclude', but haven't been able to figure it out > easily enough. They've just heard about .gitignore, so they're using that. > Yes, it's all there in the docs if you read it several times, and you > already know what you're looking at, but not in a terribly accessible, best > practices, "advice from a smart friend who's been through it all already" > kind of way. Well documentation can be useful when you know what you're looking for, but I won't go read it just for discovering new features I didn't know. > Well, yes: semantics. Since they do slightly different things, they should > have different names. It makes reference and teaching much easier. In fact, > if a renaming were to occur, I would actually prefer even better semantics: > > .gitignore -> .shared-ignore > > $GIT_DIR/info/exclude -> $GIT_DIR/info/local-ignore > > These suggested names could perhaps be improved on. But if anything, the > names need to be more different, not less. Users should be able to instantly > know what a speaker is talking about without having to doublecheck and ask > if by "git-ignore", the speaker really meant "git ignore" or > "dot-gitignore". I agree with a new name for .gitignore. A name like shared-ignore would make explicite the fact it is shared, and then the user would look for another way to locally exclude files. This would be a good approach, but changing it won't be easy as most people already use .gitignore. Would it be acceptable to have git display a warning when it detects that .gitignore is excluding itself, with eventually a link to the documentation or the path to $GIT_DIR/info/exclude ? pgp468gFl5uiM.pgp Description: PGP signature
Re: [ksummit-attendees] [PATCH] commit: Add -f, --fixes option to add Fixes: line
On Tue, Oct 29, 2013 at 10:09:53AM +1100, Benjamin Herrenschmidt wrote: > On Mon, 2013-10-28 at 09:59 +0100, Christoph Hellwig wrote: > > Btw, can we please take away this discussion from ksummit-attendees? It's > > got > > absolutely nothing to do with kernel summit and is getting fairly annoying. > > Ack. Additionally, iirc, we had decided that > > - We don't cross post multiple lists > > - We drop the annoying subject tags > > As is, all I see is some attempt at doing an lkml dup, which is > pointless I agree too. This whole thread seems to be about noise, and I too thought there was something about not cross-posting between this list and any other list. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ksummit-attendees] [PATCH] commit: Add -f, --fixes option to add Fixes: line
On Tue, Oct 29, 2013 at 10:09:53AM +1100, Benjamin Herrenschmidt wrote: > On Mon, 2013-10-28 at 09:59 +0100, Christoph Hellwig wrote: > > Btw, can we please take away this discussion from ksummit-attendees? It's > > got > > absolutely nothing to do with kernel summit and is getting fairly annoying. > > Ack. Additionally, iirc, we had decided that > > - We don't cross post multiple lists > > - We drop the annoying subject tags > > As is, all I see is some attempt at doing an lkml dup, which is > pointless I agree too. This whole thread seems to be about noise, and I too thought there was something about not cross-posting between this list and any other list. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
