Thread (38 messages) 38 messages, 18 authors, 2016-08-11

Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".

From: Carl Worth <hidden>
Date: 2016-08-11 20:05:35

Possibly related (same subject, not in this thread)

On Thu, 30 Nov 2006 10:38:25 -0800, Carl Worth wrote:
           And it's that "why should that behavior be confusing"
disconnect that I'm trying to bridge here. Can you see why the above
confuses new users?
By the way, I think I've said all I can in this thread.

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. It's the user being
required to mentally juggle 3 states for the file, (the last
"committed" state, the current "working tree" state, and this
"something else" state). The sequence above, (which is very natural),
exposes this "something else" state that to a new user.

If we imagine a new user as coming, not from cvs, but coming from
no revision control system, then it's less confusing to add one single
new state, (the "last committed" state), in addition to the "working
tree" state the user is familiar with.

Forcing the user to learn two instead of one is just plain harder,
(which is completely separate from git _allowing_ this extra state
once you learn it).

So if git is determined to just be harder to learn this way, then I
don't know what more I can do to help here.

I love git, and I think everyone should use it. I would just like to
help make it a bit easier for people to do that.

-Carl

Attachments

  • (unnamed) [application/pgp-signature] 189 bytes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help