git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Jul 2013, #02; Fri, 5)
Date: Sat, 06 Jul 2013 21:00:28 -0700	[thread overview]
Message-ID: <7vwqp3589v.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20130707003531.GG30132@google.com> (Jonathan Nieder's message of "Sat, 6 Jul 2013 17:35:31 -0700")

Jonathan Nieder <jrnieder@gmail.com> writes:

>> We are in the middle of 5th week now in the 11-week releace cycle
>> for 1.8.4 (http://tinyurl.com/gitCal), and quite a few topics have
>> graduated to 'master'.  I'd expect the rest of the week to be slow.
>
> I'd like this or the next release to be 2.0, so the common user
> trouble with "git push" pushing more branches than they intended can
> be over.  Am I crazy?  If not, what can I do to help make it happen?

There are currently three topics slated for 2.0 that changes the
default behaviours in a big way.  The default of the push behaviour
switching from matching to simple is one of them, and it has been
advertised with advice messages since 1.8.0 (Oct 2012).

The other two, "git add -u/-A" without pathspec to operate on the
entire tree, and "git add" with pathspec acting as if it were given
"-A" option to also record removals to the index, haven't had enough
time to be imprinted in users' minds.  The former was only mentioned
in the release notes of 1.8.2 (Mar 2013), and the advertisement for
the latter change appeared first in 1.8.3 (May 2013).

I'd prefer to see users have enough time to adjust to these big
changes, at least 6 months (but preferrably 9 months).  I would say
that the change to the default "git push" behaviour may have had
enough preparation period, but the other two that are scheduled for
2.0 is way too young.

With recent "triangular" addition by Ram, the "simple" mode, the
future behaviour of "git push", was again changed, and has not have
enough time to mature (isn't it still in 'next'?).

Regarding that "simple" thing, I am not sure if the "if you are
pushing to a remote that is different from where you fetch from, we
do exactly the same as 'current'", which is what we tentatively
agreed to implement, is safe enough for new people.  I suspect we
may want to tighten it a bit more (it would update the branch with
the same name as your current local branch, but never try to create
such a branch at the remote, for example).

So in that sense, even the change to "git push" default may not be
old enough for the upcoming release or the next one.

      reply	other threads:[~2013-07-07  4:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-05  9:09 What's cooking in git.git (Jul 2013, #02; Fri, 5) Junio C Hamano
2013-07-07  0:35 ` Jonathan Nieder
2013-07-07  4:00   ` Junio C Hamano [this message]

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vwqp3589v.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).