Pierre Habouzit <madcoder@debian.org> writes:

quoted text
> The real question is "what does users intend when they `git push`". In
> a git/kernel/... like model, you don't think the same than in a
> svn/cvs-like model. I mean, Junio or Linus likely don't push a lot to
> their public repository. It happens probably a couple of time per day.
> While I'm at work, it happens up way more frequentely, and I then want
> to lazily type `git push` and not `git push origin <somebranch>`. it's
> too long.
>
>   I'm not sure what we can do about it, but I'm pretty sure it bites a
> lot of people out there. For now I use this alias in my .gitconfig:
>
>   p=!git-push origin `git-symbolic-ref HEAD`
>
> but still, it feels really wrong to me. Not to mention that git-push(1)
> says that it has a --all option that in fact is the current default
> behavior, hence sounds pretty useless.

The default is not --all but "matching branches", iow, what you
have never published yet never goes out.

Having said that, I would agree that in some workflows "I am on
this branch and I would want to push only this branch" would be
the norm, and the norm even be "and this branch 'foo' is called
identically as 'foo' at the remote site as well".

Don't worry about me when discussing to change the default.
Myself, I also often push only one or two branches.  A typical
workflow for me while working on git.git is to prepare 'maint'
(if there are any changes) and 'master', push them (without
pushing 'next' and 'pu') to a private "build it to make sure"
repository I have at a k.org machine which runs RH, make sure
they are Ok, and then continue working on integrating 'next' and
'pu'.  At the end of the day, I push out all four integration
branches to a separate "publish" area, but even this one, I rely
on the explicit configuration (remote.<name>.push) to push out
only the integration branches and not other branches.

We would also want to have --mirror option that acts like --all
but removes the refs from the remote that do not exist anymore,
so we will be talking about updating "git push" in the near
future anyway.

So what's the desired semantics?

The current semantics is:

   "git push" says "you do not say to which repository?" and
   consults "branch.<current>.remote" but defaults to 'origin'
   if unconfigured.  

   "git push <name>" (or using the <name> determined as above)
   says "you do not say which branches?" and consults
   "remote.<name>.push" to find branches to push out, but
   defaults to 'matching branches' if unconfigured.

What you would want to change is the fallback behaviour for
unconfigured "remote.<name>.push".  I think it is sensible to
have an option to make it push only the current branch.  I am
not sure if it is sensible to make that the default (and
introduce --matching option to get the current behaviour) at
this point in 1.5.X series, but from the general usability point
of view, I would not object to demote 'matching' to optional and
make 'current only' the default in 1.6.X or later.

Thoughts?
-
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