git push default behaviour?

git push default behaviour?

[Jeremy Morton]

Hi everyone,

I've noticed that the default behaviour of 'git push' is to push to
*all* branches that have a remote branch set up.  In order to push
just to one branch, you must specify 'git push repo branchname'.

This seems rather unintuative to me, and in the case of a '--force',
almost certainly not what you want.  You're usually working on one
branch and just want to push that one, and it's usually the branch
you're currently on. And in the case of a '--force', in addition by
pushing all branches to remote, you are going to undo any changes on
other branches made since you updated them on your local repo.

Wouldn't it be better for git's default push behaviour (at least with
the '--force' option) to be just to push to the current branch in the
current repo?  To push to all branches you could have an
'--allbranches' option.

Best regards,
Jeremy Morton (Jez)

Re: git push default behaviour?

[Thomas Rast]

Jeremy Morton <jeremy@configit.com> writes:

> I've noticed that the default behaviour of 'git push' is to push to
> *all* branches that have a remote branch set up.
[...]
> Wouldn't it be better for git's default push behaviour (at least with
> the '--force' option) to be just to push to the current branch in the
> current repo?  To push to all branches you could have an
> '--allbranches' option.

See push.default in git-config(1).

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: git push default behaviour?

[Jeremy Morton]

Right, so I guess I'm saying that the default value for push.default
should be upstream instead of matching...

Best regards,
Jeremy Morton (Jez)

On Thu, Mar 8, 2012 at 10:11 AM, Thomas Rast <trast@inf.ethz.ch> wrote:
> Jeremy Morton <jeremy@configit.com> writes:
>
>> I've noticed that the default behaviour of 'git push' is to push to
>> *all* branches that have a remote branch set up.
> [...]
>> Wouldn't it be better for git's default push behaviour (at least with
>> the '--force' option) to be just to push to the current branch in the
>> current repo?  To push to all branches you could have an
>> '--allbranches' option.
>
> See push.default in git-config(1).
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch

Re: git push default behaviour?

[Carlos Martín Nieto]

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

On Thu, 2012-03-08 at 10:13 +0000, Jeremy Morton wrote:
> Right, so I guess I'm saying that the default value for push.default
> should be upstream instead of matching...

Any default is going to leave some people unhappy. If upstream is the
right thing for you, then that's what you should use. Most questions I
see about push not doing what the users expect would actually benefit
from 'current'. 'matching' is a fairly safe default, as it won't try to
push private branches or changes in private branches that track
something upstream.

   cmn



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: git push default behaviour?

[Jeremy Morton]

But 'push --force' WILL try to push your (probably outdated) master
upstream, killing any changes there made since you last updated.  That
alone is so dangerous it seems like reason enough to avoid it by
default.

Best regards,
Jeremy Morton (Jez)

On Thu, Mar 8, 2012 at 10:28 AM, Carlos Martín Nieto <cmn@elego.de> wrote:
> On Thu, 2012-03-08 at 10:13 +0000, Jeremy Morton wrote:
>> Right, so I guess I'm saying that the default value for push.default
>> should be upstream instead of matching...
>
> Any default is going to leave some people unhappy. If upstream is the
> right thing for you, then that's what you should use. Most questions I
> see about push not doing what the users expect would actually benefit
> from 'current'. 'matching' is a fairly safe default, as it won't try to
> push private branches or changes in private branches that track
> something upstream.
>
>   cmn
>
>

Re: git push default behaviour?

[Carlos Martín Nieto]

On Thu, 2012-03-08 at 10:38 +0000, Jeremy Morton wrote:
> But 'push --force' WILL try to push your (probably outdated) master
> upstream, killing any changes there made since you last updated.  That
> alone is so dangerous it seems like reason enough to avoid it by
> default.

Then don't use --force without specifying exactly what you want.
Anything with that option needs to be used carefully.

   cmn

Re: git push default behaviour?

[Jeremy Morton]

Obviously - but my point is that it needn't be so dangerous by
default.  It tries to push all matching branches - is that really a
more common requirement than pushing the current branch?

Best regards,
Jeremy Morton (Jez)

On Thu, Mar 8, 2012 at 10:42 AM, Carlos Martín Nieto <cmn@elego.de> wrote:
> On Thu, 2012-03-08 at 10:38 +0000, Jeremy Morton wrote:
>> But 'push --force' WILL try to push your (probably outdated) master
>> upstream, killing any changes there made since you last updated.  That
>> alone is so dangerous it seems like reason enough to avoid it by
>> default.
>
> Then don't use --force without specifying exactly what you want.
> Anything with that option needs to be used carefully.
>
>   cmn
>
>

Re: git push default behaviour?

[Junio C Hamano]

Jeremy Morton <jeremy@configit.com> writes:

> Obviously - but my point is that it needn't be so dangerous by
> default.  It tries to push all matching branches - is that really a
> more common requirement than pushing the current branch?

Depends on the way you work. If you publish to your own repository
and let others pull, the behaviour is not dangerous at all with or
without --force (well, --force brings its own danger but that does
not have anything to do with which branches are pushed).  If you
default to 'current' in such a workflow, you risk forgetting to
push, which is the more dangerous option between the two.

When using a single shared central repository to work with others,
current may be more appropriate, and that is why the behaviour is
configurable.

Re: git push default behaviour?

[Matthieu Moy]

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

> If you publish to your own repository
> and let others pull, the behaviour is not dangerous at all with or
> without --force (well, --force brings its own danger but that does
> not have anything to do with which branches are pushed).  If you
> default to 'current' in such a workflow, you risk forgetting to
> push, which is the more dangerous option between the two.

Forgetting to push a branch is a danger, but far less dangerous than
what "push --force" can do in a shared repository.

In a shared repository, there's actually a race condition that you
cannot avoid AFAICT:

$ git push
 # get an error about non-fast-forward on branch A, but no other.
 # thing "it's OK, I do want to do a forced update on A".
$ git push --force

If someone else did a push between my first push and the "push --force",
then the other user's push is discarded.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: git push default behaviour?

[Andreas Krey]

On Thu, 08 Mar 2012 19:35:51 +0000, Matthieu Moy wrote:
...
> If someone else did a push between my first push and the "push --force",
> then the other user's push is discarded.

A push --semiforce would help here: Should check whether the remote
branch is at the same commit as origin/master locally, and only then set
to new local master. (Would probably require protocol change to actuall
be atomic.)

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: git push default behaviour?

[Junio C Hamano]

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

> Junio C Hamano <gitster@pobox.com> writes:
>
>> If you publish to your own repository
>> and let others pull, the behaviour is not dangerous at all with or
>> without --force (well, --force brings its own danger but that does
>> not have anything to do with which branches are pushed).  If you
>> default to 'current' in such a workflow, you risk forgetting to
>> push, which is the more dangerous option between the two.
>
> Forgetting to push a branch is a danger, but far less dangerous than
> what "push --force" can do in a shared repository.
>
> In a shared repository, there's actually a race condition that you
> cannot avoid AFAICT:
> ...
> If someone else did a push between my first push and the "push --force",
> then the other user's push is discarded.

That is exactly what I said in the parentheses above, isn't it?  The
danger of "--force" does not have anything to do with which branches
are pushed. It comes primarily from the use of shared repository.
The first advice Carlos gave us in this thread, which was perfectly
sane, applies to your observation: before you "push --force", think
twice.

That does not change the conclusion that current is more suitable
for shared repository workflow and matching is more (not "equally to
current") suitable for publishing repository workflow, and we have a
way for user to tell Git which one is being used in a particular
project exactly for that purpose.

Re: git push default behaviour?

[Matthieu Moy]

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

> That is exactly what I said in the parentheses above, isn't it?  The
> danger of "--force" does not have anything to do with which branches
> are pushed.

I disagree. A user may use --force because he has good reason to think
that a branch hasn't been been touched by others, but it's much harder
to guarantee that all branches haven't been touched.

> That does not change the conclusion that current is more suitable
> for shared repository workflow and matching is more (not "equally to
> current") suitable for publishing repository workflow, and we have a
> way for user to tell Git which one is being used in a particular
> project exactly for that purpose.

We're not talking about the same thing. You're talking about how
_appropriate_ a value is, and I'm mentionning how _dangerous_ it can be.

And regardless of the danger, if I look around me, I see almost only
people working with shared archives, and a few projects (including Git,
obviously) using the "one commiter per repository" workflow (I teach Git
to 200 students and several colleagues every year, I've tried teaching
the "one public repository per developer" and it was a complete disaster).

I really think the default should help these people.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: git push default behaviour?

[Junio C Hamano]

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

> And regardless of the danger, if I look around me, I see almost only
> people working with shared archives, and a few projects (including Git,
> obviously) using the "one commiter per repository" workflow (I teach Git

These days, you do not have to even go to kernel.org to find people
and projects that use "publish to be pulled" model.  I hear that
there is a popular site called GitHub where people create their own
fork, publish their work there and ask the project they forked from
to pull their work.

By the way, don't we ask the workflow used by the users in the
annual user survey?

> to 200 students and several colleagues every year, I've tried teaching
> the "one public repository per developer" and it was a complete disaster).

Interesting.  I have a couple of questions.

Who are these 200 people and what do they do with Git?  If the
answer is "They work on a class assignment project, 20 teams of 10
members each", I would count that as a datapoint that represents one
project among thousands of projects that use Git.

I am also curious to learn a bit more about "a complete disaster",
even though this question (and its answer) would not be directly
relevant to this topic, as nobody is trying to convert projects to
use the "publish to be pulled" model when the "push to the shared
central repository" model is more appropriate for them.

Re: git push default behaviour?

[Jeremy Morton]

On Fri, Mar 9, 2012 at 9:50 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> And regardless of the danger, if I look around me, I see almost only
>> people working with shared archives, and a few projects (including Git,
>> obviously) using the "one commiter per repository" workflow (I teach Git
>
> These days, you do not have to even go to kernel.org to find people
> and projects that use "publish to be pulled" model.  I hear that
> there is a popular site called GitHub where people create their own
> fork, publish their work there and ask the project they forked from
> to pull their work.

Github also offer a paid service where you can host private
repositories, which you're probably going to work on as part of a team
in a business.  FWIW, I discovered the problem with this default
behaviour because someone accidentally did a 'git push --force' to our
github repo.  There is currently no hook mechanism with github that
allows you to abort a push, either, so you can't stop the problem that
way.

Best regards,
Jeremy Morton (Jez)

Re: git push default behaviour?

[Matthieu Moy]

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

>> to 200 students and several colleagues every year, I've tried teaching
>> the "one public repository per developer" and it was a complete disaster).
>
> Interesting.  I have a couple of questions.
>
> Who are these 200 people and what do they do with Git?  If the
> answer is "They work on a class assignment project, 20 teams of 10
> members each",

Teams are smaller, but that's essentially that, yes. I'm not saying it's
representative, my point just that I do have experience teaching Git to
new users.

> I am also curious to learn a bit more about "a complete disaster",

There are several points:

* It is often the case that one of the member of a team is more
  knowledgeable than others. Then, this user can set up a shared
  archive, and other users do not have to. When your project is
  open-source, it's rather easy to click GitHub's web interface and
  create a fork, but when it's a private project (and you don't want to
  pay), you have to do some kind of magic with ACLs or so to create a
  new repository. Doing this magic just once saves a lot of trouble.

  In practice, when working with colleagues (all being computer
  scientists), if I don't set up a shared repository, they just send me
  their files (yes, their files, not their patches :-( ) by email and
  ask me to do merges if needed.

* Users like to know where "the latest version" is. They are already
  confused by the fact that the last local revision may not be the same
  as the last remote one, and having multiple public repositories adds
  to the confusion.

> even though this question (and its answer) would not be directly
> relevant to this topic, as nobody is trying to convert projects to
> use the "publish to be pulled" model when the "push to the shared
> central repository" model is more appropriate for them.

Sure. I'm not saying in any way that the "shared repository" is
superior. Just that it's easier to grab for newbies.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: git push default behaviour?

[Jakub Narebski]

[I'm sorry if you received duplicate]

Nb. instead of using `--force` to force push of all relevant branches,
you can always force push of single branch with `+branch`...

Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> 
> > And regardless of the danger, if I look around me, I see almost only
> > people working with shared archives, and a few projects (including Git,
> > obviously) using the "one commiter per repository" workflow (I teach Git
> 
> These days, you do not have to even go to kernel.org to find people
> and projects that use "publish to be pulled" model.  I hear that
> there is a popular site called GitHub where people create their own
> fork, publish their work there and ask the project they forked from
> to pull their work.
> 
> By the way, don't we ask the workflow used by the users in the
> annual user survey?

There is "23) How do you publish/propagate your changes?"[1] but it
doesn't tell if responder was using shared repository approach, or one
fork per person approach.

This would be a good question to ask in this year, I think...
 
[1]: https://www.survs.com/results/Q5CA9SKQ/P7DE07F0PL

-- 
Jakub Narebski

Re: git push default behaviour?

[Miles Bader]

Jeremy Morton <jeremy@configit.com> writes:
> Obviously - but my point is that it needn't be so dangerous by
> default.  It tries to push all matching branches - is that really a
> more common requirement than pushing the current branch?

It isn't "so dangerous" by default -- you have to specify --force to
enter "danger" territory, and --force is very clearly a dangerous
option that needs to be approached carefully (someone who uses --force
blindly is going to quickly screw themselves regardless of the
defaults).

-miles

-- 
Zeal, n. A certain nervous disorder afflicting the young and inexperienced.

Re: git push default behaviour?

[Philippe Vaucher]

FWIW I also think we'd change the default to "upstream". The problem
with this default is that most repos only have one branch (master) and
thus they never run into this problem, so most people don't get the
habit to modify push.default AND they get the (bad) habit of typing
"git push". Then they work with multiple branches and get unexpected
pushes (with or without --force, especially when sausage making).

I know it's "their" fault for not learning more about git push's
defaults, but the current default is clearly against the principle of
least surprise IMHO.

Philippe

Re: git push default behaviour?

[Marc Branchaud]

On 12-03-08 05:42 AM, Carlos Martín Nieto wrote:
> On Thu, 2012-03-08 at 10:38 +0000, Jeremy Morton wrote:
>> But 'push --force' WILL try to push your (probably outdated) master
>> upstream, killing any changes there made since you last updated.  That
>> alone is so dangerous it seems like reason enough to avoid it by
>> default.
>
> Then don't use --force without specifying exactly what you want.
> Anything with that option needs to be used carefully.

I agree with Jeremy that the default is dangerous, or at the very least 
surprising.

Perhaps --force should be changed to require an explicit ref if 
push.default = matching (and the code finds that it needs to use 
push.default's value)?

By itself that change would make it impossible to use --force to 
force-change all matching refs (i.e. the current default behaviour would 
disappear completely).  I'm OK with that, personally.

		M.

Re: git push default behaviour?

[Matthieu Moy]

Marc Branchaud <marcnarc@xiplink.com> writes:

> I agree with Jeremy that the default is dangerous, or at the very
> least surprising.

Yes, --force is not the only problem. Getting constant non-fast forward
errors just because you have out-of-date local ref is annoying, and
really, really confusing.

'push.default = matching' is never a good idea if you use shared
repository actually. It makes sense for people like Junio pushing a
local repository to a public one, which is read-only for the rest of the
world. But my experience is that people using such workflow are advanced
users, and would know how to configure Git, so it wouldn't really harm
them to change the default.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: git push default behaviour?

[Dmitry Potapov]

On Thu, Mar 8, 2012 at 7:26 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
>
> 'push.default = matching' is never a good idea if you use shared
> repository actually. It makes sense for people like Junio pushing a
> local repository to a public one, which is read-only for the rest of the
> world. But my experience is that people using such workflow are advanced
> users, and would know how to configure Git, so it wouldn't really harm
> them to change the default.

There are more people that you think who rely on the current behavior
of git push. For instance, pushing changes between different computers
for testing purposes before publishing them. When you silently change
the default value of push, you silently break their workflow. It is not
difficult to add 'push.default = matching' but you need to know that the
default value has changed, so you have to add this line to preserve the
old behavior.

Dmitry

Re: git push default behaviour?

[Matthieu Moy]

Dmitry Potapov <dpotapov@gmail.com> writes:

> When you silently change
> the default value of push, you silently break their workflow.

No one talked about changing it silently. Quoting myself:

| it needs to be done with a sane migration path, however

There is already a configuration variable, so it's easy to fix a default
value change if you rely on it, but the first thing to do is to
encourage people to explicitely set push.default, so that they are not
affected by a potential future default change.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: git push default behaviour?

[Jeff King]

On Thu, Mar 08, 2012 at 07:04:25PM +0100, Matthieu Moy wrote:

> Dmitry Potapov <dpotapov@gmail.com> writes:
> 
> > When you silently change
> > the default value of push, you silently break their workflow.
> 
> No one talked about changing it silently. Quoting myself:
> 
> | it needs to be done with a sane migration path, however
> 
> There is already a configuration variable, so it's easy to fix a default
> value change if you rely on it, but the first thing to do is to
> encourage people to explicitely set push.default, so that they are not
> affected by a potential future default change.

This is all sounding eerily familiar. Indeed:

  $ git log --oneline -Swarn_unconfigured_push -- builtin-push.c
  bba0fd2 push: do not give big warning when no preference is configured
  665d3e8 Display warning for default git push with no push.default config

I don't remember the mailing list conversations that surrounded those
patches, but if we are going to have the same conversation again, maybe
it is worth looking them up.

-Peff

Re: git push default behaviour?

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> This is all sounding eerily familiar. Indeed:
>
>   $ git log --oneline -Swarn_unconfigured_push -- builtin-push.c
>   bba0fd2 push: do not give big warning when no preference is configured
>   665d3e8 Display warning for default git push with no push.default config
>
> I don't remember the mailing list conversations that surrounded those
> patches, but if we are going to have the same conversation again, maybe
> it is worth looking them up.

I just dug it up; start from here:

    http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541

read on a few messages downthread, and then jump to the other thread
Nana points at in the above message.

In short, we started warning that we _might_ change the default
someday, without having a clear concensus or plan, that ended up
confusing and annoying users without giving them anything good,
other than awareness that such a feature is _available_.

So no, the conversation did not decide if changing the default was
warranted or not. It just confirmed that we weren't anywhere close
to deciding back then.

Re: git push default behaviour?

[Junio C Hamano]

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

> I just dug it up; start from here:
>
>     http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541
>
> read on a few messages downthread, and then jump to the other thread
> Nana points at in the above message.
>
> In short, we started warning that we _might_ change the default
> someday, without having a clear concensus or plan, that ended up
> confusing and annoying users without giving them anything good,
> other than awareness that such a feature is _available_.
>
> So no, the conversation did not decide if changing the default was
> warranted or not. It just confirmed that we weren't anywhere close
> to deciding back then.

I think MJG's message (the second on in the "git push origin error"
thread) is probably what we would need to repeat, and this time more
strongly to squelch the opposition from old timers, if somebody
wants to resurrect the "warn until you set the default explicitly,
intending to change the default in the future" patch. And this time
around, the plan to change the default should be more concrete with
specific date, e.g. "Starting from April 1st, 2013".

I was in the "keep the default to matching, so that nobody among
existing 47 million users would be annoyed" camp (back then we
probably didn't have 47 million users, but that is besides the
point) and I still am, but notice that I was defending the argument
by the "let's be ( (new user) friendly )" camp in that thread. And
without much fire-support from those who were vocal about it.

Re-reading the thread made me sick.

I wish I had enough energy remaining to say "Let's try one more
time, and hope that people from the 'let's change the default' camp
will behave much better than the last time", but I do not have high
hopes, after having been burned once already with exactly the same
issue.

Re: git push default behaviour?

[demerphq]

On 9 March 2012 06:38, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> I just dug it up; start from here:
>>
>>     http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541
>>
>> read on a few messages downthread, and then jump to the other thread
>> Nana points at in the above message.
>>
>> In short, we started warning that we _might_ change the default
>> someday, without having a clear concensus or plan, that ended up
>> confusing and annoying users without giving them anything good,
>> other than awareness that such a feature is _available_.
>>
>> So no, the conversation did not decide if changing the default was
>> warranted or not. It just confirmed that we weren't anywhere close
>> to deciding back then.
>
> I think MJG's message (the second on in the "git push origin error"
> thread) is probably what we would need to repeat, and this time more
> strongly to squelch the opposition from old timers, if somebody
> wants to resurrect the "warn until you set the default explicitly,
> intending to change the default in the future" patch. And this time
> around, the plan to change the default should be more concrete with
> specific date, e.g. "Starting from April 1st, 2013".
>
> I was in the "keep the default to matching, so that nobody among
> existing 47 million users would be annoyed" camp (back then we
> probably didn't have 47 million users, but that is besides the
> point) and I still am, but notice that I was defending the argument
> by the "let's be ( (new user) friendly )" camp in that thread. And
> without much fire-support from those who were vocal about it.
>
> Re-reading the thread made me sick.
>
> I wish I had enough energy remaining to say "Let's try one more
> time, and hope that people from the 'let's change the default' camp
> will behave much better than the last time", but I do not have high
> hopes, after having been burned once already with exactly the same
> issue.

I think I read all the relevant mails, and I have a thought concerning
what I see to be the class of the problem here: the general question
of "how do you change default behavior if it turns out that the
original choice was inappropriate". It seems to me you can think of
solutions to that problem in general without considering the subject
of this thread.

A possible solution might be to give config files a "format version"
of their own. They already contain a repository format version number,
so add a new variable "ConfigVersionLevel". Alongside that you might
introduce a policy of having new git "fill in" the defaults missing
from the config file whenever it operates, so that people can
explicitly view then all at once. Then if the defaults change in the
future an old repo will continue to work as it did before. This alone
would allow you to change the defaults for existing configurable
behavior, but you need the version number to handle new options.

Once you have that you can change the default behavior based on the
version level so that older users operating in older repositories get
the old behavior, and new repositories get the new behavior. And you
have more flexibility in how your approach these problems when they
come up, and it seems to me that they are inevitable.

Cheers,
Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: git push default behaviour?

[Thomas Rast]

demerphq <demerphq@gmail.com> writes:

> A possible solution might be to give config files a "format version"
> of their own. They already contain a repository format version number,
> so add a new variable "ConfigVersionLevel". Alongside that you might
> introduce a policy of having new git "fill in" the defaults missing
> from the config file whenever it operates, so that people can
> explicitly view then all at once. Then if the defaults change in the
> future an old repo will continue to work as it did before. This alone
> would allow you to change the defaults for existing configurable
> behavior, but you need the version number to handle new options.
>
> Once you have that you can change the default behavior based on the
> version level so that older users operating in older repositories get
> the old behavior, and new repositories get the new behavior. And you
> have more flexibility in how your approach these problems when they
> come up, and it seems to me that they are inevitable.

This would be a brilliant way to confuse the hell out of existing users:
suddenly the apparent "defaults"[1] now change *between repositories*
depending on when they were created.

In short, oh please god no.


[1] using the word loosely here, for anything that the user has not
configured manually with git-config, git-remote, git branch
--set-upstream etc.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: git push default behaviour?

[Junio C Hamano]

Thomas Rast <trast@inf.ethz.ch> writes:

> This would be a brilliant way to confuse the hell out of existing users:
> suddenly the apparent "defaults"[1] now change *between repositories*
> depending on when they were created.
>
> In short, oh please god no.

Amen ;-)

