Re: git push default behaviour?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:

> Here's an attempt to an improved message. The first paragraph is here to
> make sure people understand their opinion counts (before they stop
> reading because it's too long). The rest explains the change and the way
> to get involved:

Sounds OK from a cursory read, except for a few minor details.

Thanks.  Nitpicks follow.

> ---------- 8< ---------- 8< -----------
>
> There is a proposal to change the default behaviour of 'git push'
> on the Git mailing list. The goal of this message is to encourage you
> to discuss it before it happens (or the change is aborted, depending
> on the outcome of the discussion).
>
> In the current setting (i.e. push.default=matching), 'git push' without
> argument will push all branches that exist locally and remotely with
> the same name. This is usually appropriate when a developer pushes to
> his own public repository, but confusing if not dangerous when using a
> shared repository. The proposal is to change the default to

"usually appropriate" tries to avoid claiming that this statement is
the final judgement.  "confusing" may need to be stated the same
way, i.e. "but may be confusing".  Alternatively, we can drop "usually".

> 'upstream', i.e. push only the current branch, and push it to the
> upstream branch (the one 'git pull' would pull from). 'current' is
> another candidate.

When I find myself needing to clarify a jargon with parenthesized
rephrase, I drop the jargon and parentheses and see if it makes it
easier to read.  And in this case I think it does.

    i.e. push only the current branch to the branch 'git pull' would
    pull from.

What 'upstream' does is explained but not 'current'; here is my
attempt.

    Another candidate is 'current'; this pushes only the current
    branch to the branch of the same name.

> For more details on the behavior of Git with these values, read
> the documentation about 'push.default' in 'man git-config'
> (http://schacon.github.com/git/git-config.html).
>
> You may be negatively affected when such a change happens if you
> do not see anything in the output from 'git config push.default'
> and if you rely on the fact that 'git push' pushes all your
> matching branches. On the other hand, you may want to see the

Let's stress that they are relying on the _default_ a bit stronger.

    "and if you rely on the default that pushes all your"

> default behaviour to change, especially if you are using shared
> repositories. In either case, please join the discussion to give
> us more data point and help us decide the future of Git.

> To join the discussion, send your messages to: git@xxxxxxxxxxxxxxx
> You don't need to subscribe the list to post, and it's customary to
> Cc: posters when replying on this list.
> To view the current discussion, see this thread:
> http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694

As this is not an invitation to start a new discussion, "speak
without reading what have already been said" is not something we
would want to encourage, so I'd prefer to see the order swapped, like

	What has been discussed so far can be seen in these threads:

        	... gmane references ...

        To join the discussion, send your messages to: git@xxxxxxxxxxxxxxx
        The list accepts messages from non-subscribers, and you do
        not have to ask "please Cc me, I am not subscribed", as it's
        customary to Cc: posters when replying on this list.
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]