{"thread":{"id":"12203","subject":"[PATCH 1/3] push: indicate partialness of error message","startedAt":"2008-02-19T16:25:01Z","lastAt":"2008-02-20T00:09:51Z","messageCount":4,"participants":["Jeff King","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"69282","messageId":"20080219162501.GA30451@sigill.intra.peff.net","threadId":"12203","inReplyTo":null,"subject":"[PATCH 1/3] push: indicate partialness of error message","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-19T16:25:01Z","receivedAt":"2008-02-19T16:25:01Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The existing message indicates that an error occured during\npush, but it is unclear whether _any_ refs were actually\npushed (even though the status table above shows which were\npushed successfully and which were not, the message \"failed\nto push\" implies a total failure). By indicating that \"some\nrefs\" failed, we hopefully indicate to the user that the\ntable above contains the details.\n\nWe could also put in an explicit \"see above for details\"\nmessage, but it seemed to clutter the output quite a bit\n(both on a line of its own, or at the end of the error line,\nwhich inevitably wraps).\n\nThis could also be made more fancy if the transport\nmechanism passed back more details on how many refs\nsucceeded and failed:\n\n  error: failed to push %d out of %d refs to '%s'\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\nThis patch series is meant to address some user issues encountered in\nthe recent thread \"git push [rejected] question\". It's entirely\nmessage and documentation updates.\n\n builtin-push.c |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-push.c b/builtin-push.c\nindex c8cb63e..9f727c0 100644\n--- a/builtin-push.c\n+++ b/builtin-push.c\n@@ -90,7 +90,7 @@ static int do_push(const char *repo, int flags)\n \t\tif (!err)\n \t\t\tcontinue;\n \n-\t\terror(\"failed to push to '%s'\", remote->url[i]);\n+\t\terror(\"failed to push some refs to '%s'\", remote->url[i]);\n \t\terrs++;\n \t}\n \treturn !!errs;\n-- \n1.5.4.1.143.ge7e51-dirty\n"},{"id":"69315","messageId":"7vablwiqa7.fsf@gitster.siamese.dyndns.org","threadId":"12203","inReplyTo":"20080219162501.GA30451@sigill.intra.peff.net","subject":"Re: [PATCH 1/3] push: indicate partialness of error message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-19T21:34:40Z","receivedAt":"2008-02-19T21:34:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> This patch series is meant to address some user issues encountered in\n> the recent thread \"git push [rejected] question\". It's entirely\n> message and documentation updates.\n\nThanks; I think all of them are fine 'maint' material.\n\nDistinguishing between [rejected] and [stale] would belong in\n1.5.5 if it is really needed.  Together with the \"git checkout\nnotices forks\" enhancement on Daniel's git-checkout rewritten in\nC, I think it would solve the issue in the \"push [rejected]\nquestion\".\n"},{"id":"69319","messageId":"20080219215441.GA7778@coredump.intra.peff.net","threadId":"12203","inReplyTo":"7vablwiqa7.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 1/3] push: indicate partialness of error message","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-19T21:54:41Z","receivedAt":"2008-02-19T21:54:41Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 19, 2008 at 01:34:40PM -0800, Junio C Hamano wrote:\n\n> Distinguishing between [rejected] and [stale] would belong in\n> 1.5.5 if it is really needed.  Together with the \"git checkout\n> notices forks\" enhancement on Daniel's git-checkout rewritten in\n> C, I think it would solve the issue in the \"push [rejected]\n> question\".\n\nI am still a little uncomfortable with the rejected/stale distinction,\nbecause the semantics aren't clear.\n\nLet's say we figure out which is which in send-pack. Do we:\n\n  - simply change the \"rejected\" text to \"stale, and leave as-is? I\n    think that is safe, but I also think it isn't a significant\n    improvement for workflows that leave lots of stale branches around\n    (they clutter the push output).\n  - omit stale listings when -v is not given?\n    - this is dangerous with the patch I posted, because \"git push; #\n      oops, I forgot I amended; git push -f\" will push stale branches\n      that weren't even mentioned in the first case.\n    - instead, should we require some extra magic to force stale\n      branches to be pushed? Forcing such a push is almost never a good\n      idea, whereas forked branches are not too uncommon.\n    - instead, should we disallow \"-f\" without an explicit refspec (or\n      --all, or --mirror, etc) I can't think of a workflow where you\n      want to force _many_ branches at once, except the special case of\n      mirroring.\n    - we could also combine the two: don't respect -f on stale pushes,\n      but do respect pushing \"+stale\"\n\nThoughts?\n\n-Peff\n"},{"id":"69338","messageId":"7vir0kfpyo.fsf@gitster.siamese.dyndns.org","threadId":"12203","inReplyTo":"20080219215441.GA7778@coredump.intra.peff.net","subject":"Re: [PATCH 1/3] push: indicate partialness of error message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-20T00:09:51Z","receivedAt":"2008-02-20T00:09:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Tue, Feb 19, 2008 at 01:34:40PM -0800, Junio C Hamano wrote:\n>\n>> Distinguishing between [rejected] and [stale] would belong in\n>> 1.5.5 if it is really needed.  Together with the \"git checkout\n>> notices forks\" enhancement on Daniel's git-checkout rewritten in\n>> C, I think it would solve the issue in the \"push [rejected]\n>> question\".\n>\n> I am still a little uncomfortable with the rejected/stale distinction,\n> because the semantics aren't clear.\n>\n> Let's say we figure out which is which in send-pack. Do we:\n>\n>   - simply change the \"rejected\" text to \"stale, and leave as-is? I\n>     think that is safe, but I also think it isn't a significant\n>     improvement for workflows that leave lots of stale branches around\n>     (they clutter the push output).\n>   - omit stale listings when -v is not given?\n>     - this is dangerous with the patch I posted, because \"git push; #\n>       oops, I forgot I amended; git push -f\" will push stale branches\n>       that weren't even mentioned in the first case.\n>     - instead, should we require some extra magic to force stale\n>       branches to be pushed? Forcing such a push is almost never a good\n>       idea, whereas forked branches are not too uncommon.\n>     - instead, should we disallow \"-f\" without an explicit refspec (or\n>       --all, or --mirror, etc) I can't think of a workflow where you\n>       want to force _many_ branches at once, except the special case of\n>       mirroring.\n>     - we could also combine the two: don't respect -f on stale pushes,\n>       but do respect pushing \"+stale\"\n>\n> Thoughts?\n\nI think the \"push -f is unsafe and forbidden unless you are\nusing --all, --mirror or being explicit\" is extremely sensible,\nwith or without the \"omit [stale] unless -v\".  You can even\nthrow in --matching to the mix.\n\nBy the way, I am not opposed to adding --matching to push.  Just\ndon't make anything but --matching the default, nor introduce\nconfiguration, in the first round.  We might want to do that\nlater when we have a solid migration path.  I just still do not\nthink it is necessary to make a backward incompatible changes.\n\nWhen your workflow is to work against a shared more-or-less\ncentral repository with many branches, I think it is reasonable\nto want be able to push out the work in your current branch and\nnothing else after you are done with a change you made in your\nbranch and are convinced that it is in a good enough shape to be\nshared with others,\n\nWhen the --matching behaviour was made the default at the very\nbeginning, the prevalent git workflow was not about a shared\nrepository, but to work with a set of _owned_ public\ndistribution points.  Also the model strongly discouraged the\ndeveloper to be unorganized.  You use \"matching\" push only when\nyour public branches in your private working area are all good\nand ready.  You can still work on private topic branches to\nbuild on top of what are \"public\" all you want, but until you\nare ready, you do not start merging your half-baked ideas you\nhave on your topic to the \"matching\" branches.  Because the\nrepositories you would be pushing into are owned by you, there\nis no \"staleness\" issue with it, as long as you worked that way.\nThe branches are either ready or unchanged, as long as you are\norganized well enough.\n\nBut with a central shared repository, even if you are well\norganized and your changes to your \"matching\" branches are\nready, your other branches can now go \"stale\".  It is a new\nproblem \"sharedness\" introduces.\n\nSo in that sense, not showing individual [stale] branches by\ndefault would be a sensible solution to that new problem.  The\nsolution does not break existing users.  We may even want to\nsquelch down [failed] somewhat, because the users may have WIP\non their matching topics that have diverged but are not ready to\nbe pushed out.  So perhaps saying \"N stale branches and M\ndiverged branches did not get pushed out\" at the end might be a\ngood idea, even when run without -v option.\n\nHOWEVER.\n\nIt is only half a solution.  It still requires you to be well\norganized for you to use \"matching\" semantics.\n\nFor example, if you did this:\n\n\t$ git checkout -b origin/ticket-99 ticket-99\n        $ hack hack half baked hack well that does not work blech\n        $ git commit -a -m 'WIP: I give up for now'\n\n        $ git checkout -b origin/ticket-47 ticket-47\n        $ hack hack this is easy and I am done\n\t$ test suite runs well\n        $ git commit -a -m 'Fixed ticket#47 issue'\n\nyou cannot use \"matching\" push without pushing out your\nhalf-baked attempt to fix issue #99 when you are done with\nissue#47.  Instead you would have done this if you are\norganized and really wanted to use \"matching\":\n\n\t$ git checkout -b origin/ticket-99 ticket-99\n        $ hack hack half baked hack well that does not work blech\n        $ git commit -a -m 'WIP: I give up for now'\n\t$ git branch -m wip-ticket-99\n\n        $ git checkout -b origin/ticket-47 ticket-47\n        $ hack hack this is easy and I am done\n\t$ test suite runs well\n        $ git commit -a -m 'Fixed ticket#47 issue'\n        $ some other cleanups, perhaps rebase -i to make it presentable\n\t$ test suite runs well\n        $ git push\n\nBut I tend to think it is easier to train your finger to say\n\"git push origin ticket-47\" (or \"HEAD\").  New user questions\nwould also become easier and unambiguous to deal with, as\nmentioned in another message in that \"[rejected]\" thread.\n\nBy the way, we might want to add\n\n\t$ git checkout -B origin/ticket-74\n\nthat pretends the user said \"-b origin/ticket-74 ticket-74\" by\nstripping the \"remote/$nick\" part of the dwimmed starting point\nref to come up with the local refname.\n"}]}