Steffen Prohaska [off-list ref] writes:
Quite often git prints a lot of very technical information that
is not very interesting as long as things succeed without error.
Some examples are
- git fetch (see above)
Probably.
- git rebase: prints a lot of details that I'm not interested in
unless the rebase fails.
Yes. Most of the clutter is coming from "am" which also should
be squelched.
Saying
Switched to branch <blah>
is good when the branch to rebase is specified.
"HEAD is now at ..."
is not useful -- it is a side effect of rewinding the head to
the --onto commit.
<blank line>
Applying <patch subject>
<blank line>
Wrote tree <tree object>
Committed: <commit object>
are coming from "am" for each patch. We could squelch these
into just one "Applying <patch subject>" and nothing else, which
would also help making "am" quieter.
- git push: prints updates of remote heads. A message about
failing to update a remote head may get lost.
Please do not remove the report of successful update, as people
often say "git push" or "git push $there" without explicitly
saying which refs to push. When pushing out to publish, I say
"git push ko" (to mean k.org) and I _want_ my positive feedback.
- git merge: the fact that a merge is a fast forward merge gets
printed at the very top, followed by (often a lot of) diffstat.
I know diffstat can help to judge if the merge did what you
expected. But even more important is the fact that the merge
was just a fast forward, which may get buried under lots of output.
I do not think fast-forwardness is particularly interesting. If
you find fast-forwardness interesting, I suspect you would even
want to know what _your_ change that were not in the other side
of the merge, which is something that we do not even report
right now.
Maybe git should become more quiet, as other unix tools are, and
per default only report problems. Technical details and progress
could be requested explicitly by '--verbose' or similar.
I'd agree with this sentiment in principle, and many of the
things you propose to remove above fall into the "unnecessary
clutter" category. But some of the existing output fall into
the "necessary info" category --- diffstart after merge and
report of successful remote ref updates are such things, so we
should be careful not to go overboard.
On Sep 30, 2007, at 12:25 AM, Junio C Hamano wrote:
Steffen Prohaska [off-list ref] writes:
quoted
- git push: prints updates of remote heads. A message about
failing to update a remote head may get lost.
Please do not remove the report of successful update, as people
often say "git push" or "git push $there" without explicitly
saying which refs to push. When pushing out to publish, I say
"git push ko" (to mean k.org) and I _want_ my positive feedback.
Yes but it's pretty technical.
A much simpler output could be easier to scan by a human
updating 'refs/heads/master' .. fast forward .. ok.
updating 'refs/heads/pu' .. forced non-fast forward .. ok.
updating 'refs/heads/next' ..
ERROR: 'refs/heads/next' not updating to non-fast forward
exit(1) here.
If we exit after the very first problem it can't get lost.
After fixing the issue you can just 'git push' again.
quoted
- git merge: the fact that a merge is a fast forward merge gets
printed at the very top, followed by (often a lot of) diffstat.
I know diffstat can help to judge if the merge did what you
expected. But even more important is the fact that the merge
was just a fast forward, which may get buried under lots of output.
I do not think fast-forwardness is particularly interesting. If
you find fast-forwardness interesting, I suspect you would even
want to know what _your_ change that were not in the other side
of the merge, which is something that we do not even report
right now.
I use it to advance a branch to a temporary integration branch.
At that point I expect that the merge is a fast forward. Here's
what I do.
git checkout -b for/master master
git merge branch-with-good-topics
git branch -f scratch
git push compileservers # pushes scratch for automatic builds
Now I wait for compiles to finish. Typically I continue not before
the next morning. If everything's ok I do.
git checkout master
git merge for/master
git push
The last merge must be a fast forward. This is the only fact I'm
interested in. I could do 'git reset' or 'git branch -f' but then
I'd loose the check if it's a fast forward.
I don't merge directly to master to avoid any accidentally push.
I can also easily revert by just deleting 'for/master'.
Maybe there's a better workflow?
quoted
Maybe git should become more quiet, as other unix tools are, and
per default only report problems. Technical details and progress
could be requested explicitly by '--verbose' or similar.
I'd agree with this sentiment in principle, and many of the
things you propose to remove above fall into the "unnecessary
clutter" category. But some of the existing output fall into
the "necessary info" category --- diffstart after merge
I agree. Could we print the note about fast forward _after_ the
diffstat? Maybe there are more useful oneline information that
could be output there.
and report of successful remote ref updates are such things, so we
should be careful not to go overboard.
But the output could be less technical and more human readable.
Also diffstat's output and "git push" are different. diffstats
change with the content of your repo. "git push" just succeeds
or fails. If is succeeds it updates remote refs according to your
configuration. There is no new information in the output beyond
success or failure [which is not quite true if you depend on
git push finding matching refs automatically -- I don't]. I don't
think the sha1's printed are needed by anyone. And if someone
needs them, he could call push with '--verbose'.
I asked about a '--dry-run' switch to "git push" some time ago,
which would only report what "git push" would do without actually
changing anything on the remote side. I'd use this to check what
I expect to do. Just in case I messed up my configuration. At the
time "git push" is actually pushing it's too late to fix a broken
configuration. I know '--dry-run' it's not trivial to implement
and I'll likely have no time to look into it.
Steffen
Hi,
On Sun, 30 Sep 2007, Steffen Prohaska wrote:
On Sep 30, 2007, at 12:25 AM, Junio C Hamano wrote:
quoted
Steffen Prohaska [off-list ref] writes:
quoted
- git push: prints updates of remote heads. A message about
failing to update a remote head may get lost.
Please do not remove the report of successful update, as people often
say "git push" or "git push $there" without explicitly saying which
refs to push. When pushing out to publish, I say "git push ko" (to
mean k.org) and I _want_ my positive feedback.
Yes but it's pretty technical.
A much simpler output could be easier to scan by a human
updating 'refs/heads/master' .. fast forward .. ok.
updating 'refs/heads/pu' .. forced non-fast forward .. ok.
updating 'refs/heads/next' ..
ERROR: 'refs/heads/next' not updating to non-fast forward
exit(1) here.
No, please no. This is way too short.
If at all, please let 8c3275abcacb83ea3f4c4f4ceb2376799fc282bd be an
example, and make git respect several different output levels, but not
changing the default (at first).
Ciao,
Dscho
On Sep 30, 2007, at 2:44 PM, Johannes Schindelin wrote:
quoted
A much simpler output could be easier to scan by a human
updating 'refs/heads/master' .. fast forward .. ok.
updating 'refs/heads/pu' .. forced non-fast forward .. ok.
updating 'refs/heads/next' ..
ERROR: 'refs/heads/next' not updating to non-fast forward
exit(1) here.
No, please no. This is way too short.
If at all, please let 8c3275abcacb83ea3f4c4f4ceb2376799fc282bd be an
example, and make git respect several different output levels, but not
changing the default (at first).
good idea.
Steffen