Junio C Hamano | 20 Jun 01:46 2012
Picon

What's cooking in git.git (Jun 2012, #05; Tue, 19)

Here are the topics that have been cooking.  Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.

Now 1.7.11 is out, I'll start merging topics that have been cooking
in 'next' to 'master', but let's wait for a few days in case some
brown paper bag bugfixes are needed.

You can find the changes described here in the integration branches of the
repositories listed at

    http://git-blame.blogspot.com/p/git-public-repositories.html

--------------------------------------------------
[New Topics]

* cn/cherry-pick-range-docs (2012-06-15) 2 commits
 - git-cherry-pick.txt: clarify the use of revision range notation
 - Documentation: --no-walk is no-op if range is specified

Will merge to 'next' and soon to 'master'.

* jc/sha1-name-more (2012-06-18) 9 commits
 - sha1_name.c: get_describe_name() by definition groks only commits
 - sha1_name.c: teach get_short_sha1() a commit-only option
 - sha1_name.c: allow get_short_sha1() to take other flags
 - sha1_name.c: teach find_short_packed_object() a commit-only option
 - sha1_name.c: teach find_short_object_filename() a commit-only option
 - sha1_name.c: refactor find_short_packed_object()
 - sha1_name.c: rename "now" to "current"
 - sha1_name.c: clarify what "fake" is for in find_short_object_filename()
(Continue reading)

Matthieu Moy | 20 Jun 14:35 2012
Picon
Picon

[PATCH] push: start warning upcoming default change for push.default

In preparation for flipping the default to the "simple" mode from
the "matching" mode that is the historical default, start warning
users when they rely on unconfigured "git push" to default to the
"matching" mode.

Also, advertise for 'simple' where 'current' and 'upstream' are advised.

Signed-off-by: Matthieu Moy <Matthieu.Moy <at> imag.fr>
Signed-off-by: Junio C Hamano <gitster <at> pobox.com>
---
> * mm/push-default-switch-warning (2012-06-06) 1 commit
>  - push: start warning upcoming default change for push.default
> 
> Will merge to 'next'.
> 
> Hopwefully we can have a solidly tested series early in 1.7.12 or
> 1.7.13 at the latest.

I've made a slightly modified version of the patch which adds these
two lines:

+   "(the 'simple' mode was introduced in Git 1.7.11. Use 'current' instead if\n"
+   "you sometimes use older versions of Git)");

I actually had problems setting "push.default=upstream" on a
NFS-shared $HOME, where one machine was running a brand new Git, and
another the old version from Debian stable, who didn't know about the
upstream mode. The old machine started refusing pushes because of
this :-(.

(Continue reading)

Junio C Hamano | 20 Jun 19:55 2012
Picon
Picon

Re: [PATCH] push: start warning upcoming default change for push.default

Matthieu Moy <Matthieu.Moy <at> imag.fr> writes:

> In preparation for flipping the default to the "simple" mode from
> the "matching" mode that is the historical default, start warning
> users when they rely on unconfigured "git push" to default to the
> "matching" mode.
>
> Also, advertise for 'simple' where 'current' and 'upstream' are advised.
>
> Signed-off-by: Matthieu Moy <Matthieu.Moy <at> imag.fr>
> Signed-off-by: Junio C Hamano <gitster <at> pobox.com>
> ---
>> * mm/push-default-switch-warning (2012-06-06) 1 commit
>>  - push: start warning upcoming default change for push.default
>> 
>> Will merge to 'next'.
>> 
>> Hopwefully we can have a solidly tested series early in 1.7.12 or
>> 1.7.13 at the latest.
>
> I've made a slightly modified version of the patch which adds these
> two lines:
>
> +   "(the 'simple' mode was introduced in Git 1.7.11. Use 'current' instead if\n"
> +   "you sometimes use older versions of Git)");

I am not sure who this wants to help.  For people who want to
anticipate the future, using anything but 'simple' is not living in
the future and waiting for an additional pain coming from the
differences between current and simple.  If current and simple are
(Continue reading)

Matthieu Moy | 20 Jun 20:24 2012
Picon

Re: [PATCH] push: start warning upcoming default change for push.default

Junio C Hamano <gitster <at> pobox.com> writes:

> I am not sure who this wants to help.