Re: git push default behaviour?

[Gelonida N]

On 03/09/2012 09:48 AM, Thomas Rast wrote:
> demerphq <demerphq@gmail.com> writes:
> 
>> A possible solution might be to give config files a "format version"
>> of their own. They already contain a repository format version number,
>> so add a new variable "ConfigVersionLevel". Alongside that you might
>> introduce a policy of having new git "fill in" the defaults missing
>> from the config file whenever it operates, so that people can
>> explicitly view then all at once. Then if the defaults change in the
>> future an old repo will continue to work as it did before. This alone
>> would allow you to change the defaults for existing configurable
>> behavior, but you need the version number to handle new options.
>>
>> Once you have that you can change the default behavior based on the
>> version level so that older users operating in older repositories get
>> the old behavior, and new repositories get the new behavior. And you
>> have more flexibility in how your approach these problems when they
>> come up, and it seems to me that they are inevitable.
> 
> This would be a brilliant way to confuse the hell out of existing users:
> suddenly the apparent "defaults"[1] now change *between repositories*
> depending on when they were created.
> 
> In short, oh please god no.

If config file version changes would occur rarely, then this idea
dsoesn't sound that bad to me.
git could even ask whether it should upgrade (explicitely insert the old
default value if not existing and if different in the new release)  the
config file version whenver it encounters an old version.

By this means old projects wouldn't be broken whenever a default value
would be changed  and all rconfig files would upgrade to the same version.

Even older versions of git would still work with these upgraded config files

Re: git push default behaviour?

[Matthieu Moy]

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

> I just dug it up; start from here:
>
>     http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541

That's an old discussion. A more recent one is here:

  http://thread.gmane.org/gmane.comp.version-control.git/166743

(interleaved with a discussion about tag namespace, but the end of the
message is about push.default)

In this discussion, you (Junio) proposed a patch and argued exactly in
the direction I do right now. I think the discussion stopped here:

  http://thread.gmane.org/gmane.comp.version-control.git/166743

(i.e. "Care to roll an appliable patch?", which I guess everyone has
been too lazy to do)

Patch follows.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Matthieu Moy]

More inexperienced users will often push right after committing, and at
that time they're still very much in the "working-on-one-branch" state of
mind.  "upstream" would be a safer default mode of operation for 'git push'
for them even when they have their personal publishing repository (also in
a shared public repository settings, "matching" is rarely the right
default mode).

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

Original patch and commit message by: Junio C Hamano <gitster@pobox.com>

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---

This patch prepares a transition to 'upstream', unlike the previous
version which was advertizing 'current'. In most case, this would be
the same, but 'upstream' is probably more sensible in case it points
to a branch other than 'current'. I don't care much either way.

I've kept the wording from the original patch, which commits to a
future change. We may instead relax this commitment and just say "the
default is likely to change in a future version", or so.

 builtin/push.c |   22 ++++++++++++++++++++++
 cache.h        |    1 +
 environment.c  |    2 +-
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/builtin/push.c b/builtin/push.c
index d315475..03545c0 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -91,10 +91,32 @@ static void setup_push_upstream(struct remote *remote)
 	add_refspec(refspec.buf);
 }
 
