Re: GIT - error: no such remote ref refs/heads/TestBranch

[Carl Worth <cworth@cworth.org>]

[-- Attachment #1: Type: text/plain, Size: 3531 bytes --]

On Wed, 20 Dec 2006 15:36:51 -0800, Junio C Hamano wrote:
> Do you have comments on recent changes (both on 'master' and
> some parts of 'next') from teachability point of view?  I think
> you are "the guilty guy" who defined the theme for v1.5.0 to be
> "usability and teachability" ;-).

I'm flattered to be blamed for what I consider a very good theme for
the release.

I don't have a lot of detailed comments right now other than to repeat
a "good job!" to everyone who has done a lot to improve things lately,
(coming up with more use-oriented documentation, adding a reasonable
shorthand "add"[*] for update-index, cleaning up a lot of bad error
message and needless spew, making much more reasonable default clone
behavior, etc. etc.). I think git's really come a long ways as far as
usability and teachability, (while nothing fundamental has really
changed and old-time users should hardly notice anything different).

I think I'll have a few minor tweaks to suggest to the documentation
if I get a chance to take a detailed pass over it, (which I hope to do
before the new year).

And I'd definitely like to enable "git checkout <revision>" with a new
complaint on git-commit before the 1.5 release. I'll see if I can't
find time to work on implementing that.

-Carl

[*] I'm still somewhat unsettled that the "new" add command conflates
the notions of adding content into the index for paths that previously
didn't exist in the index with the notion of updating the content in
the index for paths that did exist already. I think those notions are
generally distinct from the users point of view---the first changes a
file's state in a fundamental way, (from "untracked" to "tracked"),
while the second merely updates its content with no change to its
state.

One way to see the distinction is to imagine two different useful
operations "add all untracked file paths to the index" and "update
content for all tracked paths". If we had separate commands for 'add'
and 'update' then it would be natural to express these two variants
with "git add --all" and "git update --all".

As things stand now, the first operation is available already with
"git add .", (and oddly, with "git add", and I agree that should be
removed). Meanwhile the second operation is not currently available in
git, (but I recently proposed it as "git add -a|--all" in response to
a request). As pointed out in that thread, there's a bit of a problem
in that "git add --all" is really easy to mistake for a command that
would add all untracked files to the index, (since it's when adding
new paths that people will most often use "git add" so it will
naturally be associated with adding new paths). It's less likely for
users to establish the "update content" notion of "git add" since it
often won't be needed at all, (tutorials and the git-commit
documentation recommend "commit -a" to avoid the need to use "git add"
in its updating sense).

So, to summarize, I think it's good to have a much shorter command to
type than "update-index" for the update-content-of-path-in-index
operation. So using "add" for this is better than "update-index"
already. And if that's how it stays, I can certainly live with it.

But I think it might be even better if the updating notion were on a
separate command name (update ? stage ?), and this in spite of the
fact that fewer commands is generally better for learnability.

It's not a major issue---and it's nothing that I would make a big fuss
over, so feel free to ignore it if it appears a non-issue to you.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]