The target is for people who may use different versions of Git (e.g.
several installed git on the same machine, several machine, or worse,
several machines with a shared $HOME/.gitconfig). This includes me.

For these people, setting push.default=simple is basically impossible
since Git errors out when encountering such setting (it's not ignored,
it really makes Git die).

> For people who want to anticipate the future, using anything but
> 'simple' is not living in the future and waiting for an additional
> pain coming from the differences between current and simple. If
> current and simple are similar enough that their differences do not
> matter, why wait for simple to be available everywhere and switch the
> default to it, instead of using current as the default in the first
> place?

'simple' is an improvement over 'current' as a default, especially for
beginners, but 'current' is already reasonably good.

So, the long term goal is really to switch to 'simple', but people who
use different versions of Git won't be able to use it before a few
years. These people have several options:

1) Keep push.default unset. This is not acceptable because they don't
   want the big fat warning each time they push.

(Continue reading)

Junio C Hamano | 20 Jun 21:31 2012
Picon
Picon

Re: [PATCH] push: start warning upcoming default change for push.default

Matthieu Moy <Matthieu.Moy <at> grenoble-inp.fr> writes:

> So, the long term goal is really to switch to 'simple', but people who
> use different versions of Git won't be able to use it before a few
> years. These people have several options:
>
> 1) Keep push.default unset. This is not acceptable because they don't
>    want the big fat warning each time they push.

Yes, to them one of 'simple', 'current' or 'upstream' would be
sensible (but they need to read up on them to see which one they
want).

> 2) Set push.default to 'matching', to keep the old behavior and squelsh
>    the warning. If they go this way, they will never see the default
>    change.

This is not the audience of the quoted part of the message i.e. "If
you want to use it before default changes".  These people fall into
the "If you want to keep the current default, set push.default to
'matching'" category, so it is irrelevant to the discussion.

> 3) Set push.default to 'current', in which case they have the same
>    behavior as 'simple', except for the safety feature of 'simple'
>    (refuse to push when the name doesn't match the upstream). They can't
>    expect anything better anyway since they are sometimes using a
>    machine which doesn't support 'simple' anyway.

And they will be frozen to 'current' even after their sysadmins
update the version of git that support 'simple'.  
(Continue reading)

Matthieu Moy | 20 Jun 21:45 2012
Picon

Re: [PATCH] push: start warning upcoming default change for push.default

Junio C Hamano <gitster <at> pobox.com> writes:

>> 3) Set push.default to 'current', in which case they have the same
>>    behavior as 'simple', except for the safety feature of 'simple'
>>    (refuse to push when the name doesn't match the upstream). They can't
>>    expect anything better anyway since they are sometimes using a
>>    machine which doesn't support 'simple' anyway.
>
> And they will be frozen to 'current' even after their sysadmins
> update the version of git that support 'simple'.  

And so what? They will miss the safety feature of 'simple', but that's
not really a big deal.

'simple' was not really designed to be _better_ than current or
upstream, but to be more adapted as a default value, because 1) it's
safer, so nice for beginners and 2) follows the least surprise
principle, as it does nothing in cases where there would be an
ambiguity. But once you're not really a beginner, the added value of
'simple' is really small compared to 'current' or 'upstream'.

> Telling somebody who would blindly follow what was suggested to use
> 'current' is what bothers me.

But what alternative do we have?

You suggest that I remove the mention of 'current', but then what should
users do? Removing it sounds like replacing it with "if you sometimes
use older versions of Git, you're doomed, sorry" to me.

(Continue reading)

Junio C Hamano | 20 Jun 21:51 2012
Picon
Picon

Re: [PATCH] push: start warning upcoming default change for push.default

Junio C Hamano <gitster <at> pobox.com> writes:

> Telling somebody who would blindly follow what was suggested to use
> 'current' is what bothers me.

That is (quoting the difference between the previous round and this
one),

 static char warn_unspecified_push_default_msg[] =
 N_("push.default is unset; its implicit value is changing in\n"
    "Git 2.0 from 'matching' to 'simple'. To squelch this message\n"
    "and maintain the current behavior after the default changes, use:\n"
    "\n"
    "  git config --global push.default matching\n"
    "\n"
    "To squelch this message and adopt the new behavior now, use:\n"
    "\n"
    "  git config --global push.default simple\n"
    "\n"
-   "See 'git help config' and search for 'push.default' for further information.");
+   "See 'git help config' and search for 'push.default' for further information.\n"
+   "(the 'simple' mode was introduced in Git 1.7.11. Use 'current' instead if\n"
+   "you sometimes use older versions of Git)");

