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

From: Andy Parkins <andyparkins@gmail.com>
Date: Dec 14, 2006, 09:59 UTC
Message-ID: <200612140959.19209.andyparkins@gmail.com>
In-Reply-To: <7vk60vbcfz.fsf@assigned-by-dhcp.cox.net>

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.

Show 7 quoted lines

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

Show 7 quoted lines

> 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