On Wednesday 2006 December 13 23:31, Junio C Hamano wrote: > I am moderately against making a command verbosely report when I'm not sure "verbose" is the word for one extra line of output: $ git commit Revision XXXXXXXXXXXXXXXXXX successfully added. I'd actually argue that git-commit is a particular problem because it's too fast. You quit editing your commit message and bang, you're back at the command line. Then you run git-log to make sure it really was committed. > it did exactly what it was told to do, _unless_ the command is > expected to take longer than other commands in git suite, or it > is something the user rarely runs. In the specific case of commit I really think the hash that was added needs to be printed. I often do a series of git-commits on separate files; to find out the hash of one of those recent commits I then hop over to qgit to look. If it were right there on my terminal I wouldn't need to have qgit open all the time. > > * git-branch is not verbose enough when creating a new > The same comment applies here. Right back at you. "what it was told to do", is not a clear cut thing. Bear in mind that users make mistakes (I certainly do), so what I told it to do was not necessarily what I wanted it to do. With no output to tell me what actually happened, it makes it harder to go back and see what you did wrong. > However, perhaps you could make lack of "[user] expert = true" > in ~/.gitconfig to trigger more verbose messages that say "yes > sir I did what I was told to do". I've always thought that programs that needed an expert/beginner split were badly designed. I'm not sure you're characterising the messages correctly with "yes sir I did what I was told to do". That sort of output would truly be useless. However, going back to my git-commit example, I didn't say "commit and give this the hash XXXXXXXX", I said "commit". git makes up the hash for me, and so should really tell me that hash. > Not interested in implementing that myself at all, though. I've gotten a far more positive response than I'd expected, so it doesn't surprise me. > > Tell them if they > > made a branch as well, which branch they are now on. > > I think you are talking about "checkout -b" not commit here; > this might be a borderline (branch creation is less often done > and it might warrant assuring feedback), but I think it still > falls into the "doing exactly what it was told to do" category. You're right, I was. The reason I think feedback is useful is because of the two ways of making a new branch: - git-branch XYZ This makes a new branch but DOESN'T leave me on XYZ - git-commit -b XYZ This makes a new branch and switches to XYZ I can't tell you the number of times I get this wrong. It's not because I don't know if I stop to think, it's because I'm thinking about the project, not the VCS. > No. It either says patch is corrupt, or a hunk at this line > does not apply. I do not see what more would you would want to > ask it to say. I've been building a repository that contains every kernel release since v1.0.0; I did it by downloading every patch and "git-apply"ing them one at a time. Along the way, I had a few occasions where the patch didn't apply. I would get the "hunk didn't apply" message. (e.g. v1.1/patch54.bz2 if you're interested) Now - it /should/ apply, this is a published patch; I investigated each one, and it was always down to a whitespace problem. The current version didn't have the same whitespace as the patch was expecting; often part of a much larger patch which mostly applied. git-apply could have told me... While applying hunk #17, the following update would not apply to the file this/that/theother.c -#endif +#endif Instead I had to git-checkout HEAD; bzcat patch | git-apply --reject; find . -name "*.rej"; vim; git update-index; blah, blah blah. > As long as your solution does not accidentally lose local, > unrelated changes, changing "git-rebase --skip" to do the needed > clean-up itself for the user would be Ok (I think we would want Of course; never discarding data always takes precedence. > While I agree the users need to be taught about 'prune', I do > think immediately after running the above commands is exactly > the wrong point to run 'prune'. 'prune' should not be run while > you are busily munging the tip of the branch with rebase and > reset to come up with something that you can call "oh, I am done > with this series for now." Otherwise even lost-found would not > be able to help you. Absolutely; I wasn't suggesting that the message should say "now run git-prune"; otherwise we might as well run git-prune ourselves. I don't really know that the solution is; but I do think we need one. > In general the principle ought to be not to say anything if the > command does exactly what it was told to do successfully, unless > the operation is expected to take longer than other normal > commands in the git suite, or something that is rarely used. git is its own worst enemy here I think. I still have doubts that something actually happened when I run commands because they return so quickly. > Perhaps under "[user] expert" control. I think the problem with that is going to be that there will be disagreement about which commands should output what in which mode. "I like git-commit to tell me what it committed, but don't want git-add to list files" sorts of thing. Andy -- Dr Andy Parkins, M Eng (hons), MIEE 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