The latter half of the message is "To *adopt* the *new behaviour
now*" but setting it to 'current' is not adopting the new behaviour.

Perhaps we should say more to help people decide which one to choose
in this message.

(Continue reading)

Matthieu Moy | 21 Jun 17:50 2012
Picon

Re: [PATCH] push: start warning upcoming default change for push.default

Junio C Hamano <gitster <at> pobox.com> writes:

> Perhaps we should say more to help people decide which one to choose
> in this message.
[...]
>     You can squelch this message by picking your preferred default now,
>     e.g. running one of these:
>
>             git config push.default matching
>             git config push.default simple
>             git config push.default current

I don't see any added value. Seeing this, it's less clear to the user,
and he may chose 'simple', and then complain that it breaks his older
Git. Really, if 'simple' isn't an option for someone, why should we make
this someone think before chosing between 'current' an 'simple'?

Also, my version purposely made 'simple' more visible than 'current'
(cut-and-paste ready alone on its line Vs within parenthesis), because
this is the one we want to advertise. Putting the 3 options at the same
level is a regression to me.

We can rephrase the advice to make it clearer that 'simple' !=
'current', like

  (the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
  'current' instead if you sometimes use older versions of Git)

--

-- 
Matthieu Moy
(Continue reading)

Junio C Hamano | 21 Jun 19:00 2012
Picon
Picon

Re: [PATCH] push: start warning upcoming default change for push.default

Matthieu Moy <Matthieu.Moy <at> grenoble-inp.fr> writes:

> Junio C Hamano <gitster <at> pobox.com> writes:
>
>> Perhaps we should say more to help people decide which one to choose
>> in this message.
> [...]
>>     You can squelch this message by picking your preferred default now,
>>     e.g. running one of these:
>>
>>             git config push.default matching
>>             git config push.default simple
>>             git config push.default current
>
> I don't see any added value. Seeing this, it's less clear to the user,
> and he may chose 'simple', and then complain that it breaks his older
> Git. 

Re-read the part you omitted with [...].  Doesn't it say something
about "only available"?

> Really, if 'simple' isn't an option for someone, why should we make
> this someone think before chosing between 'current' an 'simple'?

