On Sat, 2 Dec 2006 08:28:57 +0000, Alan Chandler wrote:
> There is a conceptual difference between thinking that git-add is about adding
> a file and git-add adding the current state of a files content.
Yes, there is.
> If your
> conceptual model is the first of these - then I can see why you see a problem
> with git-add being used to say a files contents have changed.
Yes. (And of course, I personally understand the second conceptual
model. But there are a lot of "brain-damaged" people out there.)
> However, if you regard the git-add command is "adding the current content of
> the file to a staging area" , and you say this is an SCM which by definition
> keeps the history of things once its been told about them I don't see why
> there is a need for a different name for the operation the first time and for
> the operation later.
Yes, that's also true. Once you know the model then you wouldn't need
two different commands. One can certainly get by with just the
functionality of "update-index" for everything.
> Trying to put myself in the shoes of a newbie - if taught to use add in both
> ways up front - is to ask why git isn't clever enough to notice that I have
> changed the content of something it already knows about rather than having it
> to manually add it again.
Yes, and "put myself in the shoes of a newbie" is what I've been doing
through the whole conversation. That's why I keep coming across as so
stubbornly stupid in these threads, ("why can't Carl just understand
how git works?!").
> So I am with you that we need to effective teach
>
> git add <filename> #add content of filename to the SCM
> #edit <filename>
> git commit -a #commit current state of all tracked content
>
> first, and then move on to teach selective commiting
Yes. That's the only way to avoid this confusion.
So all of the conditions above, ("if your conceptual model is", "if
you regard the git-add command", "if taught to use git-add up front",
"if we effectively teach 'commit -a' first"), are barriers to learning
git. We can't guarantee these are all met for new users, and when
they're not, the users can get confused.
If git's model imposes the requirement, "we should first teach one
thing, then move on to teach a subsequent thing", it would be just
that much nicer if the commands themselves could help us do that,
(because the default would do the thing they would need first, and
then the user has to explicitly do _something_ else to get the
subsequent thing).
See? I'm just trying to make the command set more naturally provide
the same flow of learning that we've been proposing for the tutorial.
-Carl
Attachment:
pgpYDw6sYGsLX.pgp
Description: PGP signature