From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Nicolas Pitre <nico@cam.org>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: [PATCH 0/3] more terse push output
Date: Mon, 5 Nov 2007 00:05:17 -0500 [thread overview]
Message-ID: <20071105050517.GA6244@sigill.intra.peff.net> (raw)
Here are some patches to match push output to the new fetch output. The
entire output of "git-push" for my test repo now looks like this:
To file:///tmp/parent
+ f3325dc...3b91d1c hasforce -> mirror/hasforce (forced update)
f3325dc..bb022dc master -> mirror/master
! [rejected] needsforce -> mirror/needsforce (non-fast forward)
* [new branch] newbranch -> mirror/newbranch
* [new tag] v1.0 -> v1.0
Counting objects: 5, done.
Writing objects: 100% (3/3), done.
Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
(where I'm mirroring the heads in refs/heads/mirror/* to show off the name
mapping).
The interesting part is in the first patch; the other two are just
removing clutter on stderr. The patches are based on 'next' to follow
Daniel's send-pack work. I'm happy to hold on to them and rebase once
things settle down in this area.
A few caveats:
- the output is generated by send-pack, so it's actually "here's what
I'm about to do" rather than "here's what has happened or is
happening." receive-pack could generate more accurate results
(including marking rejections based on hooks), but it has no
knowledge of the name mapping (so it can't say "foo -> other/foo").
Right now receive-pack generates 'error: blah blah blah' as it
always has.
- the name mapping is perhaps superfluous here, since most of the time
people are just pushing using the same branch name. But it matches
the new fetch output, and if you do use a refspec, it's a lot more
clear.
- this only covers send-pack, since that is where we do the ref
matching. Presumably it would be possible to cover pushing over http
and rsync, but it would have to be totally separate code.
- no code is shared with the git-fetch implementation (they just
happen to use the same format). The code is short enough that I
think it would just end up more confusing to try to factor out the
commonality.
- the 'ref is not up-to-date, maybe you need to push' message has gone
away in favor of the terse '[rejected] ... (non-fast forward)'. I
know there was some discussion recently of enhancing that message.
Is this perhaps too terse?
-Peff
next reply other threads:[~2007-11-05 5:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-05 5:05 Jeff King [this message]
2007-11-05 5:11 ` [PATCH 1/3] more terse push output Jeff King
2007-11-05 5:11 ` [PATCH 2/3] receive-pack: don't mention successful updates Jeff King
2007-11-05 5:12 ` [PATCH 3/3] send-pack: require --verbose to show update of tracking refs Jeff King
2007-11-05 7:09 ` [PATCH 0/3] more terse push output Steffen Prohaska
2007-11-05 21:14 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071105050517.GA6244@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=nico@cam.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).