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