This is not about choosing between simple and current when both are
available.  As [...] part tries to clearly state (and if it is
unclear, please clarify it further), the new default "simple" is
only available in certain versions, and 'current' is the closest
approximation for other versions.  So even though there are three
choices, it is really about choosing between 'matching' (push all
(Continue reading)

Matthieu Moy | 21 Jun 19:08 2012
Picon

Re: [PATCH] push: start warning upcoming default change for push.default

Junio C Hamano <gitster <at> pobox.com> writes:

> Re-read the part you omitted with [...].  Doesn't it say something
> about "only available"?

It does, but it seems you're trying hard to avoid telling the user "you
should use 'current'", where 'current' is the only reasonable option for
this user. I still don't understand what problem you're trying to solve.

--

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Junio C Hamano | 21 Jun 19:21 2012
Picon
Picon

Re: [PATCH] push: start warning upcoming default change for push.default

Matthieu Moy <Matthieu.Moy <at> grenoble-inp.fr> writes:

> Junio C Hamano <gitster <at> pobox.com> writes:
>
>> Re-read the part you omitted with [...].  Doesn't it say something
>> about "only available"?
>
> It does, but it seems you're trying hard to avoid telling the user "you
> should use 'current'", where 'current' is the only reasonable option for
> this user. I still don't understand what problem you're trying to solve.

I am avoiding to say "you should use simple/current".  Choice
between matching and simple/current is for the user to make (mostly
dictated by the project's workflow) and we cannot make a suggestion
better than what user knows.

Choice between simple and current is mechanically derivable. If the
user also uses older version of git, simple is not an option.
Junio C Hamano | 21 Jun 19:46 2012
Picon
Picon

Re: [PATCH] push: start warning upcoming default change for push.default

Junio C Hamano <gitster <at> pobox.com> writes:

> Matthieu Moy <Matthieu.Moy <at> grenoble-inp.fr> writes:
>
>> Junio C Hamano <gitster <at> pobox.com> writes:
>>
>>> Re-read the part you omitted with [...].  Doesn't it say something
>>> about "only available"?
>>
>> It does, but it seems you're trying hard to avoid telling the user "you
>> should use 'current'", where 'current' is the only reasonable option for
>> this user. I still don't understand what problem you're trying to solve.
>
> I am avoiding to say "you should use simple/current".  Choice
> between matching and simple/current is for the user to make (mostly
> dictated by the project's workflow) and we cannot make a suggestion
> better than what user knows.
>
> Choice between simple and current is mechanically derivable. If the
> user also uses older version of git, simple is not an option.

To put it another way, I am questioning your "where 'current is the
only reasonable option for this user".  If it were truly the case,
why would we be issuing a warning message?  Wouldn't we be instead
silently doing what 'simple' or 'current' would do?

The reason why we have this message is because either "push the
current one and not others" or "push all relevant ones, regardless
of the current" are reasonable choices depending on the user, and
because we had to choose one for the default, we previously chose
(Continue reading)

Matthieu Moy | 22 Jun 09:57 2012
Picon

Re: [PATCH] push: start warning upcoming default change for push.default

Junio C Hamano <gitster <at> pobox.com> writes:

> Matthieu Moy <Matthieu.Moy <at> grenoble-inp.fr> writes:
>
>> Junio C Hamano <gitster <at> pobox.com> writes:
>>
>>> Re-read the part you omitted with [...].  Doesn't it say something
>>> about "only available"?
>>
>> It does, but it seems you're trying hard to avoid telling the user "you
>> should use 'current'", where 'current' is the only reasonable option for
>> this user. I still don't understand what problem you're trying to solve.
>
> I am avoiding to say "you should use simple/current".  Choice
> between matching and simple/current is for the user to make (mostly
> dictated by the project's workflow) and we cannot make a suggestion
> better than what user knows.
>
> Choice between simple and current is mechanically derivable. If the
> user also uses older version of git, simple is not an option.

I do agree with that. My message tells the user to use 'current' instead
of 'simple' when not appropriate, not to use 'current' instead of
'matching', which would indeed be a nonsense. I thought it was clear
enough, but we can make that more explicit. How about:

  (the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
  'current' instead of 'simple' if you sometimes use older versions of Git)

--

-- 
(Continue reading)

Junio C Hamano | 22 Jun 19:48 2012
Picon
Picon

Re: [PATCH] push: start warning upcoming default change for push.default

Matthieu Moy <Matthieu.Moy <at> grenoble-inp.fr> writes:

> I do agree with that. My message tells the user to use 'current' instead
> of 'simple' when not appropriate, not to use 'current' instead of
> 'matching', which would indeed be a nonsense. I thought it was clear
> enough, but we can make that more explicit. How about:
>
>   (the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
>   'current' instead of 'simple' if you sometimes use older versions of Git)

Yeah, that would work (the minority that need to pick 'current'
cannot cut and paste, but that is not a big deal).

As I did not butcher the version you sent me when I queued it with
my rewrite, a follow-up patch to update it should be fairly minimal
;-)

Thanks.

Matthieu Moy | 24 Jun 13:01 2012
Picon
Picon

[PATCH] push: start warning upcoming default change for push.default

In preparation for flipping the default to the "simple" mode from
the "matching" mode that is the historical default, start warning
users when they rely on unconfigured "git push" to default to the
"matching" mode.

Also, advertise for 'simple' where 'current' and 'upstream' are advised.

Signed-off-by: Matthieu Moy <Matthieu.Moy <at> imag.fr>
Signed-off-by: Junio C Hamano <gitster <at> pobox.com>
---
Junio C Hamano <gitster <at> pobox.com> writes:

>>   (the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
>>   'current' instead of 'simple' if you sometimes use older versions of Git)
>
> Yeah, that would work (the minority that need to pick 'current'
> cannot cut and paste, but that is not a big deal).
>
> As I did not butcher the version you sent me when I queued it with
> my rewrite, a follow-up patch to update it should be fairly minimal
> ;-)

Here it is.

 builtin/push.c       | 29 +++++++++++++++++++++++++++--
 t/t5541-http-push.sh |  5 ++++-
 2 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/builtin/push.c b/builtin/push.c
index 08ccb89..9a0a035 100644
(Continue reading)


Gmane