On Thu, 30 Nov 2006 17:32:22 -0800 (PST), Linus Torvalds wrote: > > The old argument by incredulity. The fact that you cannot see it doesnt' > change the fact that I use it all the time. I'm sorry, Linus. I'm really failing to communicate with you somehow here. I _do_ use this all the time too. I don't need you to explain it to me again. I get it, I like it, I use it. That's not at all what I'm trying to discuss here. > - your argument is that cannot understand how anybody would ever want to > use this. Nope. I get it and I use it. Most commonly I do things like "update-index;commit" to separate independent changes, (I could use "git commit explicit/files" instead but I *gasp* actually enjoy being able to manually stage things in the index first). What I'm trying to say is that the _defaults_ are not well geared toward helping new users do what they want to with git. > That's really what it all boils down to. That's your ONLY argument. You > didn't actually answer any of me explaining _why_ it's how it works, and > why it _has_ to be why it works. Your argument just boils down to "I can't > believe it's useful to be consistent". I do understand how git works. I understand your points about filenames and content. I understand that. One thing you never really answered was my conversation with a new user that left the user with the impression of "git is bizarre". How can I fix that conversation? The idea I have for improving this is to do nothing more than change the default semantics for one command to the semantics of that same command with a single-letter option. You keep saying that my idea is brain-damaged, (that carrying the filename from "git add" to "git commit" without the old contents would violate something fundamental). But "commit -a" already exists and does _exactly_ what I'm asking for here. People use that without destroying git's model. Why would it necessarily be so evil to do that by default? By the way, none of the "confusion" arguments are coming from me directly. They're coming through me by proxy, (on behalf of people I've seen deciding against using git). Personally, I love git and plan to continue using it forever. I'm very happy with it. I'm even comfortable with all of the aspects of its interface that I'm arguing against changing here, (which really are not big fundamental things). I just think its harder for new people to get to that point than it should be. > - the "git add file ; change file ; git commit" behaviour is absolutely > REQUIRED once you get the whole "git tracks content" logic. Doing > anything but committing the old version (the one you added) would be > illogical and wrong, because it's strictly against the whole POINT of > tracking content. Here's another question based on that example. You say above that committing the old version is the only logical thing to do. Separately, you say that after adding file-a and file-b it's often convenient to be able to commit file-a without file-b. So, given the following: echo a > file-a echo b > file-b git add file-a file-b echo a-not-ready-yet > file-a How could I do both of these at once? That is, how can I commit the _old_ version of file-a, (the only logical choice), but not commit file-b? There's no commit command that does that is there? (I don't think that's a fault in git since I think this would be a fairly exceptional thing to do). > So. That's what it boils down to. Your personal incredulity against > fundamental concepts and real usage. [I'll snip the rest, because I really do think I understand, agree with, and accept the fundamental concepts of git.] But as for "real usage", by far, the thing I want to do most often is to commit the state of my files as the exist in my working tree at the time of commit. Any time I do anything else, I'm well aware of it, and I'm quite happy to do "special" index-manipulating commands, (taking advantage of the fundamental, content-tracking nature of git to do it). I think the defaults for git-commit should reflect that aspect of real usage. That's all. -Carl
Attachment:
pgpDTsuEhfn8Q.pgp
Description: PGP signature