Re: What's in git.git (stable)

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.

quoted

 * 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.

quoted

 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