On Tue, Feb 19, 2008 at 01:34:40PM -0800, Junio C Hamano wrote:
> Distinguishing between [rejected] and [stale] would belong in
> 1.5.5 if it is really needed. Together with the "git checkout
> notices forks" enhancement on Daniel's git-checkout rewritten in
> C, I think it would solve the issue in the "push [rejected]
> question".
I am still a little uncomfortable with the rejected/stale distinction,
because the semantics aren't clear.
Let's say we figure out which is which in send-pack. Do we:
- simply change the "rejected" text to "stale, and leave as-is? I
think that is safe, but I also think it isn't a significant
improvement for workflows that leave lots of stale branches around
(they clutter the push output).
- omit stale listings when -v is not given?
- this is dangerous with the patch I posted, because "git push; #
oops, I forgot I amended; git push -f" will push stale branches
that weren't even mentioned in the first case.
- instead, should we require some extra magic to force stale
branches to be pushed? Forcing such a push is almost never a good
idea, whereas forked branches are not too uncommon.
- instead, should we disallow "-f" without an explicit refspec (or
--all, or --mirror, etc) I can't think of a workflow where you
want to force _many_ branches at once, except the special case of
mirroring.
- we could also combine the two: don't respect -f on stale pushes,
but do respect pushing "+stale"
Thoughts?
-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
