From: Peter Baumann <waste.manager@gmx•de>
To: git@vger•kernel.org
Cc: Junio C Hamano <junkio@cox•net>
Subject: Re: Importing from tarballs; add, rm, update-index?
Date: Fri, 12 Jan 2007 22:04:03 +0100 [thread overview]
Message-ID: <20070112210403.GB6262@xp.machine.xx> (raw)
In-Reply-To: <7vejq0t4ij.fsf@assigned-by-dhcp.cox.net>
On Fri, Jan 12, 2007 at 11:43:32AM -0800, Junio C Hamano wrote:
> Peter Baumann <Peter.B.Baumann@stud•informatik.uni-erlangen.de>
> writes:
>
> > Me doesn't really like the new semantics of "git-add", because it does
> > two seperate things - it adds new files and it refreshes the content of
> > previously known files.
>
> http://thread.gmane.org/gmane.comp.version-control.git/32452/focus=32792
>
[For the readers conveniance I added the above mail below.]
Yes. I fully second Linus opinion. But I think there should be a difference in
adding completly new content to the index (number of entries in the index grows)
or replacing content in the index.
That's what I'm aiming for.
-Peter
?>
?> If the "create file; git add; edit file; git commit" confusion isn't
?> blisteringly obvious to the git maintainers then I think I have to
?> give up here.
?>
?> And this isn't just CVS-induced brain damage.
?
?I'm sorry, but you are wrong.
?
? It really _is_ CVS-induced brain damage, and I'm trying to teach you. You
? can give up, but that's really "refuse to see the damage that systems like
? RCS and CVS has done to the world"
?
? The fundamental brain damage that CVS (and RCS, and SVN, and just about
? anything else) has had is thinking that "filenames" (and sometimes this is
? "fixed" to be "file ID's") are somehow special, and a totally separate
? thing from "file contents".
?
? Really. It's a BUG. It's a deficiency in CVS and friends. And it's a
? deficiency that you have gotten so used to that you don't even see that
? it's simply obviously NOT TRUE.
?
? You _cannot_ have a filename without the contents of that filename. That
? whole concept doesn't make sense, except in the twisted AND WRONG mental
? model of "files have identities even without content".
?
? The whole point of git is that it is about "project state" and the history
? that binds those states together. People have kind of come to accept that,
? and a lot of people realize what it means, but I don't think you've really
? accepted what it means for something as simple as a "git add" command.
?
? Again, totally ignore the index. Imagine that it doesn't exist. Imagine
? that you never actually learnt about it, and that none of the
? documentation ever mentions it, and just ask yourself:
?
? "What does 'adding a file' really mean?"
?
? I mean _really_. It cannot be about the "filename", because a filename
? simply doesn't have any meaning alone. Remember what git is all about.
?
? No, when you do a "git add", YOU DO NOT TALK ABOUT FILENAMES AT ALL.
?
? NOT EVEN CLOSE!
?
? No. Git is, and has always been, all about tracking project content. The
? fact that CVS is crap, and thinks that "filenames" are special (and this
? causes major problems when you do renames), and the fact that SVN is crap,
? and things that "file identities" are special (and this causes major
? problems when you split a file or when two files join) is very much about
? THEIR F*CKING IDIOTIC FUNDAMENTAL BRAINDAMAGE!
?
? So take five minutes to really think about that. Take an hour. Take a
? week. Ponder it.
?
? What does it mean to "add" something to a project? It has _nothing_ to do
? with "filenames". Yeah, the filename obviously exists, but it's not
? something that exists on its own. You add the ONLY thing that git tracks.
?
? You add CONTENT.
?
? When you do "git add file.c" you aren't adding a filename to the list of
? files that git knows about. Not even CLOSE. No. You are really adding
? _content_ to the project you are tracking. You haven't bound it to a
? commit yet, but it's there. It's there both conceptually, and very much in
? a real technical sense too (you've literally added the git object that
? that file describes to the object database - the "commit" and "tree"
? objects to tie it all together is just waiting to be added, but they
? really just expose it - the actual file object has already been created
? when you do "git add".)
?
? So yes, you very much ARE talking about CVS braindamage. The reason why
?
? git add file.c
? echo New line >> file.c
? git commit
?
? commits the _old_ content, is very much because git is ALL ABOUT THE
? CONTENT. It has _never_ been about filenames. And it _shouldn't_ be about
? filenames, because that would be BUGGY AND BROKEN.
?
? Sorry for shouting, but as long as you think "git add" adds a filename,
? you're just not getting it. And I think it's really sad that you don't
? even seem to understand that yes, this _is_ braindamage that has been
? forced upon you by decades of mental rape done by bad source control
? systems.
?
? Please. File identities are _bad_ in the SVN kind of setting. The CVS kind
? of "filename == file identity" is even _worse_, but it's still exactly the
? same disease. It's the disease of thinking that metadata is somehow
? "different" from real data, and that "files" have identities that are
? somehow separate from the data they contain.
?
? Face it, git is consistent, and if it acted the way you seem to expect it
? to act, it would actually be a BUG. Exactly because you cannot and MUST
? NOT think that "filename" is something that has meaning without "file
? content" (or "file type" and "file permissions" - they all go together).
?
? And notice? NONE OF THIS HAS ANYTHING AT ALL TO DO WITH 'INDEX'!! The
? explanation above is not "this is how the index works". It's a much more
? fundamnetal issue of getting the right mental model, where the only thing
? that matters is contents.
?
? So even without an index, "git add" should work the way it works, once you
? can just let go of the broken model that is CVS.
?
? Please. Join me, Luke. The power of the git side is stronger. I am your
? father.
?
? Linus
next prev parent reply other threads:[~2007-01-12 21:10 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-12 13:41 Importing from tarballs; add, rm, update-index? Chris Riddoch
2007-01-12 14:09 ` Horst H. von Brand
2007-01-12 14:39 ` Johannes Sixt
2007-01-12 15:39 ` Horst H. von Brand
2007-01-12 14:40 ` Morten Welinder
2007-01-12 18:47 ` Junio C Hamano
2007-01-12 19:11 ` Peter Baumann
2007-01-12 19:43 ` Junio C Hamano
2007-01-12 21:04 ` Peter Baumann [this message]
2007-01-13 0:48 ` Junio C Hamano
2007-01-13 9:33 ` Peter Baumann
2007-01-13 11:17 ` Johannes Schindelin
2007-01-13 16:19 ` Peter Baumann
2007-01-13 16:27 ` Julian Phillips
2007-01-13 18:01 ` Junio C Hamano
2007-01-13 16:09 ` Carl Worth
2007-01-13 16:45 ` Brian Gernhardt
2007-01-13 16:48 ` Peter Baumann
2007-01-13 18:54 ` Nicolas Pitre
2007-01-13 19:32 ` Carl Worth
2007-01-13 20:25 ` Junio C Hamano
2007-01-13 20:29 ` Nicolas Pitre
2007-01-13 6:36 ` Brian Gernhardt
2007-01-13 9:36 ` Peter Baumann
2007-01-13 16:31 ` Brian Gernhardt
2007-01-13 18:15 ` Alan Chandler
2007-01-13 19:31 ` Brian Gernhardt
2007-01-13 20:34 ` Shawn O. Pearce
2007-01-14 12:42 ` Johannes Schindelin
2007-01-14 22:42 ` Shawn O. Pearce
2007-01-14 23:49 ` Horst H. von Brand
2007-01-15 1:06 ` Junio C Hamano
2007-01-15 1:12 ` Shawn O. Pearce
2007-01-15 22:46 ` Daniel Barkalow
2007-01-16 0:34 ` Horst H. von Brand
2007-01-16 3:35 ` Daniel Barkalow
2007-01-16 12:12 ` Christian MICHON
2007-01-16 0:51 ` Jakub Narebski
2007-01-13 21:41 ` Horst H. von Brand
2007-01-13 21:47 ` Shawn O. Pearce
2007-01-13 22:04 ` Horst H. von Brand
2007-01-12 19:34 ` Carl Worth
2007-01-12 23:28 ` Johannes Schindelin
2007-01-13 0:01 ` Junio C Hamano
2007-01-12 20:20 ` Jakub Narebski
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=20070112210403.GB6262@xp.machine.xx \
--to=waste.manager@gmx$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=junkio@cox$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox