Junio C Hamano escreveu:
You claim it is _an interface_ issue but it is not.
>> I don't want ANYTHING to really change, I just want a sane interface
>> to it.
>
> I agree that you do not want to change anything. You just
> needed a bit of handholding, because you deviated from the
> cookbook usage, to correct your course.
Users (well, I do at least) start fiddling with systems to find out how
they work. Reading the manual is usually done as a last resort. I
think this is pretty well documented in usability research.
I'm trying to show how GIT is badly suited to this. Your response is to
explain to me what I should have done. That's nice, but that approach
doesn't scale, because you don't reach the dozens of users out there who
try the same, fail and give up.
If you really want to find out the weaknesses, you'd have to sit someone
new to git in front of a computer, and let him figure how to operate it,
while videotaping everything.
Writing a manual for newbies is also an effective (and simpler and
cheaper) approach of figuring out what needs to be changed.
As another example: annoyances regarding program invocation
- option handling: -x -f -z != -xfz , "--max-count 1" doesn't work,
but needs an '='
- git --help lists an unordered set, which is too long scan quickly.
I'd expect that list to either contain everything or the minimum set for
daily use. I.e. the set introduced in a first tutorial. Why are merge,
prune, verify-tag there?
Try "bzr help" for comparison.
- --pretty option with wholly uninformative options full, medium,
short, raw. It's not even documented what each option does.
I can go on with listing idiosyncrasies, but my point is not to get help
from you, but rather to show how git can be improved.
With GIT, this is what happens
[hanwen@haring y]$ git pull ../x
fatal: Needed a single revision
Pulling into a black hole?
You asked it to fetch from the neighbour repository and merge it
into your current branch which does not exist (I presume that
you omitted to describe what you did in directory y/ and I am
assuming you did "mkdir y && cd y && git initdb" and nothing
else). You are pulling into a black hole.
as you remark in the other reply, there is IMO no reason for not having
an empty 'master' branch. If master + HEAD gets created on the first
commit, it might as well be created on the init-db.
--
Han-Wen Nienhuys - hanwen@xxxxxxxxx - http://www.xs4all.nl/~hanwen
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html