On Tuesday 2007, April 24, Johannes Schindelin wrote:
> Like Junio said, it is not starting it, but maintaining. (BTW Andy, I
> am still waiting for that list...)
Ask and ye shall receive. I had to make it look pretty first didn't I?
Couldn't just send you any old rubbish.
The only remaining things are hardly worth worrying about or weren't accepted
any way.
Enjoy.
----------------------------------------------------------
ADP niggle list
===============
* git-revert should be called git-invert. It doesn't remove a change
from history, it simply applies another commit that does the
opposite of whatever commit you are "revert"ing. That's an inversion.
* git-branch is not verbose enough when creating a new branch, for a new user
a little reassurance that what they meant to happen has happened would be
nice.
* git-fetch output is confusing:
remote: Generating pack...
remote: Done counting 189146 objects.
remote: Result has 186566 objects.
remote: Deltifying 186566 objects.
remote: 100% (186566/186566) done
Unpacking 186566 objects
24% (44792/186566) done
Some questions from the point of view of a newbie: what is a pack? what is
an object? Why is the remote counting them? Which remote am I reading
from? What am I fetching? What is "Deltifying"? How much data do I have
to download (number of objects doesn't tell me). How long has this taken?
How long is left to go?
* Similar things can be said about git-clone
* Similar things can be said about git-push
* git-show-branch output is cryptic.
Not accepted by list
--------------------
* git-apply output is horrible. It says a few things about whitespace on
stdin then just finishes. When it succeeds. When it fails, it just says
failed, it doesn't say why a particular hunk failed.
* git-rebase/git-cherry-pick/git-reset/etc should all tell the user that they
need to run git-prune to tidy up after themselves.
* git-add has no output, whether it works or not
* git-cat-file is badly named. git-cat-object would be slightly
better.
* In general the principle for messages should be the same as for
presentations:
- say what you're going to do
- do it
- say what you did
So for example, "git-branch newbranch existingbranch" would say
Branching at "existingbranch", hash XXXXXXXXXXXXXXXXXX
- created branch "newbranch"
- your working branch is "existingbranch"
Rather than the nothing that it currently outputs.
Accepted but unimplemented
--------------------------
* git-rebase --skip requires that the offending file be clean with
git-checkout HEAD file
before the skip will work. Why? The fact of the skip is enough
knowledge for rebase to know that I don't care if the merge is lost
Fixed
-----
* Apart from a little convenience of being able to add trees, I'm not
really sure that git-add is different from git-update-index --add
git-add is now more powerful and can replace update-index
* We should never have to see git-update-index; instead git-rm, git-mv
and git-add would take its place. git-add would get new functionality
where it can be used on already tracked files and hence would be renamed
to, say git-prepare.
git-add is now more powerful and can replace update-index.
* git-fetch has to be in working root. If I can do git-push from anywhere in
my tree, why can't I do git-fetch?
* git-reset has to be in working root. If you typically sit in, say "src/",
it's annoying to have to change directory to do a reset.
* git-verify-tag would be nicer as a switch to git-tag
* git-commit doesn't (generally) have output - after a commit, it's difficult
to know if anything happened. Get users used to the idea of hashes to
identify commits by telling them which one they just made. Tell them if
they made a branch as well, which branch they are now on.
* git-init-db says "defaulting to local storage area", as if that is
meant to be a helpful message.
* git-commit without "-a" and without an "update-index" says "nothing
to commit", which isn't an adequate message to help a user who hasn't
realised they need to update the index
* git-merge output is horrible - this affects git-pull, git-rebase,
and git-cherry-pick. Issuing "fatal" errors and then carrying on is very
confusing. Errors in merges appear multiple times. The files upon which
which there is a conflict are spread throughout the output. Most of the
output is not relevant to an average user.
* It would be really nice to be able to do an arbitrary checkout, rather than
having to make a branch for it. Then I could do
git-checkout remotes/origin/master && make
(obviously committing with a non-branch HEAD would be prevented).
I think this is going to be a pre-requisite for submodule support
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@xxxxxxxxx
-
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