+static void warn_unspecified_push_default_configuration(void)
+{
+	static int warn_once;
+
+	if (warn_once++)
+		return;
+	warning(_("push.default is unset; its implicit value is changing in 1.8.0 from\n"
+		  "'matching' to 'upstream'. To squelch this message and maintain the current\n"
+		  "behavior post-1.8.0, use:\n"
+		  "\n"
+		  "  git config --global push.default matching\n"
+		  "\n"
+		  "To squelch this message and adopt the 1.8.0 behavior now, use:\n"
+		  "\n"
+		  "  git config --global push.default upstream\n"
+		  "\n"
+		  "See 'git help config' and search for 'push.default' for further information.\n"));
+}
+
 static void setup_default_push_refspecs(struct remote *remote)
 {
 	switch (push_default) {
 	default:
+	case PUSH_DEFAULT_UNSPECIFIED:
+		warn_unspecified_push_default_configuration();
+		/* fallthru */
 	case PUSH_DEFAULT_MATCHING:
 		add_refspec(":");
 		break;
diff --git a/cache.h b/cache.h
index e12b15f..e5c3f26 100644
--- a/cache.h
+++ b/cache.h
@@ -622,6 +622,7 @@ enum rebase_setup_type {
 };
 
 enum push_default_type {
+	PUSH_DEFAULT_UNSPECIFIED = -1,
 	PUSH_DEFAULT_NOTHING = 0,
 	PUSH_DEFAULT_MATCHING,
 	PUSH_DEFAULT_UPSTREAM,
diff --git a/environment.c b/environment.c
index c93b8f4..d7e6c65 100644
--- a/environment.c
+++ b/environment.c
@@ -52,7 +52,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;
 unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
 enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
 enum rebase_setup_type autorebase = AUTOREBASE_NEVER;
-enum push_default_type push_default = PUSH_DEFAULT_MATCHING;
+enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED;
 #ifndef OBJECT_CREATION_MODE
 #define OBJECT_CREATION_MODE OBJECT_CREATION_USES_HARDLINKS
 #endif
-- 
1.7.9.3.330.g598662

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

[Junio C Hamano]

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

> This patch prepares a transition to 'upstream', unlike the previous
> version which was advertizing 'current'. In most case, this would be
> the same, but 'upstream' is probably more sensible in case it points
> to a branch other than 'current'. I don't care much either way.

I would agree with that choice (provided that we were to do this
change).

> I've kept the wording from the original patch, which commits to a
> future change. We may instead relax this commitment and just say "the
> default is likely to change in a future version", or so.

Please no.  Keep it _very_ firmly committed.  Otherwise we didn't
learn a thing from 1.6.3 era.

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

[Junio C Hamano]

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

> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> This patch prepares a transition to 'upstream', unlike the previous
>> version which was advertizing 'current'. In most case, this would be
>> the same, but 'upstream' is probably more sensible in case it points
>> to a branch other than 'current'. I don't care much either way.
>
> I would agree with that choice (provided that we were to do this
> change).
>
>> I've kept the wording from the original patch, which commits to a
>> future change. We may instead relax this commitment and just say "the
>> default is likely to change in a future version", or so.
>
> Please no.  Keep it _very_ firmly committed.  Otherwise we didn't
> learn a thing from 1.6.3 era.

The need for awareness building outside this mailing list remains,
but the ball is in the court of "let's change the default" folks and
I cannot do anything further on that front, so I'll focus on the
patch itself in this message.

The code seems quite competently done, except that the message text
would want to live in a separate static array, if only to keep the
lines in the patch not overly long.  Also, The message taken from
Jeff's $gmane/166787 may need to be tweaked further, waiting the
conclusion of the discussion in the other subthread.

Oh, another thing is that the "1.8.0" in Jeff's original was written
back in 1.7.5 era.  We would want to bump it to say "1.8" (or even
"2.0").

Thanks.

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

[Carlos Martín Nieto]

[-- Attachment #1: Type: text/plain, Size: 4687 bytes --]

On Fri, 2012-03-09 at 09:31 +0100, Matthieu Moy wrote:
> More inexperienced users will often push right after committing, and at
> that time they're still very much in the "working-on-one-branch" state of
> mind.  "upstream" would be a safer default mode of operation for 'git push'
> for them even when they have their personal publishing repository (also in
> a shared public repository settings, "matching" is rarely the right
> default mode).
> 
> In preparation for flipping the default to the "upstream" mode from the
> "matching" mode that is the upstream default, start warning users when they
> rely on unconfigured "git push" to default to the "matching" mode.
> 
> Original patch and commit message by: Junio C Hamano <gitster@pobox.com>
> 
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
> ---
> 
> This patch prepares a transition to 'upstream', unlike the previous
> version which was advertizing 'current'. In most case, this would be
> the same, but 'upstream' is probably more sensible in case it points
> to a branch other than 'current'. I don't care much either way.
> 

For people using git as VCS that happens to have local history rather
than taking full advantage of the distributed nature (or who aren't
aware of it or don't get it), 'matching' is bound to be confusing.
However, IMO 'current' makes more sense. Consider

    git clone ../foo; cd foo;
    git checkout -b topic origin/develop
    ed main.c
    git push

With upstream I've just updated origin's dev branch, even though I might
have meant to create a new 'topic' branch. Alternatively, I might have
run

    git checkout -b topic

in which case I certainly want 'current'. I don't see that workflow
where the upstream branch is named differently from the local one should
be that big a consideration when trying to determine a default to help
people unfamiliar as they'd be certainly more likely to consider branch
names to be binding. Maybe you have seen this differently in your
students, but that's the impression I get from #git.

They also seem to expect 'git pull' to be magic, but that's a different
story.

> I've kept the wording from the original patch, which commits to a
> future change. We may instead relax this commitment and just say "the
> default is likely to change in a future version", or so.
> 
>  builtin/push.c |   22 ++++++++++++++++++++++
>  cache.h        |    1 +
>  environment.c  |    2 +-
>  3 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/builtin/push.c b/builtin/push.c
> index d315475..03545c0 100644
> --- a/builtin/push.c
> +++ b/builtin/push.c
> @@ -91,10 +91,32 @@ static void setup_push_upstream(struct remote *remote)
>  	add_refspec(refspec.buf);
>  }
>  
> +static void warn_unspecified_push_default_configuration(void)
> +{
> +	static int warn_once;
> +
> +	if (warn_once++)
> +		return;
> +	warning(_("push.default is unset; its implicit value is changing in 1.8.0 from\n"
> +		  "'matching' to 'upstream'. To squelch this message and maintain the current\n"
> +		  "behavior post-1.8.0, use:\n"
> +		  "\n"
> +		  "  git config --global push.default matching\n"
> +		  "\n"
> +		  "To squelch this message and adopt the 1.8.0 behavior now, use:\n"
> +		  "\n"
> +		  "  git config --global push.default upstream\n"
> +		  "\n"
> +		  "See 'git help config' and search for 'push.default' for further information.\n"));
> +}
> +
>  static void setup_default_push_refspecs(struct remote *remote)
>  {
>  	switch (push_default) {
>  	default:
> +	case PUSH_DEFAULT_UNSPECIFIED:
> +		warn_unspecified_push_default_configuration();
> +		/* fallthru */
>  	case PUSH_DEFAULT_MATCHING:
>  		add_refspec(":");
>  		break;
> diff --git a/cache.h b/cache.h
> index e12b15f..e5c3f26 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -622,6 +622,7 @@ enum rebase_setup_type {
>  };
>  
>  enum push_default_type {
> +	PUSH_DEFAULT_UNSPECIFIED = -1,
>  	PUSH_DEFAULT_NOTHING = 0,
>  	PUSH_DEFAULT_MATCHING,
>  	PUSH_DEFAULT_UPSTREAM,
> diff --git a/environment.c b/environment.c
> index c93b8f4..d7e6c65 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -52,7 +52,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;
>  unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
>  enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
>  enum rebase_setup_type autorebase = AUTOREBASE_NEVER;
> -enum push_default_type push_default = PUSH_DEFAULT_MATCHING;
> +enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED;
>  #ifndef OBJECT_CREATION_MODE
>  #define OBJECT_CREATION_MODE OBJECT_CREATION_USES_HARDLINKS
>  #endif



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Marc Branchaud]

On 12-03-09 05:25 AM, Carlos Martín Nieto wrote:
> On Fri, 2012-03-09 at 09:31 +0100, Matthieu Moy wrote:
>> More inexperienced users will often push right after committing, and at
>> that time they're still very much in the "working-on-one-branch" state of
>> mind.  "upstream" would be a safer default mode of operation for 'git push'
>> for them even when they have their personal publishing repository (also in
>> a shared public repository settings, "matching" is rarely the right
>> default mode).
>>
>> In preparation for flipping the default to the "upstream" mode from the
>> "matching" mode that is the upstream default, start warning users when they
>> rely on unconfigured "git push" to default to the "matching" mode.
>>
>> Original patch and commit message by: Junio C Hamano<gitster@pobox.com>
>>
>> Signed-off-by: Matthieu Moy<Matthieu.Moy@imag.fr>
>> ---
>>
>> This patch prepares a transition to 'upstream', unlike the previous
>> version which was advertizing 'current'. In most case, this would be
>> the same, but 'upstream' is probably more sensible in case it points
>> to a branch other than 'current'. I don't care much either way.
>>
>
> For people using git as VCS that happens to have local history rather
> than taking full advantage of the distributed nature (or who aren't
> aware of it or don't get it), 'matching' is bound to be confusing.
> However, IMO 'current' makes more sense. Consider
>
>      git clone ../foo; cd foo;
>      git checkout -b topic origin/develop
>      ed main.c
>      git push
>
> With upstream I've just updated origin's dev branch, even though I might
> have meant to create a new 'topic' branch. Alternatively, I might have
> run
>
>      git checkout -b topic
>
> in which case I certainly want 'current'. I don't see that workflow
> where the upstream branch is named differently from the local one should
> be that big a consideration when trying to determine a default to help
> people unfamiliar as they'd be certainly more likely to consider branch
> names to be binding. Maybe you have seen this differently in your
> students, but that's the impression I get from #git.

I disagree and consider "upstream" to be the more reasonable default.

I think that an incantation like

	git checkout -b topic origin/master

makes it pretty clear that topic is meant to be merged into origin's 
master branch.  And so a simple "git push" as you describe I think 
*should* update origin's master branch.

OTOH, with a default of "current" I believe the simple "git push" will 
create a new branch named topic in the origin repo.  To me that's 
implying too much from the simple "git push" command.  If the user 
really wants a branch named topic in the origin repo, I think it's 
reasonable for git's default behaviour to require the user to say so 
explicitly ("git push origin topic").

I also disagree that an incantation like

	git checkout -b topic

means that the user wants "current" when they "git push".  There's no 
indication here that the user is at all interested in remote branches 
with this topic, and I think it would be presumptuous for git to make 
such a link by default.  (Besides, what if the user has more than one 
remote?  Which should be used?)

In this case the "upstream" default would mean that git couldn't 
identify a remote for the topic branch and so the "git push" would fail. 
  I think that's appropriate, because the user never told git how the 
topic branch relates to any remote branches.

		M.

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

[Stefan Haller]

Marc Branchaud <marcnarc@xiplink.com> wrote:

> I think that an incantation like
> 
>   git checkout -b topic origin/master
> 
> makes it pretty clear that topic is meant to be merged into origin's 
> master branch.  And so a simple "git push" as you describe I think 
> *should* update origin's master branch.

Not for us, no.  (But this is maybe a different topic.)

In our workflow (centralized repository), we never ever have a local
branch with a different name than its upstream branch. Never.

When we say

  git checkout -b topic origin/master

then it's always a mistake, and what we really meant was

  git checkout -b --no-track topic origin/master

This has bitten us a few times in the past (people accidentally pushing
their topic branches to master this way), and it's very annoying.


But coming back to the subject of push.default: in our environment,
"upstream" is the only default that is useful with the current behaviour
of git.

(I could dream of a git mode where it's not necessary to explicitly set
an upstream branch, and all git operations such as status, pull, or even
saying "@{u}" would automatically use "remotes/origin/samename" as the
upstream branch.  In that case, "current" would be a more convenient
default value for push.default; but I guess that hypothetical mode would
imply this anyway.)


-- 
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/

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

[Junio C Hamano]

lists@haller-berlin.de (Stefan Haller) writes:

> Marc Branchaud <marcnarc@xiplink.com> wrote:
>
>> I think that an incantation like
>> 
>>   git checkout -b topic origin/master
>> 
>> makes it pretty clear that topic is meant to be merged into origin's 
>> master branch.  And so a simple "git push" as you describe I think 
>> *should* update origin's master branch.
>
> Not for us, no.  (But this is maybe a different topic.)
>
> In our workflow (centralized repository), we never ever have a local
> branch with a different name than its upstream branch. Never.
>
> When we say
>
>   git checkout -b topic origin/master
>
> then it's always a mistake, and what we really meant was
>
>   git checkout -b --no-track topic origin/master

It would have been nice if you explained larger picture of your
workflow, as almost anything else in life, a blanket statement like
the above is not a universal truth.  It is clear you were aware of
that from your "Not for *us*", there is not enough clue for others
to tell if their workflow is similar to yours to decide if the above
rule of thumb of yours is a good one to follow for them.

Let's illustrate what I mean by "explain larger picture of workflow"
with a few examples.

An example of where "checkout -b topic origin/master" would not be a
mistake is when it is the norm for your project for contributors to
integrate their work with "pull --rebase", it is perfectly sensible
for a contributor to

	git checkout -b frotz origin/master

to start working on his feature "frotz", and way before the feature
becomes ready, starting to work on unrelated feature "nitfol" with

	git checout -b nitfol origin/master

and keep building these in parallel, running "git pull --rebase" to
float yet-to-be-published his own work on updated the shared history
before continuing to work on a topic until the feature is done.  As
the contributor may not know upfront which of these independent
features will become ready when he starts working, it is sensible
to be on the latter "nitfol" topic and "git push" it to update the
shared history with the finished work on the branch.

In this case, you would want "git push" a branch to its @{upstream}.

Another example that "checkout -b topic origin/master" would not be
a mistake is when you fork your favorite project at GitHub, work on
two independent topics. You work the same way as the above (you may
not "pull --rebase", though), and then push both of them out and ask
them to be pulled "Please pull my 'frotz' and 'nitfol' branches".

In this case, you would want "git push" a branch to update the
branch with the same name (i.e. either 'current' or 'matching').

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

[Stefan Haller]

Junio C Hamano <gitster@pobox.com> wrote:

> lists@haller-berlin.de (Stefan Haller) writes:
> 
> > When we say
> >
> >   git checkout -b topic origin/master
> >
> > then it's always a mistake, and what we really meant was
> >
> >   git checkout -b --no-track topic origin/master
> 
> It would have been nice if you explained larger picture of your
> workflow, as almost anything else in life, a blanket statement like
> the above is not a universal truth.

I wasn't saying that "checkout -b topic origin/master" isn't useful for
*anybody*; it's just not useful for us.  But you are right, I should
have explained who "us" is, and what our workflow is, sorry.

We're a closed-source company that uses git more or less like an
old-style, non-distributed VCS. (This is not because "we don't get it",
as someone phrased it elsewhere in this thread, but because it's what
makes most sense for us.)

The central repository has special significance, because it sends an
email for every commit, and it is hooked up to the CI system. For these
reasons, everything that people work on is pushed to the central
repository, on a topic branch with the same name as the local branch.
Also, it is very common for two or more developers to collaborate on a
topic branch, and the central repository is the hub for this (developers
pull topics with "pull --rebase"). There's no direct exchange between
developer's clones, because others on the team wouldn't see a commit
mail.

Topics are never pushed to master; we have a "merge --no-ff" policy for
integration.

Sometimes, we need to branch a topic (let's call it B) off another topic
(say A), because B needs some of A's code before it's integrated (we'll
rebase B onto master once A is merged back, to keep the history clean).
Same thing here: we say "checkout -b B origin/A", but we don't want to
have B's upstream to be set to origin/A. Again, we forgot to say
--no-track.

To sum it up, push.default=current is almost perfect for this kind of
workflow; except that you still need to configure your upstream branches
so that pull works, and status (and the shell prompt) displays the right
information.


-- 
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/

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

[Matthieu Moy]

lists@haller-berlin.de (Stefan Haller) writes:

> We're a closed-source company that uses git more or less like an
> old-style, non-distributed VCS.
> [...]
> Also, it is very common for two or more developers to collaborate on a
> topic branch,
> [...]
> Topics are never pushed to master; we have a "merge --no-ff" policy for
> integration.
> [...]
> To sum it up, push.default=current is almost perfect for this kind of
> workflow; except that you still need to configure your upstream branches
> so that pull works, and status (and the shell prompt) displays the right
> information.

What do you set "upstream" to in your flow?

I agree that push.default=current is the best setting for you. But I
think 'tracking' would not be a silly choice either: if you collaborate
on topic branches, it makes sense to set the upstream to the remote
topic branch, so that "git pull" gets changes in the same branch (and
you may need to "git pull origin master" to sync with the master branch
from time to time). If you create a new branch with, say

  git checkout -b new-branch

then the new branch has no upstream configured, and the next push
without argument will fail, pointing you to the right command for your
case:

  $ git push
  fatal: The current branch new-branch has no upstream branch.
  To push the current branch and set the remote as upstream, use
  
      git push --set-upstream origin new-branch

If you do a "git checkout new-branch" when "origin/new-branch" exists
and "new-branch" doesn't, the upstream is configured to point to the
remote "new-branch".

In both cases, the upstream is configured so that push.default=current
do the same thing as push.default=upstream, so you don't really care
which value is taken.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Stefan Haller]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

> lists@haller-berlin.de (Stefan Haller) writes:
> 
> > We're a closed-source company that uses git more or less like an
> > old-style, non-distributed VCS.
> > [...]
> > Also, it is very common for two or more developers to collaborate on a
> > topic branch,
> > [...]
> > Topics are never pushed to master; we have a "merge --no-ff" policy for
> > integration.
> > [...]
> > To sum it up, push.default=current is almost perfect for this kind of
> > workflow; except that you still need to configure your upstream branches
> > so that pull works, and status (and the shell prompt) displays the right
> > information.
> 
> What do you set "upstream" to in your flow?

The remote topic branch with the same name.

> I agree that push.default=current is the best setting for you. But I
> think 'tracking' would not be a silly choice either: if you collaborate
> on topic branches, it makes sense to set the upstream to the remote
> topic branch, so that "git pull" gets changes in the same branch (and
> you may need to "git pull origin master" to sync with the master branch
> from time to time). If you create a new branch with, say
> 
>   git checkout -b new-branch
> 
> then the new branch has no upstream configured, and the next push
> without argument will fail, pointing you to the right command for your
> case:
> 
>   $ git push
>   fatal: The current branch new-branch has no upstream branch.
>   To push the current branch and set the remote as upstream, use
>   
>       git push --set-upstream origin new-branch
> 
> If you do a "git checkout new-branch" when "origin/new-branch" exists
> and "new-branch" doesn't, the upstream is configured to point to the
> remote "new-branch".

Yes, you describe exactly what we are doing.  I am having two problems
with this way of working:

1) After creating a new local topic branch, I must remember to use
"push -u origin new-branch" the first time I push it. I don't want to
have to remember whether this is the first time I push; it would be nice
to be able to say "git push" the first time as well.
(push.default=current does this, but it's not good enough because I
still need the upstream branch configured so that pull works.)

2) I get bitten by commands that configure the "wrong" upstream branch
without me realizing it, like "checkout -b topic origin/master". Again,
push.default=current helps somewhat because it avoids accidentally
pushing to the wrong branch; but it will still let me pull from the
wrong branch; and it will confuse me because my shell prompt tells me
I'm ahead of upstream even though I just pushed.


-- 
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/

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

[Matthieu Moy]

lists@haller-berlin.de (Stefan Haller) writes:

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>
>> What do you set "upstream" to in your flow?
>
> The remote topic branch with the same name.

OK, so once it is configured, 'current' and 'upstream' do the same
thing. The difference is how the upstream is configured, and what
happens if you forget to do it.

> 1) After creating a new local topic branch, I must remember to use
> "push -u origin new-branch" the first time I push it.

For this case, I'd say 'upstream' is superior to 'current', because it
will remind you to set the upstream on the first push, while 'current'
will let you silently continue with the upstream unconfigured (which you
need for 'pull' and 'status').

> I don't want to have to remember whether this is the first time I
> push; it would be nice to be able to say "git push" the first time as
> well.

(If you're going to work colaboratively, I'd say it makes sense to push
an empty branch, just to let other people know that the branch is
created, but that's not the point here)

Probably the ideal command for you would be to allow something like

  git checkout -b topic origin/master --set-upstream=origin/topic

> 2) I get bitten by commands that configure the "wrong" upstream branch
> without me realizing it, like "checkout -b topic origin/master".

You may want to set branch.autosetupmerge to false, then. It will
disable the "set upstream" magic (but unfortunately, it will also
disable it for a plain "git checkout new-branch" which would create
new-branch automagically if origin/new-branch already exists).

Just to be clear: I'm not saying that your workflow is wrong, but my
feeling is that you wouldn't be hurt by 'push.default=upstream'. The
area of potential improvement for your case would be at branch creation
time more than at push time.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Junio C Hamano]

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

> Just to be clear: I'm not saying that your workflow is wrong, but my
> feeling is that you wouldn't be hurt by 'push.default=upstream'. The
> area of potential improvement for your case would be at branch creation
> time more than at push time.

Your analysis of Stefan's pain points sounds very sensible.
The autoSetupMerge mechanism may want to learn new tricks, but that
is a separate issue and it shouldn't affect the search for a sane
default for push.

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

[Marc Branchaud]

On 12-03-09 04:08 PM, Stefan Haller wrote:
> 
> But coming back to the subject of push.default: in our environment,
> "upstream" is the only default that is useful with the current behaviour
> of git.

I'm not at all surprised -- everyone works differently.  This is why the
default is configurable in the first place.

When it comes to what git should do by default, I think it's a bit pointless
to have environment-vs-environment discussions.  No matter how many people
join such a discussion on this list, it can only give us hints to which
default would best serve git's users.  Maybe the git survey can tell us what
workflows are most popular, but even that may not indicate the best default
behaviour.

The point I was trying to make in my previous message is that "upstream"
seems like the least dangerous default behaviour.  Yes, it does not match
everyone's workflow.  But it seems the least likely to shoot the feet off of
people who have yet to figure out their workflow at all.

		M.

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

[Michael Haggerty]

On 03/09/2012 07:30 PM, Marc Branchaud wrote:
> On 12-03-09 05:25 AM, Carlos Martín Nieto wrote:
>> On Fri, 2012-03-09 at 09:31 +0100, Matthieu Moy wrote:
>>> This patch prepares a transition to 'upstream', unlike the previous
>>> version which was advertizing 'current'. In most case, this would be
>>> the same, but 'upstream' is probably more sensible in case it points
>>> to a branch other than 'current'. I don't care much either way.
>>>
>>
>> For people using git as VCS that happens to have local history rather
>> than taking full advantage of the distributed nature (or who aren't
>> aware of it or don't get it), 'matching' is bound to be confusing.
>> However, IMO 'current' makes more sense. Consider
>> [...]
> 
> I disagree and consider "upstream" to be the more reasonable default.
> [...]

I think that either "current" or "upstream" would be an improvement on
the current behavior, but each of them is inappropriate in certain
workflows (even among centralized workflows).

I propose that the default should be even stricter: like "current", it
would push to an branch with the same name as the current local branch,
*but only if that branch already exists on the remote*.  It would only
be possible to create a new branch on the remote by calling "git push"
with an explicit branch argument.  I believe that such a policy would do
the right thing in the cases where the "right thing" is pretty
unambiguous, and would require a user decision in other cases.

Of course, users who have a strong preference for what is the "right
thing" in the ambiguous case can fine-tune their local preference to
"current" or "upstream"; this would amount to a relaxation of the strict
default policy.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

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

[Marc Branchaud]

On 12-03-10 01:16 AM, Michael Haggerty wrote:
> 
> I propose that the default should be even stricter: like "current", it
> would push to an branch with the same name as the current local branch,
> *but only if that branch already exists on the remote*.  It would only
> be possible to create a new branch on the remote by calling "git push"
> with an explicit branch argument.  I believe that such a policy would do
> the right thing in the cases where the "right thing" is pretty
> unambiguous, and would require a user decision in other cases.

I haven't thought it through very deeply, but at first glance this seems like
reasonable default behaviour to me.

		M.

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

[Matthieu Moy]

Marc Branchaud <marcnarc@xiplink.com> writes:

> On 12-03-10 01:16 AM, Michael Haggerty wrote:
>> 
>> I propose that the default should be even stricter: like "current", it
>> would push to an branch with the same name as the current local branch,
>> *but only if that branch already exists on the remote*.  It would only
>> be possible to create a new branch on the remote by calling "git push"
>> with an explicit branch argument.  I believe that such a policy would do
>> the right thing in the cases where the "right thing" is pretty
>> unambiguous, and would require a user decision in other cases.
>
> I haven't thought it through very deeply, but at first glance this seems like
> reasonable default behaviour to me.

I do find it reasonable, but I think 'upstream' has several advantages
over it.

* 'upstream' makes "git push" and "git pull" symmetrical. While there
  are workflows where it is usefull to have "push" and "pull" point to
  different branches, I think it is far more intuitive to have this
  symmetry by default.

* For newbies, the sequence "create an empty repository, clone it,
  commit and push" works like a charm with either 'upstream' or
  'current'. Today, the first push to an empty repository requires
  either saying "git push origin master" or "git push --all", both of
  which sound like black magic to the poor user who did not yet learn
  what 'origin' is and what a branch is.

* 'upstream' makes it easy to create a local topic branch, and let
  'push' send it to the master branch (i.e. have local 'topic-branch'
  pull and push to 'origin/master'). In general, 'upstream' allows
  workflows where you push to branches with either a different name or
  with the same name (by setting the upstream appropriately), but the
  opposite is not true.

That being said, I think the mode you Michael described at least
deserves to exist, even if I disagree that it would be the best default.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Junio C Hamano]

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

> * 'upstream' makes "git push" and "git pull" symmetrical. While there
>   are workflows where it is usefull to have "push" and "pull" point to
>   different branches, I think it is far more intuitive to have this
>   symmetry by default.

Yes, "by default" is really the key word in this discussion, and I
find the above a sound reasoning.

> ...
> That being said, I think the mode you Michael described at least
> deserves to exist, even if I disagree that it would be the best default.

While I agree with that, I think the "if and only if the destination
already exists" falls into the same "modifier" category as "force"
that changes the behaviour of updating _one_ ref from the default
"only if it fast-forwards" to "even if it does not fast-forward".  I
would prefer this new modifier not to be tied too tightly to the
Michael's magic mode, so that it can also be used when the refspecs
are explicitly given.

In other words, with "force":

	git push $there +pu

updates branch 'pu' over there even if it is not an ancestor of our
'pu'.  Similarly, may want to be able to say (I am *not* suggesting
to use '?' as the motifier):

	git push $there ?next

to update next only if it exists over there and it is an ancestor of
our 'next'.

Maybe these modifiers can be combined, so that I can say

	for there in k.org repo github sf.net
        do
		git push $there maint master ?next ?+pu
	done

Because the publishing point I have at sourceforge lack next and pu,
this will only update maint and master following the usual rules
over there, but next and pu will be updated at other places.

Hmm?

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

[Jeff King]

On Mon, Mar 12, 2012 at 05:37:32PM +0100, Matthieu Moy wrote:

> I do find it reasonable, but I think 'upstream' has several advantages
> over it.
> 
> * 'upstream' makes "git push" and "git pull" symmetrical. While there
>   are workflows where it is usefull to have "push" and "pull" point to
>   different branches, I think it is far more intuitive to have this
>   symmetry by default.

This is one of the things I really hate about 'upstream'. If you share a
central repo with other people, it makes sense. You push and pull from
the same place. But in the classic kernel-style workflow, you'd pull
from an upstream, and then publish your work elsewhere. And I think it's
not just kernel people who use this asymmetric workflow. On something
like GitHub, you get your own fork repo on the site as a publishing
point. But you also want to keep pulling and basing your work on what
the main project is doing. You can't just pull from your fork, since it
never gets updates from the main project; you pull them into your local
repo, and then push them up to your fork.

So in a very reasonable common newbie workflow, "upstream" will not at
all do what you want, because it will go to the wrong repo[1]

That being said, "current" will _also_ go to the wrong repo, because
push fundamentally respects "branch.*.remote".  Which is definitely not
what you want in the asymmetric case. This is not a push.default issue,
but I think it is somewhat related, and maybe worth discussing along
with the topic of asymmetry. Am I the only one who finds this behavior
annoying? I've mostly trained my fingers to type "git push
<my-publish-repo>", but I do occasionally forget. Do other people with
asymmetric workflows find this annoying? Do they not care? Or are many
fewer people doing asymmetric things than I think?

While I'm ranting, there's another weirdness I noticed. If I have
push.default set to upstream, and config like this:

  [branch "foo"]
     remote = origin
     merge = refs/heads/master

then typing "git push" will go to foo's master branch. But if I type
"git push other-remote", then it will go to other-remote's master
branch. Which makes no sense to me. The upstream is foo's master, and
now we are making guesses about how the names on each side are the same.
Is this an intentional behavior?

[1] One saving grace of going to the wrong repo is that you usually
    don't have permissions to push to that repo, so you get a harmless
    error message.

> * For newbies, the sequence "create an empty repository, clone it,
>   commit and push" works like a charm with either 'upstream' or
>   'current'. Today, the first push to an empty repository requires
>   either saying "git push origin master" or "git push --all", both of
>   which sound like black magic to the poor user who did not yet learn
>   what 'origin' is and what a branch is.

Ending that confusion is one of the best reasons to switch the default,
IMHO, but I don't think it argues for "current" versus "upstream", as
they both fix it (but Michael's matching-current hybrid would not, so I
agree it is less appealing).

> * 'upstream' makes it easy to create a local topic branch, and let
>   'push' send it to the master branch (i.e. have local 'topic-branch'
>   pull and push to 'origin/master'). In general, 'upstream' allows
>   workflows where you push to branches with either a different name or
>   with the same name (by setting the upstream appropriately), but the
>   opposite is not true.

Actually, this is the thing that scares me the most about "upstream" as
a default, because in this case, you are implicitly performing the
equivalent of a fast-forward merge. So that's handy if you are a new
user who wants to publish your work back to the master branch. But that
has two problems:

  1. If you are a new user who does like the implicit merge, you may
     find it convenient not to have to learn about "git checkout; git
     merge topic ; git push remote master". But it only helps you
     _sometimes_. If master has had other work built on it, your push
     will fail, and you will have to do the merge yourself. So it is
     only helping you by omitting a step some of the time, and you still
     have to learn why the step is sometimes necessary and sometimes
     not.

     Yes, experienced users do not have this learning problem. But
     remember we are talking about a default targeted at new users, and
     trying to reduce their confusion.  People who know and like what
     "upstream" does can configure it themselves.

  2. If you are a new user who _doesn't_ want to do the merge, but
     instead wants to publish your work-in-progress topic, then the
     implicit merge-back-to-master behavior is wrong and dangerous.
     You are publishing work that probably violates the general rules
     for what goes on master.

     Or perhaps somebody else has built on top of master, and your push
     fails. If you're an astute reader, you will see that the failing
     push tried to go to master. But if you're not, you may retry with
     "-f", which is quite dangerous, as now you are not just
     accidentally publishing a work-in-progress, but you are
     overwriting somebody else's work. Obviously this is a problem
     anytime you use "-f", but the fact that your "foo" branch is going
     to somewhere besides the remote's "foo" branch makes me think it is
     much more likely a clueless user will get confused and overwrite
     something on the more "mainstream" branch.

So far a lot of the discussion has focused on "what is the most sensible
default for the most number of people". But I wonder if a better
question is "what is the default that is the least likely to do
something dangerous and embarrassing". People who use git enough to say
"wow, I don't like this default for my workflow" are probably at the
point that they can configure push.default themselves.

-Peff

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> ... This is not a push.default issue,
> but I think it is somewhat related, and maybe worth discussing along
> with the topic of asymmetry. ...
> I've mostly trained my fingers to type "git push
> <my-publish-repo>", but I do occasionally forget.

In an assymmetric set-up, you would typically push into one place
but update from one or more places, so it might make sense to make
it easier to say "git push" and "git pull $there".  But that does
not solve the fundamental issue, I would think.

> Do other people with
> asymmetric workflows find this annoying? Do they not care? Or are many
> fewer people doing asymmetric things than I think?

I think it is not "they do not care", but "they do not have a good
solution".  I do not think of anything offhand, either.

> While I'm ranting, there's another weirdness I noticed. If I have
> push.default set to upstream, and config like this:
>
>   [branch "foo"]
>      remote = origin
>      merge = refs/heads/master
>
> then typing "git push" will go to foo's master branch. But if I type
> "git push other-remote", then it will go to other-remote's master
> branch. Which makes no sense to me. The upstream is foo's master, and
> now we are making guesses about how the names on each side are the same.
> Is this an intentional behavior?

Because "upstream" is meant to be "For the branch I am on, you know
how the branches map between the remote repository, so you already
know what the right thing to do---do it" mode, the correct "guess"
in your case is to error out and say "Nah, you are not talking with
your upstream, so I do not have any clue what branches you want to
push out and how. As you said that the push.default is upstream, not
matching, I refuse to even do the matching push in your case.  This
is an error. Be more specific".

> Actually, this is the thing that scares me the most about "upstream" as
> a default, because in this case, you are implicitly performing the
> equivalent of a fast-forward merge. So that's handy if you are a new
> user who wants to publish your work back to the master branch. But that
> has two problems:
>
>   1. If you are a new user who does like the implicit merge, you
>   may find it convenient not to have to learn about ... << and we
>   shouldn't discourage them from learning as it will be needed
>   anyway >>
>
>   2. If you are a new user who _doesn't_ want to do the merge, but
>   instead wants to publish your work-in-progress topic, then the
>   implicit merge-back-to-master behavior is wrong and dangerous.
>   << the newbie may push -f ruining the work of others >>

I agree with both points.  Also there is a cross-variant issue of
the above two:

	If a new user hears "not fast-forward, first pull and then
	push again", that will be done on a topic branch, merging
	'master' back and then pushing the result to 'master',
	leaving the 'master' of the user behind.

> So far a lot of the discussion has focused on "what is the most sensible
> default for the most number of people". But I wonder if a better
> question is "what is the default that is the least likely to do
> something dangerous and embarrassing". People who use git enough to say
> "wow, I don't like this default for my workflow" are probably at the
> point that they can configure push.default themselves.

I do not think "the most number of people" is a high-priority issue,
but "least damage" default may not be necessarily the best.

Obviously, "nothing" is the least-damage option, and looking at how
even people on this list cannot decide between current and upstream,
I actually am very tempted to suggest it as the new default.

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

[Junio C Hamano]

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

> Jeff King <peff@peff.net> writes:
>
>> ... This is not a push.default issue,
>> but I think it is somewhat related, and maybe worth discussing along
>> with the topic of asymmetry. ...
>> I've mostly trained my fingers to type "git push
>> <my-publish-repo>", but I do occasionally forget.
>
> In an assymmetric set-up, you would typically push into one place
> but update from one or more places, so it might make sense to make
> it easier to say "git push" and "git pull $there".  But that does
> not solve the fundamental issue, I would think.
>
>> Do other people with
>> asymmetric workflows find this annoying? Do they not care? Or are many
>> fewer people doing asymmetric things than I think?
>
> I think it is not "they do not care", but "they do not have a good
> solution".  I do not think of anything offhand, either.

Actually, we could introduce branch.$name.pushRemote that overrides
branch.$name.remote only for pushes.

Before anybody makes an ill-conceived comment, remote.$name.pushURL
is not to be used for this purpose.  It is only about how to get to
the named remote repository, and git still considers remote.$name to
be logically the same remote. "git push" into the named remote will
still update the remote tracking branch that we would update if we
were to immediately turn around and run "git fetch" from that same
remote, and abusing remote.$name.pushURL for triangular setup will
not give us a correct behaviour.

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

[Marc Branchaud]

On 12-03-12 03:06 PM, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>> 
>> So far a lot of the discussion has focused on "what is the most sensible
>> default for the most number of people". But I wonder if a better
>> question is "what is the default that is the least likely to do
>> something dangerous and embarrassing". People who use git enough to say
>> "wow, I don't like this default for my workflow" are probably at the
>> point that they can configure push.default themselves.
> 
> I do not think "the most number of people" is a high-priority issue,
> but "least damage" default may not be necessarily the best.

I agree, but I don't think we even have a good idea of what "least damage"
even means.  It seems to be vaguely related to how much of a hassle it would
be to recover from a plain "git push" doing the wrong thing.

There's one thing I'd like to ask all the folks who are pointing out how well
the candidate defaults match various workflows:  How much training do you
give (or are assuming for) your workflow's new users?

Or, more broadly, what is a "new" git user?  Are we talking about someone
using git for the first time on a brand-new project that they're setting up
themselves?  (Has that person even used any other VCS's?)

Or is it someone who's joining an already-established team?  Even a "new"
user hacking the Linux kernel or forking some github project is tying into an
established process.  And most every established process has either
documentation (or a person) to explain how things are set up, and how to best
configure git to work in that environment.

IMHO git need not worry about "new" users joining an established process, if
for no other reason that it seems impossible to make git new-user-friendly in
all (or even most) of those environments.

Instead the focus should be on new users who are wrestling with git by
themselves (well, hopefully with the help whatever online documentation
they've found).  They're making up their workflows as they go, refining them
as they learn more about git.  These are the users that git's defaults should
cater to.

And for those users, I still think "upstream" is the best of the current
default candidates.

> Obviously, "nothing" is the least-damage option, and looking at how
> even people on this list cannot decide between current and upstream,
> I actually am very tempted to suggest it as the new default.

There's a lot of merit to that.  If nothing else, it'd get new users to learn
at least a little bit about git.  I wouldn't be opposed to pushing nothing by
default.

		M.

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

[Matthieu Moy]

Marc Branchaud <marcnarc@xiplink.com> writes:

>> Obviously, "nothing" is the least-damage option, and looking at how
>> even people on this list cannot decide between current and upstream,
>> I actually am very tempted to suggest it as the new default.
>
> There's a lot of merit to that.  If nothing else, it'd get new users to learn
> at least a little bit about git.  I wouldn't be opposed to pushing nothing by
> default.

That would imply teching people what a branch is before teaching them
very basic workflows with push and pull.

If Git goes this route, I'll have to consider Mercurial instead of Git
to teach revision control to my students ;-).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Matthieu Moy]

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

> Jeff King <peff@peff.net> writes:
>
>> ... This is not a push.default issue,
>> but I think it is somewhat related, and maybe worth discussing along
>> with the topic of asymmetry. ...
>> I've mostly trained my fingers to type "git push
>> <my-publish-repo>", but I do occasionally forget.
>
> In an assymmetric set-up, you would typically push into one place
> but update from one or more places, so it might make sense to make
> it easier to say "git push" and "git pull $there".  But that does
> not solve the fundamental issue, I would think.

It does not solve it completely, but it makes it sensible to have
'upstream' point to the place you are publishing to, and tell "git pull"
explicitely where you want to pull from. This is the way I work when I
have an asymmetrical setup (not the most common in my case).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Jeff King]

On Mon, Mar 12, 2012 at 12:06:48PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > ... This is not a push.default issue,
> > but I think it is somewhat related, and maybe worth discussing along
> > with the topic of asymmetry. ...
> > I've mostly trained my fingers to type "git push
> > <my-publish-repo>", but I do occasionally forget.
> 
> In an assymmetric set-up, you would typically push into one place
> but update from one or more places, so it might make sense to make
> it easier to say "git push" and "git pull $there".  But that does
> not solve the fundamental issue, I would think.

I think it can even be a bit more complex than that. For example, I
actually _never_ run git-pull. Instead, I fetch, and then use the
upstream config for lots of other operations, like seeing what's in a
topic branch, rebasing, etc.

So to me, it is not just about "symmetry between push and pull", but
that the upstream config is fundamentally about "what is this work based
off of", which may or may not have anything to do with where you are
pushing to.

> > Do other people with
> > asymmetric workflows find this annoying? Do they not care? Or are many
> > fewer people doing asymmetric things than I think?
> 
> I think it is not "they do not care", but "they do not have a good
> solution".  I do not think of anything offhand, either.

The branch.*.pushRemote you mentioned would help with that. But for me,
I would much rather have simply push.defaultRemote. Configuring each
branch independently would be a pain, and I always want to push to my
publishing point (or at least, by default; anything else is a one-off
that can get an option on the command line). It is not a per-branch
thing at all for me.

Speaking of which, I often get annoyed at the per-branch
auto-configuration of upstreams. For example, I find myself doing this:

  [get an idea, read a bug report on the list, etc]
  $ cd git
  $ hack hack hack
  [oh, this is turning into something real. Let's make a branch]
  $ git checkout -b jk/bug-fix
  $ git commit -m 'fix bug'

but now my bug-fix branch is based off of wherever I was (which is
usually some private topic-integration branch I run most of the time).
I wish there was some way to say "No, branches should _always_ consider
origin/master as their upstream, unless I configure them some other
way" (which I do occasionally for building sub-topics on other topics).

Which makes me wonder if perhaps people are using "upstream" to mean
several different thing. I use it to say "this is the branch that this
topic is based off of", which makes "git log @{u}.." helpful, "git
rebase -i" just work, and gives some meaning to the ahead/behind message
(it shows how my topic relates to the main project).

But I think people also use upstream to mean "this is the definitive
version of this branch in some central repo". So they would say that
"jk/bug-fix" is based on "origin/jk/bug-fix". And the ahead/behind
message is about "do I have any local work that needs pushed, or any
remote work that needs pulled?"

And I wonder if this is where some of the debate for
push.default=upstream comes from. Whether that is useful to you or not
would depend on how you set up your branches. In the latter model, I
would think pushing to the upstream would be the right thing.

> Because "upstream" is meant to be "For the branch I am on, you know
> how the branches map between the remote repository, so you already
> know what the right thing to do---do it" mode, the correct "guess"
> in your case is to error out and say "Nah, you are not talking with
> your upstream, so I do not have any clue what branches you want to
> push out and how. As you said that the push.default is upstream, not
> matching, I refuse to even do the matching push in your case.  This
> is an error. Be more specific".

Yeah, I agree that is the only sane thing to do.

> I do not think "the most number of people" is a high-priority issue,
> but "least damage" default may not be necessarily the best.
> 
> Obviously, "nothing" is the least-damage option, and looking at how
> even people on this list cannot decide between current and upstream,
> I actually am very tempted to suggest it as the new default.

I was tempted to suggest that, but it somehow feels too overboard and
unfriendly.  I really like "current", as it seems like the simplest and
unsurprising thing we can do, short of doing nothing at all.

-Peff

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> The branch.*.pushRemote you mentioned would help with that. But for me,
> I would much rather have simply push.defaultRemote.

I would think that is a natural way to extend it. Don't we already have
something similar that is per repository default that can be overriden
with per branch configuration?

> Speaking of which, I often get annoyed at the per-branch
> auto-configuration of upstreams. For example, I find myself doing this:
>
>   [get an idea, read a bug report on the list, etc]
>   $ cd git
>   $ hack hack hack
>   [oh, this is turning into something real. Let's make a branch]
>   $ git checkout -b jk/bug-fix
>   $ git commit -m 'fix bug'
>
> but now my bug-fix branch is based off of wherever I was (which is
> usually some private topic-integration branch I run most of the time).

What in "checkout -b jk/bug-fix" makes jk/bug-fix a downstream of
origin/master?  I admit my brain is not working very well today, but I
would have expected the branch to have either your local private topic
integration branch as its @{u}, or no @{u} defined for it at all.  Perhaps
there is a design error of some sort around that code?

> Which makes me wonder if perhaps people are using "upstream" to mean
> several different thing. I use it to say "this is the branch that this
> topic is based off of", which makes "git log @{u}.." helpful, "git
> rebase -i" just work, and gives some meaning to the ahead/behind message
> (it shows how my topic relates to the main project).
>
> But I think people also use upstream to mean "this is the definitive
> version of this branch in some central repo". So they would say that
> "jk/bug-fix" is based on "origin/jk/bug-fix". And the ahead/behind
> message is about "do I have any local work that needs pushed, or any
> remote work that needs pulled?"

I think that is the more common interpretation.  Earlier you said
ahead/behind gives "some meaning", but compared to this "how many more do
I have, how many more do others have while I was looking the other way", I
am not sure what kind of cue that "some meaning" would give us.

> And I wonder if this is where some of the debate for
> push.default=upstream comes from. Whether that is useful to you or not
> would depend on how you set up your branches. In the latter model, I
> would think pushing to the upstream would be the right thing.

No question about the conclusion in the last sentence, but at the same
time, I do not think the push.default is about making things work smoothly
for people who configure everything right.

>> Because "upstream" is meant to be "For the branch I am on, you know
>> how the branches map between the remote repository, so you already
>> know what the right thing to do---do it" mode, the correct "guess"
>> in your case is to error out and say "Nah, you are not talking with
>> your upstream, so I do not have any clue what branches you want to
>> push out and how. As you said that the push.default is upstream, not
>> matching, I refuse to even do the matching push in your case.  This
>> is an error. Be more specific".
>
> Yeah, I agree that is the only sane thing to do.

Perhaps this can be a good sample entry for the experimental "tracker"
thing to keep track of to see how the workflow will evolve around it;
unless neither of us would get to work on it immediately, it is very
likely to be forgotten, as this is a tangent in the overall discussion,
even though the bug is real and solution is clear.

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

[Jeff King]

On Tue, Mar 13, 2012 at 03:54:26PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > The branch.*.pushRemote you mentioned would help with that. But for me,
> > I would much rather have simply push.defaultRemote.
> 
> I would think that is a natural way to extend it. Don't we already have
> something similar that is per repository default that can be overriden
> with per branch configuration?

I think branch.*.rebase / pull.rebase is the only current example. But
yeah, having a hierarchy like that makes sense to me.

> > Speaking of which, I often get annoyed at the per-branch
> > auto-configuration of upstreams. For example, I find myself doing this:
> >
> >   [get an idea, read a bug report on the list, etc]
> >   $ cd git
> >   $ hack hack hack
> >   [oh, this is turning into something real. Let's make a branch]
> >   $ git checkout -b jk/bug-fix
> >   $ git commit -m 'fix bug'
> >
> > but now my bug-fix branch is based off of wherever I was (which is
> > usually some private topic-integration branch I run most of the time).
> 
> What in "checkout -b jk/bug-fix" makes jk/bug-fix a downstream of
> origin/master?  I admit my brain is not working very well today, but I
> would have expected the branch to have either your local private topic
> integration branch as its @{u}, or no @{u} defined for it at all.  Perhaps
> there is a design error of some sort around that code?

Sorry, reading my example again, I was completely unclear. I was trying
to simplify it down to a readable case and ended up omitting the parts
that would have it make any sense.  So let me try again:

I play around with a fix or a feature on top of some random branch.
Eventually, I realize that this is a promising direction, and want to
make a topic branch. I'm in a state where I have some work-in-progress
commits on top of a random point (which yes, means my commits might be
totally bogus when ported to origin/master, but in practice, they are
close enough).

One option would be:

  $ git checkout -b jk/bug-fix origin/master
  $ git cherry-pick @{-1}~2..@{-1}

which sets up the upstream appropriately. But what I often end up doing
is:

  $ git checkout -b jk/bug-fix
  $ git rebase -i --onto origin/master HEAD~2

to tweak the patch ordering. Or even:

  $ git checkout -b jk/bug-fix
  $ hack hack hack
  [oops, this should be based on master, not where I was]
  $ git rebase --onto origin/master HEAD~2

In all three cases, I end up in the same state of history, but only in
the first one is my upstream config even remotely useful. There are
other variants, too, where I use "stash" and "reset" to end up building
on the history I want.

Two caveats before I go further:

  1. You might argue that the real problem is that I'm building the
     tentative change somewhere inappropriate. And that is kind of true,
     and this could all be averted by running "git checkout" in the
     first place to build on the appropriate spot. Though I do sometimes
     do that, too:

       $ git checkout origin/master
       $ test test test
       [ok, bug exists]
       $ fix fix fix
       [ok, this is worth a topic branch]
       $ git checkout -b jk/bug-fix

     and it also does not set up the upstream config. It would if I used
     a local "master" branch, but I do not have one (and I do not want
     one, as it would just be a pain to keep in sync with
     origin/master).

  2. I really just want everything based off of origin/master, because
     that is an implicit part of my workflow for this project. So I am
     not arguing that what "git checkout -b" does is wrong given the
     information I have given git, but that there is no place for me to
     give git that information.

So originally, I had a vague notion in my mind that I wanted some way to
tell "no, really, I always want to think of origin/master as the
upstream unless I explicitly tell you otherwise". Something like:

  $ git config branch.defaultUpstream refs/remotes/origin/master
  $ git config branch.autosetupmerge false

But having just typed out several examples, I think git _could_ figure
this out automatically. My real complaint is that as I use lower-level
tools to adjust the basis of my history, the upstream config is not
similarly updated. So another option would be:

  1. git-rebase could re-adjust the upstream config when using "--onto"
     with a branch parameter.

  2. git-reset could re-adjust the upstream config when moving directly
     to a branch.

  3. When we detach HEAD, remember the original branch name (in
     .git/ORIGINAL_BRANCH or similar); when a branch is created from
     the detached HEAD, set up ORIGINAL_BRANCH as the upstream. You'd
     probably want the "rebase" and "reset" in steps (1) and (2) to
     update ORIGINAL_BRANCH when you're on a detached HEAD.

I think that would perfectly fit my workflow. But I'm not sure if other
people would be confused by these operations changing the upstream
config (e.g., if you expect "jk/bug-fix" to have an upstream of
"origin/jk/bug-fix", when such a change would not be welcome).

> > But I think people also use upstream to mean "this is the definitive
> > version of this branch in some central repo". So they would say that
> > "jk/bug-fix" is based on "origin/jk/bug-fix". And the ahead/behind
> > message is about "do I have any local work that needs pushed, or any
> > remote work that needs pulled?"
> 
> I think that is the more common interpretation.  Earlier you said
> ahead/behind gives "some meaning", but compared to this "how many more do
> I have, how many more do others have while I was looking the other way", I
> am not sure what kind of cue that "some meaning" would give us.

If upstream is "here is where my topic is based from", then the
ahead/behind tells you how big your topic is (ahead), and whether it
might be a candidate for rebasing (behind). If your upstream is "the
central repo version of topic", then it tells you what work you have yet
to share with others (ahead), and what work others have done on the
topic that you could merge (behind).

> >> Because "upstream" is meant to be "For the branch I am on, you know
> >> how the branches map between the remote repository, so you already
> >> know what the right thing to do---do it" mode, the correct "guess"
> >> in your case is to error out and say "Nah, you are not talking with
> >> your upstream, so I do not have any clue what branches you want to
> >> push out and how. As you said that the push.default is upstream, not
> >> matching, I refuse to even do the matching push in your case.  This
> >> is an error. Be more specific".
> >
> > Yeah, I agree that is the only sane thing to do.
> 
> Perhaps this can be a good sample entry for the experimental "tracker"
> thing to keep track of to see how the workflow will evolve around it;
> unless neither of us would get to work on it immediately, it is very
> likely to be forgotten, as this is a tangent in the overall discussion,
> even though the bug is real and solution is clear.

I agree this is a candidate for that. But this is where the concept of
the tracker breaks down. Who is supposed to update it? You or me? Some
volunteer who agrees to migrate email discussion into the tracker?  I
suspect the latter will not work for a point buried so deeply in a
thread.  Which leaves you and me.

I specifically stayed out of the tracker discussion this time around
because all I had to contribute was "please no, web-based tools are an
abomination". But now that we see a potential use-case in practice, I am
realizing that I would not mind at all making a note in a todo file, or
even sending an email. But the thought of filling out a structured
problem report to go into a web-based database makes me not want to
bother.  Perhaps it is just my natural curmudgeonliness, but I think
part of it is that I know I am unlikely to actually visit the page to
ever retrieve the information.

I dunno.

-Peff

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Two caveats before I go further:
>
>   1. You might argue that the real problem is that I'm building the
>      tentative change somewhere inappropriate.

No, that is completely normal for a developer to start into one direction
and then later realize something and change his course.  In fact, many
parts of Git strive to help you avoid being bound by premature commitments
(e.g. "checkout [-m] <branch>" takes local changes with you).  I think
this discussion is only showing that the @{upstream} part wasn't as
carefully designed as other parts of the system.

>   2. I really just want everything based off of origin/master, because
>      that is an implicit part of my workflow for this project.

I think this probably shows that "autosetupmerge" mechanism is not
polished enough.  Perhaps it can take, in addition to "true/false", a ref
in refs/remotes namespace, or something.  If you have "these branches are
to be off of this, this other set of branches are to be off of that", it
may need to become more elaborate.

> I think that would perfectly fit my workflow. But I'm not sure if other
> people would be confused by these operations changing the upstream
> config (e.g., if you expect "jk/bug-fix" to have an upstream of
> "origin/jk/bug-fix", when such a change would not be welcome).

Yeah, the above is starting to sound a bit overengineered black magic.

>> Perhaps this can be a good sample entry for the experimental "tracker"
>> thing to keep track of to see how the workflow will evolve around it;
>> unless neither of us would get to work on it immediately, it is very
>> likely to be forgotten, as this is a tangent in the overall discussion,
>> even though the bug is real and solution is clear.

Heh, I find myself already forgetting what this "clear bug" was and having
to look up in your message (the issue is "git push $there" when $there
does not match branch.$current.remote, it should error out).

> I agree this is a candidate for that. But this is where the concept of
> the tracker breaks down. Who is supposed to update it? You or me? Some
> volunteer who agrees to migrate email discussion into the tracker?  I
> suspect the latter will not work for a point buried so deeply in a
> thread.  Which leaves you and me.

That is why I think any demand (I wouldn't call it "proposal" or
"suggestion") to this project to use tracker fundamentally is flawed.

> I specifically stayed out of the tracker discussion this time around
> because all I had to contribute was "please no, web-based tools are an
> abomination". But now that we see a potential use-case in practice, I am
> realizing that I would not mind at all making a note in a todo file, or
> even sending an email. But the thought of filling out a structured
> problem report to go into a web-based database makes me not want to
> bother.

I agree with this 100%.  If it takes more than just adding an email
address to Cc: line to either a tracker bot or a human project secretary,
I cannot be bothered to spend extra 10 minutes to go to an extra web site,
log-in and fill the form fields.

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

[Matthieu Moy]

Jeff King <peff@peff.net> writes:

> On Mon, Mar 12, 2012 at 05:37:32PM +0100, Matthieu Moy wrote:
>
>> * For newbies, the sequence "create an empty repository, clone it,
>>   commit and push" works like a charm with either 'upstream' or
>>   'current'. Today, the first push to an empty repository requires
>>   either saying "git push origin master" or "git push --all", both of
>>   which sound like black magic to the poor user who did not yet learn
>>   what 'origin' is and what a branch is.
>
> Ending that confusion is one of the best reasons to switch the default,
> IMHO, but I don't think it argues for "current" versus "upstream", as
> they both fix it (but Michael's matching-current hybrid would not, so I
> agree it is less appealing).

Exactly. It does not change the 'upstream' vs 'current' debate.

>> * 'upstream' makes it easy to create a local topic branch, and let
>>   'push' send it to the master branch (i.e. have local 'topic-branch'
>>   pull and push to 'origin/master'). In general, 'upstream' allows
>>   workflows where you push to branches with either a different name or
>>   with the same name (by setting the upstream appropriately), but the
>>   opposite is not true.
>
> Actually, this is the thing that scares me the most about "upstream" as
> a default, because in this case, you are implicitly performing the
> equivalent of a fast-forward merge. So that's handy if you are a new
> user who wants to publish your work back to the master branch. But that
> has two problems:
>
>   1. If you are a new user who does like the implicit merge, you may
>      find it convenient not to have to learn about "git checkout; git
>      merge topic ; git push remote master". But it only helps you
>      _sometimes_. If master has had other work built on it, your push
>      will fail, and you will have to do the merge yourself. So it is
>      only helping you by omitting a step some of the time, and you still
>      have to learn why the step is sometimes necessary and sometimes
>      not.

There's a rule of thumb which works very well for beginners: when "git
push" tells you to pull before, then pull before. This rule of thumb
works, but only provided "push" and "pull" are symmetrical.

My experience with teaching Git is that this is the number 1 issue with
beginners (I'm talking about students who didn't learn CVS/SVN before,
so real beginners). They try to push, the push fails, and they come to
me saying "Git is broken, we can't work". That's why I introduced the
advice about non-fast forward, and later added the mention (e.g. 'git
pull') to point users in the right direction when the push fails. It
considerably reduced my workload as teacher ;-).

Now, if pushing sends commits to a branch other than 'upstream', you can
get the following scenario:

$ git push
To bla
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'bla'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.
$ git pull
Already up-to-date.
$ git push
<still denied, wtf>

One can easily get in this situation even in a kernel-style workflow:
work from your desktop, push, work from your laptop, try to push and it
fails.

Back to my students, most of them will never get in this situation
because they won't use branch, so HEAD = master and upstream =
origin/master, but the not-so-newbies may get this once they start
creating branches ifever they have HEAD = topic-branch and upstream =
origin/master for example.

>   2. If you are a new user who _doesn't_ want to do the merge, but
>      instead wants to publish your work-in-progress topic, then the
>      implicit merge-back-to-master behavior is wrong and dangerous.
>      You are publishing work that probably violates the general rules
>      for what goes on master.

To me, this is the real argument in favor of 'current'. I think it is
less important than others, but that's obviously subjective.

In any case, I'm not opposed to 'current', and I think 'current' is a
better default than 'matching', but I'm still not convinced it is better
than 'upstream'.

>      Or perhaps somebody else has built on top of master, and your push
>      fails. If you're an astute reader, you will see that the failing
>      push tried to go to master. But if you're not, you may retry with
>      "-f", which is quite dangerous, as now you are not just
>      accidentally publishing a work-in-progress, but you are
>      overwriting somebody else's work. Obviously this is a problem
>      anytime you use "-f", but the fact that your "foo" branch is going
>      to somewhere besides the remote's "foo" branch makes me think it is
>      much more likely a clueless user will get confused and overwrite
>      something on the more "mainstream" branch.

I don't think 'current' Vs 'upstream' really changes that. You may get a
non-fast forward on your topic branch if you've push to it from another
machine for example.

> So far a lot of the discussion has focused on "what is the most sensible
> default for the most number of people". But I wonder if a better
> question is "what is the default that is the least likely to do
> something dangerous and embarrassing".

I think "what's the most intuitive" is also very important. If we're
talking about real, real newbies, the risk of pushing to the wrong
branch is marginal compared to the risk of giving up and say "Git
doesn't work, I'll send my files by email" (which is real in my
experience :'-( ). But your remark does apply to not-totally newbies
anymore, but not yet Git gurus.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Junio C Hamano]

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

> There's a rule of thumb which works very well for beginners: when "git
> push" tells you to pull before, then pull before. This rule of thumb
> works, but only provided "push" and "pull" are symmetrical.

I actually think the "pull before push again" was written with only
CVS style non-branching workflow in mind, in other words, only to
help somebody who works on his master against the central master.
Obviously "push and pull are symmetrical" holds true for that single
branch workflow, but that does not mean a more complex workflow must
be symmetrical.

Even though I think 'upstream' will be a superset of what 'current'
wants to do in an ideal world where the user configures everything
right (hence it ought to be the better default between the two), I
do not think that the target audience "let's change the default"
folks are trying to help is those who set @{upstream} correctly
point the destination for a branch they want to push to and leave it
unset for a strictly private branch. If we choose the default that
would primarily make it efficient for people who can configure
everything right, we are missing the point of this discussion. I
think the target audience to be helped is the people who do not
(yet) do anything complex, and the point of this discussion is to
help them avoid getting surprised.

And by "surprised", I do not necessarily mean "dangerous". While we
should aim to avoid "dangerous", we should avoid "ununderstandable"
even more.

Pushing 'current' from a branch 'topic' forked from either 'master'
or 'origin/master' will create a new branch 'topic' at the central
repository. But that is straightforward and understandable. The user
will see what happened in the feedback from the command, and there
is no need for the user to be experienced enough to know the mapping
of @{upstream} to understand why it happened.  "I am on 'topic' and
I pushed, I created 'topic' there".  Very simple explanation exists.

On the other hand, the user needs to know not just 'branch' but also
understand the concept of @{upstream} in order to use 'upstream'
without surprise.  When something goes wrong, prerequisite knowledge
that is required to understand it is greater.  Also the current
implementation of 'upstream' has some weird semantics (or undesigned
bugs) pointed out by Peff, which would make it even more confusing.

That makes me suspect that 'current' might be a more appropriate
default between the two. From that simple default, those in the
"shared central repository" world can graduate to 'upstream' once
they know what an 'upstream' is and how to take advantage of
per-branch configuration.  Similarly, those in the "publish to be
pulled" world would graduate to 'matching'.

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

[Matthieu Moy]

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

> I actually think the "pull before push again" was written with only
> CVS style non-branching workflow in mind, in other words, only to
> help somebody who works on his master against the central master.

It doesn't have much to do with branching/non-branching. You may use
branches, and still work collaboratively on them. There was an example
above in the same thread:

  http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694

There are also cases like "I pushed from my laptop and I'm back to my
desktop", or "the content has been edited from GitHub's web interface".

Actually, I hardly see a case where "pull before push again" (with or
without --rebase or such) is wrong for a beginner.

> Pushing 'current' from a branch 'topic' forked from either 'master'
> or 'origin/master' will create a new branch 'topic' at the central
> repository. But that is straightforward and understandable. The user
> will see what happened in the feedback from the command, and there
> is no need for the user to be experienced enough to know the mapping
> of @{upstream} to understand why it happened.  "I am on 'topic' and
> I pushed, I created 'topic' there".  Very simple explanation exists.

Very simple explanation exist for what "push" does, but not for "the
global picture of what push and pull do". And really, the case "Git
prevents me from pushing, I don't know what to do" is a problem for
people who don't get the whole remote/branch/upstream/... things.

Actually, I'm starting to wonder if the whole "upstream" thing should
not be deactivated by default, and replaced with a simpler mechanism
like "pull.default", similar to what "push.default" does today. Then,
users could set "pull.default=current", and "git pull" would pull a
branch with the same name remotely. Or users could set
"pull.default=upstream" and get what Git does today.

But that's a much larger change, then ...

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Auto-matching upstream branches by name (was: [RFC PATCH] push: start warning upcoming default change for push.default)

[Stefan Haller]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

> Actually, I'm starting to wonder if the whole "upstream" thing should
> not be deactivated by default, and replaced with a simpler mechanism
> like "pull.default", similar to what "push.default" does today. Then,
> users could set "pull.default=current", and "git pull" would pull a
> branch with the same name remotely. Or users could set
> "pull.default=upstream" and get what Git does today.

Yes, this is pretty similar to what I had in mind, in the last paragraph
of this message:

   http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694

But it's not just about pull versus push. If you make them both work
with same-name branches automatically, you still need to make "status"
and "branch -vv" aware of that too, so that they can report whether you
are ahead or behind your, well, "upstream".  "git log @{u}" would be
nice as well in this mode.

So I think that "pull.default" is not the best option to use for this;
maybe something like "branch.automatchupstreambyname" or some such.

(It's really a separate discussion from the push.default question
though, so I'm changing the subject.)


-- 
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/

Re: Auto-matching upstream branches by name

[Matthieu Moy]

lists@haller-berlin.de (Stefan Haller) writes:

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>
>> Actually, I'm starting to wonder if the whole "upstream" thing should
>> not be deactivated by default, and replaced with a simpler mechanism
>> like "pull.default", similar to what "push.default" does today. Then,
>> users could set "pull.default=current", and "git pull" would pull a
>> branch with the same name remotely. Or users could set
>> "pull.default=upstream" and get what Git does today.
>
> Yes, this is pretty similar to what I had in mind, in the last paragraph
> of this message:
>
>    http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694

Indeed, yes.

> But it's not just about pull versus push. If you make them both work
> with same-name branches automatically, you still need to make "status"
> and "branch -vv" aware of that too, so that they can report whether you
> are ahead or behind your, well, "upstream".  "git log @{u}" would be
> nice as well in this mode.
>
> So I think that "pull.default" is not the best option to use for this;
> maybe something like "branch.automatchupstreambyname" or some such.

I'd call that 'upstream.default' actually.

> (It's really a separate discussion from the push.default question
> though, so I'm changing the subject.)

Separate, but related. If Git had this behavior as default, I'd
recommend 'current' without hesitation. I'm starting to be convinced
that the whole 'upstream' stuff is confusing for non-expert, but it is
for pull as much as it is for push.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Marc Branchaud]

On 12-03-13 09:17 AM, Junio C Hamano wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> 
>> There's a rule of thumb which works very well for beginners: when "git
>> push" tells you to pull before, then pull before. This rule of thumb
>> works, but only provided "push" and "pull" are symmetrical.
> 
> I actually think the "pull before push again" was written with only
> CVS style non-branching workflow in mind, in other words, only to
> help somebody who works on his master against the central master.
> Obviously "push and pull are symmetrical" holds true for that single
> branch workflow, but that does not mean a more complex workflow must
> be symmetrical.
> 
> Even though I think 'upstream' will be a superset of what 'current'
> wants to do in an ideal world where the user configures everything
> right (hence it ought to be the better default between the two), I
> do not think that the target audience "let's change the default"
> folks are trying to help is those who set @{upstream} correctly
> point the destination for a branch they want to push to and leave it
> unset for a strictly private branch. If we choose the default that
> would primarily make it efficient for people who can configure
> everything right, we are missing the point of this discussion. I
> think the target audience to be helped is the people who do not
> (yet) do anything complex, and the point of this discussion is to
> help them avoid getting surprised.
> 
> And by "surprised", I do not necessarily mean "dangerous". While we
> should aim to avoid "dangerous", we should avoid "ununderstandable"
> even more.
> 
> Pushing 'current' from a branch 'topic' forked from either 'master'
> or 'origin/master' will create a new branch 'topic' at the central
> repository. But that is straightforward and understandable. The user
> will see what happened in the feedback from the command, and there
> is no need for the user to be experienced enough to know the mapping
> of @{upstream} to understand why it happened.  "I am on 'topic' and
> I pushed, I created 'topic' there".  Very simple explanation exists.
> 
> On the other hand, the user needs to know not just 'branch' but also
> understand the concept of @{upstream} in order to use 'upstream'
> without surprise.  When something goes wrong, prerequisite knowledge
> that is required to understand it is greater.  Also the current
> implementation of 'upstream' has some weird semantics (or undesigned
> bugs) pointed out by Peff, which would make it even more confusing.
> 
> That makes me suspect that 'current' might be a more appropriate
> default between the two. From that simple default, those in the
> "shared central repository" world can graduate to 'upstream' once
> they know what an 'upstream' is and how to take advantage of
> per-branch configuration.  Similarly, those in the "publish to be
> pulled" world would graduate to 'matching'.

Good points!

I think someone who's figuring out their workflow as they go would appreciate
the simplicity offered by "current".

You've changed my mind:  I now think "current" is the better default.

		M.

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

[Holger Hellmuth]

On 13.03.2012 14:17, Junio C Hamano wrote:
> that is required to understand it is greater.  Also the current
> implementation of 'upstream' has some weird semantics (or undesigned
> bugs) pointed out by Peff, which would make it even more confusing.

If Peff's "push to same branch in a different remote" is a bug (and IMHO 
it is) it should not count as a reason for what should be the default.

One small point in favor of "current" I haven't seen mentioned: It is 
the smaller/more compatible change from the "matching" behaviour.

The most important point for me in the discussion up till now (because 
it matches my newbie experiences): It doesn't matter that much for new 
users whether "current" or "upstream" is default, because they mostly 
work on master and create branches from local master.

But in that case the typical situation where the default comes into play 
will be when they accidentally are on a branch other than master and try 
to use 'git push'. In that case "current" would push (wrongly) to a 
similar named branch on the remote while upstream would not because the 
local branch would have no upstream configured. Small point in favor of 
"upstream"

The symmetry is what really makes me vote for "upstream". Both 
"upstream" and "current" play to the expectations of new users, 
"upstream" because of the symmetry and "current" because they usually 
expect some connection between branches of the same name in different 
repositories. But only upstream will help those who want to cure git 
push with git pull. And that would be the whole crowd having just a 
whiff of experience with cvs or svn. And if I could take a guess, that 
is the case for the majority of computer science students at a typical 
university (the rest mostly having no experience with version control at 
all)



By the way, the documentation is very confusing in its description what 
git push without parameters does. For example it is not really explained 
in the description or options part, the only explanation is in the 
Examples. There "git push" points to "git push origin" and:
-------------
"git push origin
            Without additional configuration, works like git push origin :.

            The default behavior of this command when no <refspec> is 
given can be configured by setting the push option of the
            remote.
------------

Now the refspec documentation never says anything about what '.' means 
(the only docu about refspecs I could find is in pull-fetch-param.txt 
that is included by git-fetch and git-pull. I thought there was another 
manpage about refspecs but I couldn't find it).
And shouldn't the second sentence above be "... can be configured by 
setting the push.default option of the remote" ?

Is this patchworthy (in that case I'll try to make one) or did I just 
not read at the right places?

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

[Junio C Hamano]

Holger Hellmuth <hellmuth@ira.uka.de> writes:

> On 13.03.2012 14:17, Junio C Hamano wrote:
>> that is required to understand it is greater.  Also the current
>> implementation of 'upstream' has some weird semantics (or undesigned
>> bugs) pointed out by Peff, which would make it even more confusing.
>
> If Peff's "push to same branch in a different remote" is a bug (and
> IMHO it is) it should not count as a reason for what should be the
> default.

I may phrased it poorly, but I don't think you mean "if the bug is fixed,
then the behaviour of upstream is simple and easy to understand".  The
very reason the bug exists in the first place is that the semantics that
mode wants to give its users is complex enough that even the people who
should know (i.e. those who implement it) overlooked that there is a
corner case their implementation was not handling. It is a demonstration
that upstream is not an easy-to-understand choice to throw at new people.

> By the way, the documentation is very confusing in its description
> what git push without parameters does. For example it is not really
> explained in the description or options part, the only explanation is
> in the Examples. There "git push" points to "git push origin" and:
> -------------
> "git push origin
>            Without additional configuration, works like git push origin :.
>
>            The default behavior of this command when no <refspec> is
> given can be configured by setting the push option of the
>            remote.
> ------------
>
> Now the refspec documentation never says anything about what '.' means
> (the only docu about refspecs I could find is in pull-fetch-param.txt

That should read:

	... works like "git push origin :".

That dot you see after the colon is a full-stop for the sentence, not a
part of any refspec.


> Is this patchworthy (in that case I'll try to make one) or did I just
> not read at the right places?

It is patch-worthy; you already know that it made you waste time looking
for ':.'---the documentation shouldn't have done that.

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

[Holger Hellmuth]

On 13.03.2012 18:41, Junio C Hamano wrote:
> Holger Hellmuth<hellmuth@ira.uka.de>  writes:
>> If Peff's "push to same branch in a different remote" is a bug (and
>> IMHO it is) it should not count as a reason for what should be the
>> default.
>
> I may phrased it poorly, but I don't think you mean "if the bug is fixed,
> then the behaviour of upstream is simple and easy to understand".  The

I think the behaviour of the whole pull/push system is not easy to 
understand. One has to learn a lot of concepts about git before being 
able to answer the simple question "if I do 'git push' now, what happens?".

Since I am using git without any collaboration I never had much need to 
play around with the whole porcelain remote configuration (cloning and 
using git config was enough). So today I tried to create a bidirectional 
link between a local and a remote branch using only porcelain commands 
(i.e. without using git config directly). Somehow I didn't succeed. I 
can either use git checkout --track or git push -u to make a pull 
connection between the two, but to automatically push I would have to 
create a branch of the same name (and know that this is the magical 
ingredient that makes it work!)

Maybe what is missing is a parameter to git-push that tells git that 
from now on this is what git push should do per default in this branch 
(Similar to what git checkout --track does). This would mean that even 
new users could do most remote configuration with just the knowledge of 
git checkout and git push.

By the way I think I found another "hole" in the porcelain: If you add a 
single branch to follow with git remote add -t <branch> ..., you can't 
add another. A second git remote add -t <otherbranch> ... will be met 
with an error that the remote is already configured. I would have to 
delete the remote and add it again with git add -t <branch> -t 
<otherbranch> ..... Or use a different remote name (which would be 
confusing later on). Did I miss something?

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

[Matthieu Moy]

Holger Hellmuth <hellmuth@ira.uka.de> writes:

> So today I tried to create a
> bidirectional link between a local and a remote branch using only
> porcelain commands (i.e. without using git config directly). Somehow I
> didn't succeed. I can either use git checkout --track or git push -u
> to make a pull connection between the two, but to automatically push I
> would have to create a branch of the same name (and know that this is
> the magical ingredient that makes it work!)

In this particular case, having 'push.default=upstream' would have done
it for you: your "push -u" would have set up the upstream, and the next
"push" would have followed it.

(or you could "git push remote local-branch:remote-branch")

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Holger Hellmuth]

On 15.03.2012 09:02, Matthieu Moy wrote:
> Holger Hellmuth<hellmuth@ira.uka.de>  writes:
>
>> So today I tried to create a
>> bidirectional link between a local and a remote branch using only
>> porcelain commands (i.e. without using git config directly). Somehow I
>> didn't succeed. I can either use git checkout --track or git push -u
>> to make a pull connection between the two, but to automatically push I
>> would have to create a branch of the same name (and know that this is
>> the magical ingredient that makes it work!)
>
> In this particular case, having 'push.default=upstream' would have done
> it for you: your "push -u" would have set up the upstream, and the next
> "push" would have followed it.

I know, this is why I voted for "upstream", but there are good reasons 
for "current" too. Whatever is decided on will still get some users by 
surprise.

> (or you could "git push remote local-branch:remote-branch")
>

Sure, I can believe that a new user will be able to get at that line 
after studying the "git push" manual page (or reading a tutorial), but I 
really doubt he will easily find out where to go from there to simplify 
that line. And typing that line every time for a permanent connection is 
out of the question, right?

That is why I think git push --track remote local-branch:remote-branch 
(or --permanent, --perm, --follow, --configure, --keep) would be a great 
help because a tutorial wouldn't have to talk about a lot of special 
cases, config options, it could just explain:

-----------------------------
1) To follow a remote repository do "git remote add <repo> <url>
2) To follow a remote branch do "git checkout [-b localbranch] --track 
<repo>/<branch>. Then "git pull" while in this branch will synchronize 
you whenever you want to be up-to-date.
3) To get a remote branch to follow you do "git push --track <repo> 
<local-branch>:<branch> once. Then "git push" while in this branch will 
synchronize the remote branch.
-----------------------------

With this simple recipe 90% of all workflows could be configured by a 
novice without embarrasing himself. Can you find a similar simple and 
consise recipe that would work today (even with upstream or current) ? I 
doubt it.

Sorry about opening up another tangent, but this is somewhat connected. 
If we give the novice an easy instrument to configure what he really 
wants then the default becomes much less important.

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

[Andreas Ericsson]

On 03/13/2012 02:17 PM, Junio C Hamano wrote:
> Matthieu Moy<Matthieu.Moy@grenoble-inp.fr>  writes:
> 
>> There's a rule of thumb which works very well for beginners: when "git
>> push" tells you to pull before, then pull before. This rule of thumb
>> works, but only provided "push" and "pull" are symmetrical.
> 
> I actually think the "pull before push again" was written with only
> CVS style non-branching workflow in mind, in other words, only to
> help somebody who works on his master against the central master.
> Obviously "push and pull are symmetrical" holds true for that single
> branch workflow, but that does not mean a more complex workflow must
> be symmetrical.
> 
> Even though I think 'upstream' will be a superset of what 'current'
> wants to do in an ideal world where the user configures everything
> right (hence it ought to be the better default between the two), I
> do not think that the target audience "let's change the default"
> folks are trying to help is those who set @{upstream} correctly
> point the destination for a branch they want to push to and leave it
> unset for a strictly private branch. If we choose the default that
> would primarily make it efficient for people who can configure
> everything right, we are missing the point of this discussion. I
> think the target audience to be helped is the people who do not
> (yet) do anything complex, and the point of this discussion is to
> help them avoid getting surprised.
> 
> And by "surprised", I do not necessarily mean "dangerous". While we
> should aim to avoid "dangerous", we should avoid "ununderstandable"
> even more.
> 
> Pushing 'current' from a branch 'topic' forked from either 'master'
> or 'origin/master' will create a new branch 'topic' at the central
> repository. But that is straightforward and understandable. The user
> will see what happened in the feedback from the command, and there
> is no need for the user to be experienced enough to know the mapping
> of @{upstream} to understand why it happened.  "I am on 'topic' and
> I pushed, I created 'topic' there".  Very simple explanation exists.
> 
> On the other hand, the user needs to know not just 'branch' but also
> understand the concept of @{upstream} in order to use 'upstream'
> without surprise.  When something goes wrong, prerequisite knowledge
> that is required to understand it is greater.  Also the current
> implementation of 'upstream' has some weird semantics (or undesigned
> bugs) pointed out by Peff, which would make it even more confusing.
> 
> That makes me suspect that 'current' might be a more appropriate
> default between the two. From that simple default, those in the
> "shared central repository" world can graduate to 'upstream' once
> they know what an 'upstream' is and how to take advantage of
> per-branch configuration.  Similarly, those in the "publish to be
> pulled" world would graduate to 'matching'.


Sensible sentiments, sir.

Even with advanced usage, 'current' is what I think does the right
thing in 99% of all cases, and it errs on the side of "least extra
work when things go wrong".

The questions to ask, I think, are these:
* What would newcomers to git expect?
You answered this nicely.

* What does advanced users use *most of the time*?
At $dayjob, 99.9% of all pushes are to get the changes of the current
branch to the sharepoint repo. Once in a while (when tagging, usually
whatnot) for some repositories, I wish to push maint and master to a
public repository for the masses to use. This happens roughly once
every 200 commits, according to a quick "git log" in two repos, but
only for about 10 or so of the 60-odd repos we're maintaining, and
only for two of the six developers working on them.
It's very rare that I work on multiple already-created topics and
they all finish at the same time. At most, I wish to push "maint"
and "master" in one go.

If I notice I've done the bad push, I need to make sure noone else
fetched the thing during the time it takes me to undo the push, or
I may have to quickly fix up the potentially broken branch. Either
way, it can be a lot of work that I rarely have time for right then.


* What causes the least damage when the default is less suitable?
Quite a few times I've managed to push work-in-progress commits to
random topics at work with the default "matching". If I miss that
I've done so, undoing the damage is a great big pain in the butt,
since it means either force-pushing to sharepoint or un-bisectable
commits. The worst case for "current" would be if I merge one branch
to master, forget to push the merged branch but do push 'master'
to our sharepoint, and then someone else comes along and works a
bit more on the topic I accidentally didn't push. When that happens,
I can quite easily rebase my changes on top of the other devs, or
merge with the sharepoint changes, and then re-merge to master
without having to call a flag-day for the devs working on the same
project.

If I notice I've forgotten to push, I can just push again immediately
and git will handle any errors for me. It never leads to any extra
work for me, and never stalls anyone else from progressing with their
own tasks.


In light of that, "current" is really the only sensible way to go.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

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

[Jeff King]

On Tue, Mar 13, 2012 at 06:17:13AM -0700, Junio C Hamano wrote:

> Pushing 'current' from a branch 'topic' forked from either 'master'
> or 'origin/master' will create a new branch 'topic' at the central
> repository. But that is straightforward and understandable. The user
> will see what happened in the feedback from the command, and there
> is no need for the user to be experienced enough to know the mapping
> of @{upstream} to understand why it happened.  "I am on 'topic' and
> I pushed, I created 'topic' there".  Very simple explanation exists.
> [...]
> That makes me suspect that 'current' might be a more appropriate
> default between the two. From that simple default, those in the
> "shared central repository" world can graduate to 'upstream' once
> they know what an 'upstream' is and how to take advantage of
> per-branch configuration.  Similarly, those in the "publish to be
> pulled" world would graduate to 'matching'.

Thanks for this explanation. When writing my last email, I had a gut
feeling about how "current" was a simpler choice, but I didn't quite
find the words to explain it. This paragraph (and the rest of the email)
covers what I was trying to say.

-Peff

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

[Dmitry Potapov]

On Tue, Mar 13, 2012 at 1:34 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Jeff King <peff@peff.net> writes:
>
>>   1. If you are a new user who does like the implicit merge, you may
>>      find it convenient not to have to learn about "git checkout; git
>>      merge topic ; git push remote master". But it only helps you
>>      _sometimes_. If master has had other work built on it, your push
>>      will fail, and you will have to do the merge yourself. So it is
>>      only helping you by omitting a step some of the time, and you still
>>      have to learn why the step is sometimes necessary and sometimes
>>      not.
>
> There's a rule of thumb which works very well for beginners: when "git
> push" tells you to pull before, then pull before. This rule of thumb
> works, but only provided "push" and "pull" are symmetrical.

I am not sure what you mean by symmetrical here, because they are never
truly symmetrical as "pull" does merge and "push" does not. If there is
a centralized workflow with only one branch then everything is simple,
but it is not so with other workflows.

Moreover, doing 'git pull' too often (unless it is 'git pull --rebase)
pollutes history with useless merges, making more difficult to review
changes, or doing git-bisect.

> Now, if pushing sends commits to a branch other than 'upstream', you can
> get the following scenario:
>
> $ git push
> To bla
>  ! [rejected]        master -> master (non-fast-forward)
> error: failed to push some refs to 'bla'

I agree that the current diagnostic is not suitable for beginners.
Not-fast-forward push is something that beginners should never use,
but from this message is not clear what is the alternative to forcing
non-fast-forward push.

> One can easily get in this situation even in a kernel-style workflow:
> work from your desktop, push, work from your laptop, try to push and it
> fails.

IMHO, when you often switch between your desktop and laptop, 'matching'
makes much more sense. If 'push' fails then usually I want to force non-
fast-forward push, because the new series contain reworked patches that
already were on the other computer.

>
> Back to my students, most of them will never get in this situation
> because they won't use branch, so HEAD = master and upstream =
> origin/master,

So, there is no real difference between 'current' and 'upstream' for
them.

> but the not-so-newbies may get this once they start
> creating branches ifever they have HEAD = topic-branch and upstream =
> origin/master for example.

The real question is what one expects from 'push' in that situation. It
could be pushing this branch back to the upstream branch or creating a
new feature branch in the upstream.

>
>> So far a lot of the discussion has focused on "what is the most sensible
>> default for the most number of people". But I wonder if a better
>> question is "what is the default that is the least likely to do
>> something dangerous and embarrassing".
>
> I think "what's the most intuitive" is also very important.

But it depends on the workflow that is employed by the project.
Different projects may have different workflows. We can assume that
the person who sets up the repository has good knowledge of Git and
how to use it, but many others who work on the same project may not
know Git well. For them "the most intuitive" means whatever policy
this project has.


Dmitry

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

[Junio C Hamano]

Dmitry Potapov <dpotapov@gmail.com> writes:

>> One can easily get in this situation even in a kernel-style workflow:
>> work from your desktop, push, work from your laptop, try to push and it
>> fails.
>
> IMHO, when you often switch between your desktop and laptop, 'matching'
> makes much more sense. If 'push' fails then usually I want to force non-
> fast-forward push, because the new series contain reworked patches that
> already were on the other computer.

You are free to live dangerously, but please do not teach that to other
people.

Switching between two machines A and B is done a lot more safely if you
arrange them to cross pull from each other, i.e. on machine A, remotes/B/*
is where you keep copies of branches of B to with either of these

	machineA$ git fetch B refs/heads/*:refs/remotes/B/*
	machineB$ git push A refs/heads/*:refs/remotes/B/*

(the latter is to emulate the former "fetch" you wish to run on A to get
data from B in the reverse direction), and similarly on machine B, you use
remotes/A/* to keep copies of branches of A.

That way, the risk of losing your work because the "usually" in your "then
usually I want to force" turns out to be untrue is greatly reduced.

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

[Dmitry Potapov]

On Wed, Mar 14, 2012 at 8:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Dmitry Potapov <dpotapov@gmail.com> writes:
>
>>> One can easily get in this situation even in a kernel-style workflow:
>>> work from your desktop, push, work from your laptop, try to push and it
>>> fails.
>>
>> IMHO, when you often switch between your desktop and laptop, 'matching'
>> makes much more sense. If 'push' fails then usually I want to force non-
>> fast-forward push, because the new series contain reworked patches that
>> already were on the other computer.
>
> You are free to live dangerously, but please do not teach that to other
> people.

Is it more dangerous than using "git reset --hard somewhere" ?
I believe both cases I should be able to recover the lost using reflog.
Anyway, so far I have never had any problem, because I do "git push"
first and then look at failures and decide whether I want to discard
the old series on the remote end.

> Switching between two machines A and B is done a lot more safely if you
> arrange them to cross pull from each other, i.e. on machine A, remotes/B/*
> is where you keep copies of branches of B to with either of these
>
>        machineA$ git fetch B refs/heads/*:refs/remotes/B/*
>        machineB$ git push A refs/heads/*:refs/remotes/B/*
>
> (the latter is to emulate the former "fetch" you wish to run on A to get
> data from B in the reverse direction), and similarly on machine B, you use
> remotes/A/* to keep copies of branches of A.

I am aware about that, but the thing that stops me from using this is
there is no way to delete automatically all references from the remote
end that were deleted locally. (There is --mirror option, which can do
this, but it is incompatible with refspecs)

If I use only "git fetch B ...", I can run "git remote prune B" from time
to time to remove branches that no longer exists on B. However, if I do
"git push A ..." as you suggested then A will accumulate old garabage
from B very quickly.


Dmitry

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

[Junio C Hamano]

Dmitry Potapov <dpotapov@gmail.com> writes:

> ... However, if I do
> "git push A ..." as you suggested then A will accumulate old garabage
> from B very quickly.

That is not a valid excuse, is it?
It only shows that lack of "push --prune A" is a problem to be solved.

And hasn't it been solved already?

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

[Dmitry Potapov]

On Wed, Mar 14, 2012 at 9:29 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Dmitry Potapov <dpotapov@gmail.com> writes:
>
>> ... However, if I do
>> "git push A ..." as you suggested then A will accumulate old garabage
>> from B very quickly.
>
> That is not a valid excuse, is it?

Maybe not, but so far I have never had any problem with the way I use now.
So I have not had any real insensitive to change that. Though I agree that
what you proposed is better except pruning deleted branches.

> It only shows that lack of "push --prune A" is a problem to be solved.
>
> And hasn't it been solved already?
>

Has it? Somehow I cannot find the corresponding option in the manual.
What did I miss?

Dmitry

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

[Junio C Hamano]

Dmitry Potapov <dpotapov@gmail.com> writes:

>> It only shows that lack of "push --prune A" is a problem to be solved.
>>
>> And hasn't it been solved already?
>
> Has it? Somehow I cannot find the corresponding option in the manual.
> What did I miss?

What you are missing is that you are not running 1.7.10-rc to help shaking
out last minute regressions.

Please be a good resident on this list and help us out ;-)

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

[Matthieu Moy]

Dmitry Potapov <dpotapov@gmail.com> writes:

> On Tue, Mar 13, 2012 at 1:34 PM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Jeff King <peff@peff.net> writes:
>>
>>>   1. If you are a new user who does like the implicit merge, you may
>>>      find it convenient not to have to learn about "git checkout; git
>>>      merge topic ; git push remote master". But it only helps you
>>>      _sometimes_. If master has had other work built on it, your push
>>>      will fail, and you will have to do the merge yourself. So it is
>>>      only helping you by omitting a step some of the time, and you still
>>>      have to learn why the step is sometimes necessary and sometimes
>>>      not.
>>
>> There's a rule of thumb which works very well for beginners: when "git
>> push" tells you to pull before, then pull before. This rule of thumb
>> works, but only provided "push" and "pull" are symmetrical.
>
> I am not sure what you mean by symmetrical here, because they are never
> truly symmetrical as "pull" does merge and "push" does not.

I mean "they work with the same branch".

> If there is a centralized workflow with only one branch then
> everything is simple, but it is not so with other workflows.

I don't get this. With either 'current' or 'upstream', both pull and
push deal with one local and one remote branch. The only asymetry is the
case of non-fast forward (push fails, pull merges). But it's all about
transmitting changes from a branch to another, in one or another
direction.

> Moreover, doing 'git pull' too often (unless it is 'git pull --rebase)
> pollutes history with useless merges, making more difficult to review
> changes, or doing git-bisect.

What's your point here? How does it invalidate the rule of thumb above?

Whether you want to pull often or not, it does not change the fact that
you cannot do non-fast forward push (at least, not without losing
history). If the user tried to push, what would you suggest if not
pulling (or merging in whatever way you want)? Blame the user who wanted
to push that he shouldn't have tried that?

> I agree that the current diagnostic is not suitable for beginners.
> Not-fast-forward push is something that beginners should never use,
> but from this message is not clear what is the alternative to forcing
> non-fast-forward push.

Again, what would you suggest? Teach --force to beginners?

>> One can easily get in this situation even in a kernel-style workflow:
>> work from your desktop, push, work from your laptop, try to push and it
>> fails.
>
> IMHO, when you often switch between your desktop and laptop, 'matching'
> makes much more sense.

Then, if you worked on branch 'foo' from your desktop, and 'bar' on your
laptop, you'll get errors about non-fast forward push from both machines.

> If 'push' fails then usually I want to force non- fast-forward push,
> because the new series contain reworked patches that already were on
> the other computer.

... but if they were not, you've just silently errased your previous
work. I have no problem with you working like this, but please don't
teach that to beginners.

>> but the not-so-newbies may get this once they start
>> creating branches ifever they have HEAD = topic-branch and upstream =
>> origin/master for example.
>
> The real question is what one expects from 'push' in that situation. It
> could be pushing this branch back to the upstream branch or creating a
> new feature branch in the upstream.

Yes. But both of them are covered by 'push.default=upstream', depending
on how you configured the upstream.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Dmitry Potapov]

On Wed, Mar 14, 2012 at 1:07 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Dmitry Potapov <dpotapov@gmail.com> writes:
>
>> If there is a centralized workflow with only one branch then
>> everything is simple, but it is not so with other workflows.
>
> I don't get this. With either 'current' or 'upstream', both pull and
> push deal with one local and one remote branch. The only asymetry is the
> case of non-fast forward (push fails, pull merges). But it's all about
> transmitting changes from a branch to another, in one or another
> direction.

If a user has 'master' after cloning and then create another branch
with different names, are you sure that the user expects that this
second branch to be pushed to a remote 'master'? And then what about
his stale local 'master'?

Those who understand the concept tracking may be happy with 'upstream'
but when it comes to the least surprise principle for beginner , I
believe 'current' is better. Maybe it would be even better if it did
not create a new remote branch without asking first:

Staying on foo-branch, you do:
 $ git push
Warning: foo-branch does not exist on the remote, if you want to
create it, type: "git push foo-branch"

In this way, it will be safer.

>
>> Moreover, doing 'git pull' too often (unless it is 'git pull --rebase)
>> pollutes history with useless merges, making more difficult to review
>> changes, or doing git-bisect.
>
> What's your point here? How does it invalidate the rule of thumb above?

The point is that you still need to understand what you are doing. It
is not 'pull' magically resolve the problem. On the other hand, if you
really want a workflow similar to CVS then you need "git pull --rebase"
(you can configure 'pull' to do rebase by default, but beginners do not
know about it).

BTW, whether you do merge or rebase, you still need to test the result
before pushing. Even if there was no conflicts, it may not work anymore.
And while you are merging and testing everything, somebody else could
push his changes. So, a centralized workflow may appear simple, but it
does not scale well, and often leads to many untested and hastily merged
commits.

>> I agree that the current diagnostic is not suitable for beginners.
>> Not-fast-forward push is something that beginners should never use,
>> but from this message is not clear what is the alternative to forcing
>> non-fast-forward push.
>
> Again, what would you suggest? Teach --force to beginners?

Not of course. I said above non-fast forward push should not be used by
beginners. However, if you have branches and merge them (using 'pull' or
'merge'), it is silly pretend that they do not exist. If you happy with
CVS-like behavior then just do "pull --rebase".

>
>>> One can easily get in this situation even in a kernel-style workflow:
>>> work from your desktop, push, work from your laptop, try to push and it
>>> fails.
>>
>> IMHO, when you often switch between your desktop and laptop, 'matching'
>> makes much more sense.
>
> Then, if you worked on branch 'foo' from your desktop, and 'bar' on your
> laptop, you'll get errors about non-fast forward push from both machines.

Right... and then I look at the cause, and usually I have made some
minor fixes to some series of patches. So when I make my mind, I do
non-fast forward push, but I do not think it is how beginners should
start to use 'git'.

>
>> If 'push' fails then usually I want to force non- fast-forward push,
>> because the new series contain reworked patches that already were on
>> the other computer.
>
> ... but if they were not, you've just silently errased your previous
> work. I have no problem with you working like this, but please don't
> teach that to beginners.

Basically, it is same as doing 'git reset --hard somewhere'. I use it
sometimes, but I have never suggested that for beginners...


Dmitry

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

[Matthieu Moy]

Dmitry Potapov <dpotapov@gmail.com> writes:

> Not of course. I said above non-fast forward push should not be used by
> beginners.

Do you mean "beginners should not force non-fast forward push", or
"beginners should not use flow where push may be denied because of
non-fast forward"?

If the second, this implies that beginners should never have a shared
repository, either shared for one user and multiple machines, or shared
between developers?

If you mean that shared repositories are too complex for beginners, my
experience is exactly the opposite.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Dmitry Potapov]

On Wed, Mar 14, 2012 at 6:47 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Dmitry Potapov <dpotapov@gmail.com> writes:
>
>> Not of course. I said above non-fast forward push should not be used by
>> beginners.
>
> Do you mean "beginners should not force non-fast forward push", or
> "beginners should not use flow where push may be denied because of
> non-fast forward"?

Of course, the former. I have never said that the centralized workflow
should never been used. I have only said that it is not scalable and
lead to problems in larger projects.

> If the second, this implies that beginners should never have a shared
> repository,

Well, you can set up a shared repository where everyone has their own
namespaces to push. I don't say that that it is better than having one
public repository per user, but it may be easier to setup...

So it only implies that you cannot have a centralized workflow in this
way.

> either shared for one user and multiple machines, or shared
> between developers?

I am not sure that I understood this part.

> If you mean that shared repositories are too complex for beginners, my
> experience is exactly the opposite.

It is not too complex but it is wrong for any more or less serious project.
Git is flexible enough to cover different workflows, including some variant
of a centralized workflow, but git was not designed with the centralized
workflow in mind. So some trade-offs are different in it than in VCS that
were designed primary (if not only) to be used with a centralized workflow.
IMHO if you teach git then you should teach a distributed workflow,
because it is the workflow where advantages of git is most obvious...

Dmitry

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

[Matthieu Moy]

Dmitry Potapov <dpotapov@gmail.com> writes:

> On Wed, Mar 14, 2012 at 6:47 PM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Dmitry Potapov <dpotapov@gmail.com> writes:
>>
>>> Not of course. I said above non-fast forward push should not be used by
>>> beginners.
>>
>> Do you mean "beginners should not force non-fast forward push", or
>> "beginners should not use flow where push may be denied because of
>> non-fast forward"?
>
> Of course, the former. I have never said that the centralized workflow
> should never been used. I have only said that it is not scalable and
> lead to problems in larger projects.

Then I don't follow you. The starting point of the discussion was my
rule of thumb about push/pull:

| There's a rule of thumb which works very well for beginners: when "git
| push" tells you to pull before, then pull before. This rule of thumb
| works, but only provided "push" and "pull" are symmetrical.

I can rephrase the end as "... provided 'push' pushes to the same branch
'pull' pulls from" (i.e. provided push.default=upstream).

Can you explain what you disagree with here? Or do you actually agree
with it?

Then, I showed the message of "git push" in the non-fast forward case,
which suggests that the user should pull, and you said:

| I agree that the current diagnostic is not suitable for beginners.

Again, what do you mean? What diagnosis would you suggest, if not
pulling?

>> either shared for one user and multiple machines, or shared
>> between developers?
>
> I am not sure that I understood this part.

I mean that a repository can be shared because multiple developers have
acces to it, or because the same developer has several clones.

>> If you mean that shared repositories are too complex for beginners, my
>> experience is exactly the opposite.
>
> It is not too complex but it is wrong for any more or less serious
> project.

I never argued against distributed development. I'm saying that
centralized development also makes sense, especially with beginners.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Michael Haggerty]

On 03/12/2012 07:37 PM, Jeff King wrote:
> On Mon, Mar 12, 2012 at 05:37:32PM +0100, Matthieu Moy wrote:
>> * For newbies, the sequence "create an empty repository, clone it,
>>   commit and push" works like a charm with either 'upstream' or
>>   'current'. Today, the first push to an empty repository requires
>>   either saying "git push origin master" or "git push --all", both of
>>   which sound like black magic to the poor user who did not yet learn
>>   what 'origin' is and what a branch is.
> 
> Ending that confusion is one of the best reasons to switch the default,
> IMHO, but I don't think it argues for "current" versus "upstream", as
> they both fix it (but Michael's matching-current hybrid would not, so I
> agree it is less appealing).

In the case of my proposed matching-current hybrid, the error message
for the failing push would make it pretty obvious what went wrong and
how to fix it; something like:

    $ git push
    The remote repository "git.example.com:myproject" does not yet
    contain a branch called "master".  If you would like to create one
    now, type

        git push origin master

    For other alternatives, please see gitworkflows(7).

This error message would appear *whenever* the matching-current hybrid
policy caused the push to fail.  Since this problem occurs only if (1)
the upstream repository is empty and (2) the user hasn't configured a
more liberal global push.default, and since it is blindingly obvious
what to do to fix the problem, it doesn't seem especially onerous.

(One could even create a special-case to allow such a push when the
upstream repository is empty, but I don't think the gain in convenience
is worth the loss of consistency.)

> So far a lot of the discussion has focused on "what is the most sensible
> default for the most number of people". But I wonder if a better
> question is "what is the default that is the least likely to do
> something dangerous and embarrassing". People who use git enough to say
> "wow, I don't like this default for my workflow" are probably at the
> point that they can configure push.default themselves.

I agree entirely.  And here is an algorithm for deciding what the
default should be:

1. Make a list of branch configurations that can be distinguished by
   git, which would be something like all combinations of

   * remote has a branch with the same name as the current branch?
     * no
     * yes, and remote branch could be fast-forwarded to local state
     * yes, but remote branch cannot be fast-forwarded to local state

   * local branch has known upstream branch on remote?
     * no
     * yes, and remote upstream branch could be fast-forwarded to
       the state of the current local branch
     * yes, but remote upstream branch cannot be fast-forwarded to
       the state of the current local branch

2. In each of these situations, decide what "git push" should do in
   each of the common workflows.

3. In the branching configurations for which all workflows agree about
   what "git push" should do, then that is what "git push" should do by
   default.  When they do not agree, then "git push" should do nothing,
   give an informative error message, and leave it to the user to
   decide.  If all workflows agree on a safe subset of what "git push"
   should do (for example, "matching" and "current" agree that the
   current branch should be pushed even though they disagree whether
   other branches should be pushed), then it might be OK to carry out
   the safe subset.

The most common workflows, along with the configuration settings that
are recommended for that workflow, should be given standard names and
documented in gitworkflows(7).  The warning message for a failed "git
push" invocations (especially if push.default is unset) should direct
the user to this manpage.


Isn't it obvious?: The fact that we cannot even agree among ourselves
what "git push" should do in all cases *proves* that we are trying to be
too ambitious with DWIM.  "git push" must therefore become more
deferential when the obvious thing to do is unclear, especially given
that mistakes (due to the very nature of "git push") often have
embarrassing and publicly visible effects.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

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

[Jeff King]

On Wed, Mar 14, 2012 at 09:59:04AM +0100, Michael Haggerty wrote:

> > Ending that confusion is one of the best reasons to switch the default,
> > IMHO, but I don't think it argues for "current" versus "upstream", as
> > they both fix it (but Michael's matching-current hybrid would not, so I
> > agree it is less appealing).
> 
> In the case of my proposed matching-current hybrid, the error message
> for the failing push would make it pretty obvious what went wrong and
> how to fix it; something like:
> 
>     $ git push
>     The remote repository "git.example.com:myproject" does not yet
>     contain a branch called "master".  If you would like to create one
>     now, type
> 
>         git push origin master
> 
>     For other alternatives, please see gitworkflows(7).
> 
> This error message would appear *whenever* the matching-current hybrid
> policy caused the push to fail.  Since this problem occurs only if (1)
> the upstream repository is empty and (2) the user hasn't configured a
> more liberal global push.default, and since it is blindingly obvious
> what to do to fix the problem, it doesn't seem especially onerous.

Thanks for the clarification. That does go a long way towards dealing
with the confusion. I think I'd be OK with that, though I am on the
fence about whether just pushing (i.e., "current") would be better or
worse.

> 3. In the branching configurations for which all workflows agree about
>    what "git push" should do, then that is what "git push" should do by
>    default.  When they do not agree, then "git push" should do nothing,
>    give an informative error message, and leave it to the user to
>    decide.
> [...]
> Isn't it obvious?: The fact that we cannot even agree among ourselves
> what "git push" should do in all cases *proves* that we are trying to be
> too ambitious with DWIM.  "git push" must therefore become more
> deferential when the obvious thing to do is unclear, especially given
> that mistakes (due to the very nature of "git push") often have
> embarrassing and publicly visible effects.

I find your approach interesting, but it doesn't deal with one problem:
user perception when git fails to do something out of the box. I am
worried that the rule above means that push will end up defaulting to
nothing. It is one thing to say "there are so many workflows, and they
do not agree, so we should be safe and do nothing"; that makes sense to
an advanced user who thinks about things like different workflows. But
to a brand-new git user who is running "push" in their first session, it
makes git seem very unfriendly.

And that's why I think either "current" or "current-if-matching" as you
describe is a sane default. I don't think it matches with what the
"upstream" people want, and so does not meet your criteria above as a
default behavior. But it does something sensible and not very dangerous
or embarrassing, and it means git will do something that is probably
useful out of the box for a new user.

-Peff

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

[Ævar Arnfjörð Bjarmason]

On Fri, Mar 9, 2012 at 09:31, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> More inexperienced users will often push right after committing, and at
> that time they're still very much in the "working-on-one-branch" state of
> mind.  "upstream" would be a safer default mode of operation for 'git push'
> for them even when they have their personal publishing repository (also in
> a shared public repository settings, "matching" is rarely the right
> default mode).

I very much like changing the default, thanks for working on this,
this'll make Git a lot more sensible by default.

</aol>

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

[Clemens Buchacher]

Hi,

On Fri, Mar 09, 2012 at 09:31:26AM +0100, Matthieu Moy wrote:
>
> In preparation for flipping the default to the "upstream" mode from the
> "matching" mode that is the upstream default, start warning users when they
> rely on unconfigured "git push" to default to the "matching" mode.

I haven't had time to follow the entire discussion, but I have been
thinking about this myself a little and I also find it hard to decide
between "current" and "upstream". So I just wanted to throw in another
option:

If neither default is the right thing to do, then we should not choose
either. Instead, by default make push act according to "current" or
"upstream" only if they would do the same thing anyways. In other words,
push the current branch only if it is also tracking a remote branch of
the same name.

If "current" and "upstream" disagree, git push errors out and asks the
user to use an explicit refspec or change push.default according to
their preferred workflow.

Clemens

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

[Matthieu Moy]

Clemens Buchacher <drizzd@aon.at> writes:

> If "current" and "upstream" disagree, git push errors out and asks the
> user to use an explicit refspec or change push.default according to
> their preferred workflow.

I actually like this idea. Or at least, much more than "current, but
only if the remote already exists". In most simple case, it will just
work, and it will error out with an explicit message in every case which
could have confused the user.

I'd count "upstream is not set" as "current and upstream agree on
'current'". IOW, use "current", but error out if there's a configured
upstream that is different.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Junio C Hamano]

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

> I'd count "upstream is not set" as "current and upstream agree on
> 'current'". IOW, use "current", but error out if there's a configured
> upstream that is different.

And if there is no configured upstream, should it error out, or should it
just push the current one to its own name?

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

[Matthieu Moy]

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

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> I'd count "upstream is not set" as "current and upstream agree on
>> 'current'". IOW, use "current", but error out if there's a configured
>> upstream that is different.
>
> And if there is no configured upstream, should it error out, or should it
> just push the current one to its own name?

I meant just push the current one to its own name.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Clemens Buchacher]

On Fri, Mar 16, 2012 at 01:42:36PM +0100, Matthieu Moy wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> >
> >> I'd count "upstream is not set" as "current and upstream agree on
> >> 'current'". IOW, use "current", but error out if there's a configured
> >> upstream that is different.
> >
> > And if there is no configured upstream, should it error out, or should it
> > just push the current one to its own name?
> 
> I meant just push the current one to its own name.

Altough in a somewhat rarer case, this has the same problem as
"current":

git checkout -b master origin/master
git checkout -b topic master
git push

If a branch called topic already exists on origin, push will now try to
update it with the local branch topic. But they do not have any clear
connection, except for the name.

Clemens

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

[Matthieu Moy]

Clemens Buchacher <drizzd@aon.at> writes:

> On Fri, Mar 16, 2012 at 01:42:36PM +0100, Matthieu Moy wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>> 
>> > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>> >
>> >> I'd count "upstream is not set" as "current and upstream agree on
>> >> 'current'". IOW, use "current", but error out if there's a configured
>> >> upstream that is different.
>> >
>> > And if there is no configured upstream, should it error out, or should it
>> > just push the current one to its own name?
>> 
>> I meant just push the current one to its own name.
>
> Altough in a somewhat rarer case, this has the same problem as
> "current":
>
> git checkout -b master origin/master
> git checkout -b topic master
> git push
>
> If a branch called topic already exists on origin, push will now try to
> update it with the local branch topic. But they do not have any clear
> connection, except for the name.

Yes, but the user can hardly expect anything else here. So, it may be a
(user) mistake, but it's not a surprise.

BTW, 'matching' also has this drawback, and I never saw anyone complain
about it (maybe I didn't listen enough though).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Andrew Myers]

I would like to register my vote to change the default behavior of git push
to either current (preferred) or upstream.  I'm the git admin on my team which
uses a shared repository with many branches.  The current default behavior
has caused confusion and problems for inexperienced users (or users who refuse
to self educate).  While the optimum solution would be users who learn the
system but this change would make (at least) my job easier.

Re: git push default behaviour?

[Junio C Hamano]

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

> Junio C Hamano <gitster@pobox.com> writes:
>
>> I just dug it up; start from here:
>>
>>     http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541
>
> That's an old discussion. A more recent one is here:
>
>   http://thread.gmane.org/gmane.comp.version-control.git/166743
>
> (interleaved with a discussion about tag namespace, but the end of the
> message is about push.default)

I'd say that it only shows that everybody for some strange reason
forgot to learn from history, including me, in that more recent
thread. Luckily, Jeff noticed eerily familiarity this time around.

> (i.e. "Care to roll an appliable patch?", which I guess everyone has
> been too lazy to do)

I doubt that it would have solved any issue we suffered in the 1.6.3
to 1.6.4 timeframe if somebody gave a concluding patch after that
message in the more recent discussion.  Specifically, it would not
have solved anything that these raised:

  http://thread.gmane.org/gmane.comp.version-control.git/118866/focus=119142
  http://thread.gmane.org/gmane.comp.version-control.git/118866/focus=119148

Resurrecting the old patch that was reverted is the easiest part.

It is much more important to spread the word to the people who will
be hurt by the default change well before it actually happens, and
to get them engaged in the discussion, along with those who would
benefit from such a change. That needs to happen before any patch
that reverts a revert.

Even in the kernel community, I suspect that most people do not
follow this mailing list anymore and simply trust that we won't make
changes that affect them negatively. People will complain only after
a change hits them, and tell us "We didn't know that you will be
making this stupid change." And having this thread here does not
count as "spreading the word".

I can send a message saying "There is a proposal to change the
default behaviour of 'git push' on the Git mailing list, and you may
be negatively affected if you do not see anything in the output from
'git config push.default' when such a change happens. On the other
hand, you may want to see the default behaviour to change. In either
case, please join the discussion to give us more data point and help
us decide the future of Git." to the kernel list. Anybody could, for
that matter.

One thing I refuse to do is to fight this battle alone for "let's
change the default" folks, especially when I am not convinced that
it is a good change to begin with. It is "let's change the default"
folks' responsibility to help the legwork.

Re: git push default behaviour?

[Matthieu Moy]

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

> I can send a message saying "[...]" to the kernel list. Anybody could,
> for that matter.

That would have been something sensible to do a few years ago, but
today, I think we are far, far beyond the point where Git was a tool
meant primarily for kernel hackers. I don't think considering the kernel
community as more important than other users will help making Git easy
to use for bare mortals.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: git push default behaviour?

[Junio C Hamano]

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

> Junio C Hamano <gitster@pobox.com> writes:
>
>> I can send a message saying "[...]" to the kernel list. Anybody could,
>> for that matter.
>
> That would have been something sensible to do a few years ago, but
> today, I think we are far, far beyond the point where Git was a tool
> meant primarily for kernel hackers. I don't think considering the kernel
> community as more important than other users will help making Git easy
> to use for bare mortals.

That is *EXACTLY* the issue.

The kernel is one example community that *I* can cover, and if we
were going to continue discussion, I'm willing to help doing so
because your change will *NEVER* work unless we spread the word to
*all* the relevant communities whose members may be negatively
affected.  That is what I am saying in the part you quoted.

But I obviously *WILL* *NOT* be able to do so for *all* communities
whose members may be negatively affected.

Let me repeat the part you omitted from your quote:

  One thing I refuse to do is to fight this battle alone for "let's
  change the default" folks, especially when I am not convinced that
  it is a good change to begin with. It is "let's change the
  default" folks' responsibility to help the legwork.

Now, you have realized that the kernel community is only one of the
places where "let's change the default" folks need to spread the
word and solicit their involvement, are you willing to do your part?

People will complain only after a change hits them, and tell us "We
didn't know that you will be making this stupid change." And having
this thread here does not count as "spreading the word".

Re: git push default behaviour?

[Junio C Hamano]

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

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> I can send a message saying "[...]" to the kernel list. Anybody could,
>>> for that matter.
>> ...
> But I obviously *WILL* *NOT* be able to do so for *all* communities
> whose members may be negatively affected.

Oh, let's avoid any misunderstanding before it happens.

I am not saying that we need to get involvement only from people who
might like the current default.  If you read the "[...]" part you
omitted from your quote again, you will notice that the RFH message was
carefully crafted to take a neutral position, and solicit input from
both sides, and that was very much on purpose.

I was hoping that the reaction to my reply would be that "let's
change the default" folks to help polishing the wording of the RFH
message further, and post the final one to help spreading the word,
both in the forums of projects that will be helped by the change,
and of those that will be irritated by the change.

I didn't mean to suggest anybody to play politics by asking input
from only one side to skew the discussion, even though it is not
like we will decide by majority vote anyway.  Deciding in favor of
whichever position you happen to like is not the goal. Avoiding user
surprises and unnecessary harm is.

And that is why the lesson the older thread from 1.6.3-1.6.4 era
teaches us is important.

Re: git push default behaviour?

[Jakub Narebski]

[I am sorry if you have received duplicates]

Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> I just dug it up; start from here:
>>>
>>>     http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541
>>
>> That's an old discussion. A more recent one is here:
>>
>>   http://thread.gmane.org/gmane.comp.version-control.git/166743
>>
>> (interleaved with a discussion about tag namespace, but the end of the
>> message is about push.default)
> 
> I'd say that it only shows that everybody for some strange reason
> forgot to learn from history, including me, in that more recent
> thread. Luckily, Jeff noticed eerily familiarity this time around.

Nb. if I remember it correctly one of problems seen with transition to
new default was that there were no command-line equivalent to
'push.default = matching'... but now we have ":" and "+:" magic
refspec.

>> (i.e. "Care to roll an appliable patch?", which I guess everyone has
>> been too lazy to do)
[...]

> Resurrecting the old patch that was reverted is the easiest part.
> 
> It is much more important to spread the word to the people who will
> be hurt by the default change well before it actually happens, and
> to get them engaged in the discussion, along with those who would
> benefit from such a change. That needs to happen before any patch
> that reverts a revert.
> 
> Even in the kernel community, I suspect that most people do not
> follow this mailing list anymore and simply trust that we won't make
> changes that affect them negatively. People will complain only after
> a change hits them, and tell us "We didn't know that you will be
> making this stupid change." And having this thread here does not
> count as "spreading the word".
> 
> I can send a message saying "There is a proposal to change the
> default behaviour of 'git push' on the Git mailing list, and you may
> be negatively affected if you do not see anything in the output from
> 'git config push.default' when such a change happens. On the other
> hand, you may want to see the default behaviour to change. In either
> case, please join the discussion to give us more data point and help
> us decide the future of Git." to the kernel list. Anybody could, for
> that matter.

There are other places where we can send such message beside git
mailing list and LKML: There is Junio's "Git Blame" blog, there is Git
page on Google+; we can ask for such annoncement to be posted also
on GitHub Blog...

Spread the word...
-- 
Jakub Narebski

Re: git push default behaviour?

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> There are other places where we can send such message beside git
> mailing list and LKML: There is Junio's "Git Blame" blog, there is Git
> page on Google+; we can ask for such annoncement to be posted also
> on GitHub Blog...

And you are saying who will do all of the above?

Re: git push default behaviour?

[Jakub Narebski]

On Fri, 9 Mar 2012, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > There are other places where we can send such message beside git
> > mailing list and LKML: There is Junio's "Git Blame" blog, there is Git
> > page on Google+; we can ask for such annoncement to be posted also
> > on GitHub Blog...
> 
> And you are saying who will do all of the above?

I would certainly not be announcing this message on yours "Git Blame"
blog, and you usually accompany new post on blog with announcement on G+
(I don't remember if via "Git" page or via your own personal Google+
page).

I can go round git hosting sites asking to post announcements, similarly
to what I do during annual "Git User's Survey".
-- 
Jakub Narebski
Poland

Re: git push default behaviour?

[Matthieu Moy]

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

> I can send a message saying "There is a proposal to change the
> default behaviour of 'git push' on the Git mailing list, and you may
> be negatively affected if you do not see anything in the output from
> 'git config push.default' when such a change happens. On the other
> hand, you may want to see the default behaviour to change. In either
> case, please join the discussion to give us more data point and help
> us decide the future of Git." to the kernel list. Anybody could, for
> that matter.

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:

---------- 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
'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.

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
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@vger.kernel.org
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

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: git push default behaviour?

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> 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@vger.kernel.org
> 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@vger.kernel.org
        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.

Re: git push default behaviour?

[Matthieu Moy]

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

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> 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.

I'm taking them all. Here's the result:

---------- 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 may be confusing if not dangerous when using
a shared repository. The proposal is to change the default to
'upstream', i.e. push only the current branch, and push it to the branch
'git pull' would pull from. Another candidate is 'current'; this pushes
only the current branch to the remote 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 default that pushes all your matching branches. On the other
hand, you may want to see the

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.

What has been discussed so far can be seen in this thread:
http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694
Previous relevant discussions include:
http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541
http://thread.gmane.org/gmane.comp.version-control.git/166743

To join the discussion, send your messages to: git@vger.kernel.org
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.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: git push default behaviour?

[Junio C Hamano]

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

>> Sounds OK from a cursory read, except for a few minor details.
>>
>> Thanks.  Nitpicks follow.
>
> I'm taking them all. Here's the result:

I'd hold onto this version for a few days before I paste it in my
blog or send it to k-list in order to give others a chance to
improve the text further, but this looks good (obviously) to me.

Thanks for getting the ball rolling.

Re: git push default behaviour?

[Junio C Hamano]

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

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>>> Sounds OK from a cursory read, except for a few minor details.
>>>
>>> Thanks.  Nitpicks follow.
>>
>> I'm taking them all. Here's the result:
>
> I'd hold onto this version for a few days before I paste it in my
> blog or send it to k-list in order to give others a chance to
> improve the text further, but this looks good (obviously) to me.
>
> Thanks for getting the ball rolling.

So a few days passed, and I do not think we heard anything from anybody.
I am not sure if that means everybody is happy with the wording of the
draft, or simply nobody cares, but unless I hear from anybody further on
this topic, I'll start my part of distributing this to where I feel are
appropriate tonight [*1*].

People who want to see the default changed, please help the message to
reach corners where mine wouldn't reach.  For that matter, people who 
want to see that the default remains the same, please do the same.

Thanks.

[Footnote]

*1* The places I have in mind are:
 - This list (which may be pointless)
 - linux-kernel@vger.kernel.org
 - http://git-blame.blogspot.com/
 - http://gplus.to/gitster
 - http://gplus.to/git
 - Google internal (there are a few users at $DAYJOB)

Re: git push default behaviour?

[Eric Hanchrow]

In response to
http://git-blame.blogspot.com/2012/03/please-discuss-what-git-push-should-do.html:

I think either 'current' or 'upstream' is a better default than
'matching', since it's less likely to surprise newbies.  However, I
cannot decide which of 'current' or 'upstream' is the best choice.  It
might be worthwhile to have 'git push' warn when someone has
push.default = current or push.default = upstream, AND when @{u} has a
different name than the local branch -- in other words, emit a warning
when 'upstream'' and 'current' refer to different branches.  The
warning itself should be turn-off-able, since it would get pretty old
pretty quickly.

Re: git push default behaviour?

[Dmitry Potapov]

On Thu, Mar 8, 2012 at 7:00 PM, Marc Branchaud <marcnarc@xiplink.com> wrote:
>
> Perhaps --force should be changed to require an explicit ref if push.default
> = matching (and the code finds that it needs to use push.default's value)?

No, it will workflow for some people. In general, --force should not be
used, but when it is used, it is used for a reason. If you need another
behavior like forcing only the current branch then you probably should add
--force-current or something like that, but not to break what works now.

Dmitry

Re: git push default behaviour?

[Jakub Narebski]

Jeremy Morton <jeremy@configit.com> writes:
> On Thu, Mar 8, 2012 at 10:28 AM, Carlos Martín Nieto <cmn@elego.de> wrote:
> > On Thu, 2012-03-08 at 10:13 +0000, Jeremy Morton wrote:

> >> Right, so I guess I'm saying that the default value for push.default
> >> should be upstream instead of matching...
> >
> > Any default is going to leave some people unhappy. If upstream is the
> > right thing for you, then that's what you should use. Most questions I
> > see about push not doing what the users expect would actually benefit
> > from 'current'. 'matching' is a fairly safe default, as it won't try to
> > push private branches or changes in private branches that track
> > something upstream.
>
> But 'push --force' WILL try to push your (probably outdated) master
> upstream, killing any changes there made since you last updated.  That
> alone is so dangerous it seems like reason enough to avoid it by
> default.

You can always configure server to refuse forced pushes.
-- 
Jakub Narebski

Re: git push default behaviour?

[Jeremy Morton]

On Thu, Mar 8, 2012 at 11:33 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> You can always configure server to refuse forced pushes.

We're using github, and as far as I'm aware, there's no way to
configure github to do that.

Best regards,
Jeremy Morton (Jez)

Re: git push default behaviour?

[Jakub Narebski]

On Thu, 8 Mar 2012, Jeremy Morton wrote:
> On Thu, Mar 8, 2012 at 11:33 AM, Jakub Narebski <jnareb@gmail.com> wrote:

> > You can always configure server to refuse forced pushes.
> 
> We're using github, and as far as I'm aware, there's no way to
> configure github to do that.

It would be nice if GitHub supported setting receive.denyNonFastForward
and receive.denyDeletes (the receive.*current* do not matter for GitHub).
Though I am not sure if it would not require changes to the custom Git
implementation they use...

-- 
Jakub Narebski
Poland

Re: git push default behaviour?

[Jeremy Morton]

Would that deny non fast-forwards for all branches, though, or just
selected ones?  We'd like to just to it for 2 of our branches.  We'd
also like to explitly ALLOW fast-forwards to master, when we want to
merge in from develop to master.

A better description of what we want is to prevent 'rewriting of
history' for some of our branches.

Best regards,
Jeremy Morton (Jez)

On Tue, Mar 13, 2012 at 4:27 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, 8 Mar 2012, Jeremy Morton wrote:
>> On Thu, Mar 8, 2012 at 11:33 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>
>> > You can always configure server to refuse forced pushes.
>>
>> We're using github, and as far as I'm aware, there's no way to
>> configure github to do that.
>
> It would be nice if GitHub supported setting receive.denyNonFastForward
> and receive.denyDeletes (the receive.*current* do not matter for GitHub).
> Though I am not sure if it would not require changes to the custom Git
> implementation they use...
>
> --
> Jakub Narebski
> Poland

Re: git push default behaviour?

[Jakub Narebski]

Could you please do not top-post?  TIA.

Jeremy Morton wrote:
> On Tue, Mar 13, 2012 at 4:27 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> > On Thu, 8 Mar 2012, Jeremy Morton wrote:
> >> On Thu, Mar 8, 2012 at 11:33 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> >
> >> > You can always configure server to refuse forced pushes.
> >>
> >> We're using github, and as far as I'm aware, there's no way to
> >> configure github to do that.
> >
> > It would be nice if GitHub supported setting receive.denyNonFastForward
> > and receive.denyDeletes (the receive.*current* do not matter for GitHub).
> > Though I am not sure if it would not require changes to the custom Git
> > implementation they use...
>
> Would that deny non fast-forwards for all branches, though, or just
> selected ones?  We'd like to just to it for 2 of our branches.  We'd
> also like to explitly ALLOW fast-forwards to master, when we want to
> merge in from develop to master.

No, receive.denyNonFastForward is for all branches only.  If you want
per-branch access control, try gitolite... again not available on GitHub
(unless GitHub allows custom hooks).
 
> A better description of what we want is to prevent 'rewriting of
> history' for some of our branches.

C.f. http://thread.gmane.org/gmane.comp.version-control.git/189895
     http://thread.gmane.org/gmane.comp.version-control.git/189946/focus=191119

Though that is only a proposal and a prototype.
-- 
Jakub Narebski
Poland

Re: git push default behaviour?

[Matthieu Moy]

Carlos Martín Nieto <cmn@elego.de> writes:

> On Thu, 2012-03-08 at 10:13 +0000, Jeremy Morton wrote:
>> Right, so I guess I'm saying that the default value for push.default
>> should be upstream instead of matching...
>
> Any default is going to leave some people unhappy. If upstream is the
> right thing for you, then that's what you should use. Most questions I
> see about push not doing what the users expect would actually benefit
> from 'current'. 'matching' is a fairly safe default, as it won't try to
> push private branches or changes in private branches that track
> something upstream.

There were some discussions about changing the default, and I thought
people agreed that 'upstream' was a better default value for
push.default:

  http://permalink.gmane.org/gmane.comp.version-control.git/167149

it needs to be done with a sane migration path, however, and I guess no
one stepped in to start the process (but I may have missed some further
discussions).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: git push default behaviour?

[demerphq]

On 8 March 2012 12:54, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> Carlos Martín Nieto <cmn@elego.de> writes:
>
>> On Thu, 2012-03-08 at 10:13 +0000, Jeremy Morton wrote:
>>> Right, so I guess I'm saying that the default value for push.default
>>> should be upstream instead of matching...
>>
>> Any default is going to leave some people unhappy. If upstream is the
>> right thing for you, then that's what you should use. Most questions I
>> see about push not doing what the users expect would actually benefit
>> from 'current'. 'matching' is a fairly safe default, as it won't try to
>> push private branches or changes in private branches that track
>> something upstream.
>
> There were some discussions about changing the default, and I thought
> people agreed that 'upstream' was a better default value for
> push.default:
>
>  http://permalink.gmane.org/gmane.comp.version-control.git/167149
>
> it needs to be done with a sane migration path, however, and I guess no
> one stepped in to start the process (but I may have missed some further
> discussions).

From the point of view of new users the current default is sub-optimal
and confusing. I actually find the current default an odd choice, as I
personally have *never* wanted to push all the branches at once, nor
have I ever seen a colleague want to do that.

cheers,
Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: git push default behaviour?

[Sebastien Douche]

On Thu, Mar 8, 2012 at 11:01, Jeremy Morton <jeremy@configit.com> wrote:
> Hi everyone,

Hi Jeremy (sorry to be late, back from holiday)

> I've noticed that the default behaviour of 'git push' is to push to
> *all* branches that have a remote branch set up.  In order to push
> just to one branch, you must specify 'git push repo branchname'.
>
> This seems rather unintuative to me

I made many Git presentation and managed a lot of training[1] and the
first thing I explain on the configuration is :

1. set your name and email
2. change the default push option[2]

Moreover, most people I see don't understand the default behaviour:
it's a frequently ask question by beginner.


[1] For git French : http://gitfr.net/blog
[2] I recommend tracking


-- 
Sebastien Douche <sdouche@gmail.com>
Twitter: @sdouche / G+: +sdouche

Re: git push default behaviour?

[Jeremy Morton]

On Sat, Mar 17, 2012 at 9:36 AM, Sebastien Douche <sdouche@gmail.com> wrote:
> On Thu, Mar 8, 2012 at 11:01, Jeremy Morton <jeremy@configit.com> wrote:
>> Hi everyone,
>
> Hi Jeremy (sorry to be late, back from holiday)
>
>> I've noticed that the default behaviour of 'git push' is to push to
>> *all* branches that have a remote branch set up.  In order to push
>> just to one branch, you must specify 'git push repo branchname'.
>>
>> This seems rather unintuative to me
>
> I made many Git presentation and managed a lot of training[1] and the
> first thing I explain on the configuration is :
>
> 1. set your name and email
> 2. change the default push option[2]

So, that would seem to be a rather strong indication that the default
push option is a bad one.  :-)

Best regards,
Jeremy Morton (Jez)

Re: git push default behaviour?

[Sebastien Douche]

On Sat, Mar 17, 2012 at 10:38, Jeremy Morton <jeremy@configit.com> wrote:
>> I made many Git presentation and managed a lot of training[1] and the
>> first thing I explain on the configuration is :
>>
>> 1. set your name and email
>> 2. change the default push option[2]
>
> So, that would seem to be a rather strong indication that the default
> push option is a bad one.  :-)

True. Never understood why matching is the default value :). Btw,
thank you for the discussion, I forgot to do that :(.

-- 
Sebastien Douche <sdouche@gmail.com>
Twitter: @sdouche / G+: +sdouche

Re: git push default behaviour?

[Pavel Pospíšil]

Hi,
I consider myself a little bit experienced git newbie. I use git 1.7.5.4
I use git for 9 month in this way:
1. copy a released version from a centralized versioning control
system (this VCS does not have any git interface) to my local git repo
2. do work in git in my-branch
3. copy current work-in-progress reconfiguration from VCS to git
4. rebase my-branch onto current work-in-progress
5. copy my work to VCS
Therefore, no usage of push/pull.

I created my first public repo in which I share the released versions
of 4 development streams in 4 independent branches with my colleagues.
My usual workflow is:
1. copy a released version from VCS to my local git repo
2. git add .
3. git commit
4. git tag <release-name>
5. git push <my-public-repo> HEAD
6. git push <release-name>
I expected that push is meant (even after reading man git-push) to be
used in this way:
1. do some work in my-branch
2. merge it to master
3. git push
and this will push only the changes in the master branch I am
currently switched on.

Now, I realized that git push default is not "upstream" (the behaviour
I expected) but is "matching" that brings more automation (I assume
git community wants to achieve as much automation as possible).

I agree with Sebastien that current git push.default is too much
automation for newbies that "upstream" would be a better default for
newbies.

I came across an inconvenience in man git-push. There is no
Configuration section that will inform about the push.default
configuration parameter and educate the reading about various push
behaviours. I know that there is man git-config but it's too long and
it's too tedious to read all git configuration options.

Maybe, adding the Configuration section to man git-push will help.

Best regards,
Pavel Pospisil


On Sat, Mar 17, 2012 at 10:51 AM, Sebastien Douche <sdouche@gmail.com> wrote:
>
> On Sat, Mar 17, 2012 at 10:38, Jeremy Morton <jeremy@configit.com> wrote:
> >> I made many Git presentation and managed a lot of training[1] and the
> >> first thing I explain on the configuration is :
> >>
> >> 1. set your name and email
> >> 2. change the default push option[2]
> >
> > So, that would seem to be a rather strong indication that the default
> > push option is a bad one.  :-)
>
> True. Never understood why matching is the default value :). Btw,
> thank you for the discussion, I forgot to do that :(.
>
> --
> Sebastien Douche <sdouche@gmail.com>
> Twitter: @sdouche / G+: +sdouche
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html