patch, 7 partsgit push: Remove warning for "git push" default change

Usability improvements:

"-" is now an alias for the current remote (the remote of the current branch or "origin" as a fallback). This works both for push, fetch, pull, remote (and possibly some others), creating a lot of nice shortcuts I think: git remote prune - : prune the current remote git push - HEAD : push the current branch to a branch of the same name git fetch - next : fetch the next branch from the current remote

git push has learned two new command line options --matching and --current, which override any configuration. 'matching' pushes all branches that already exist at the remote, while 'current' pushes the current branch to whatever it is tracking

I chose this behaviour for 'current', since it is the one that I find most useful, and there seems to be no good way of expressing it from the command line. Pushing a branch to an identically named branch on a remote can now easily be done by "git push - HEAD".

Also added a new configuration option push.default, which can have values "nothing", "matching" and "current". This variable will only be used if you have not specificed any refspecs at all, no command line options imply any refspecs, and the current branch has no push configuration.

This is implemented in 1-3

git push default change:

git push will by default push "nothing" instead of "matching".

This is implemented in 4-7. 4-5 are for immediate consumption, 6 is for next major release (or later), and 7 is even later.

4 Adds a warning if you have not configured push.default
5 Changes the wording to say that the default will change. 4 and 5 can
  be applied immediately.
6 changes the deault to "nothing", but keeps the warning.
7 removes the warning entirely

Finn Arne Gangstad (7):
      remote: Make "-" an alias for the current remote
      New config option push.default
      git push: New options --matching and --current
      git push: Display warning on unconfigured default push
      git push: Document that "nothing" is the future push default
      git push: Change default for "git push" to nothing.
      git push: Remove warning for "git push" default change

 Documentation/RelNotes-1.6.3.txt |    7 +++
 Documentation/config.txt         |   18 ++++++++
 Documentation/git-push.txt       |   14 +++++--
 builtin-push.c                   |   84 +++++++++++++++++++++++++++++--------
 cache.h                          |    7 +++
 config.c                         |   23 ++++++++++
 environment.c                    |    1 +
 remote.c                         |    2 +-
 transport.h                      |    9 ++++
 9 files changed, 142 insertions(+), 23 deletions(-)

- Finn Arne

This creates a handy alias "-" for the remote of the current branch (or origin if no such remote exists), which can be used in both push, pull, fetch and remote to make many tasks easier. E.g.: git push - HEAD : push the current branch git remote prune - : prune the current remote git fetch - next : get the next branch from the current remote

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
 remote.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

This option takes effect when no refspec is given explicitly or implicitly
by any of the command line arguments to push, and no refspec is configured
for the current remote. The possible values are:
* nothing - do not push anything
* current - push the current branch to whatever it is tracking
* matching - push all branches that already exist remotely (same name)

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
 Documentation/config.txt |   18 ++++++++++++++++++
 cache.h                  |    8 ++++++++
 config.c                 |   23 +++++++++++++++++++++++
 environment.c            |    1 +
 4 files changed, 50 insertions(+), 0 deletions(-)

--matching: Push all branches that already exist with the same name in the remote --current: Push the current branch to whatever it is tracking

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
 Documentation/git-push.txt |   10 +++++-
 builtin-push.c             |   87 +++++++++++++++++++++++++++++++++++---------
 transport.h                |    9 +++++
 3 files changed, 87 insertions(+), 19 deletions(-)

On Mon, 9 Mar 2009, Finn Arne Gangstad wrote:

It's kind of odd that you define these flags as TRANSPORT_PUSH_*, but implement them before entering transport_push(). I'm not sure which is right, but the combination is odd. I think just taking care of it in builtin-push with flags or options defined there is probably the best thing, currently.

	-Daniel
*This .sig left intentionally blank*

On Mon, Mar 09, 2009 at 07:49:47PM -0400, Daniel Barkalow wrote:

True, this was not very beautiful. I will make something better.

- Finn Arne

As a preparation for a possible future "git push" default behaviour change, display a prominent warning for operations that may change behaviour in the future. The warning explains for the user how to configure this permanently so the warning will not be seen again after proper configuration.

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
 builtin-push.c |   23 +++++++++++++++++++++++
 1 files changed, 23 insertions(+), 0 deletions(-)

On Mon, Mar 9, 2009 at 6:35 PM, Finn Arne Gangstad <finnag@pvv.org> wrote:

s/anythig/anything/

j.

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
 Documentation/RelNotes-1.6.3.txt |    7 +++++++
 builtin-push.c                   |    4 ++--
 2 files changed, 9 insertions(+), 2 deletions(-)

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
 Documentation/config.txt   |    4 ++--
 Documentation/git-push.txt |    4 +---
 builtin-push.c             |    7 ++++---
 3 files changed, 7 insertions(+), 8 deletions(-)

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
 Documentation/config.txt |    4 ++--
 builtin-push.c           |   27 ---------------------------
 cache.h                  |    1 -
 environment.c            |    2 +-
 4 files changed, 3 insertions(+), 31 deletions(-)

Hi,

On Mon, 9 Mar 2009, Finn Arne Gangstad wrote:

Hasn't this been shot down already? I do not want that change. I think it is harmful.

At least without a proper way to prepare existing users for the end of the world.

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I haven't actually read the patch, but my reading of the cover lette ris that the four-patch sequence 4-to-7 is (meant to be, at least) structured that way.

On Tue, Mar 10, 2009 at 12:35:12AM +0100, Johannes Schindelin wrote:

That is pretty much what patches 4 and 5 are about - add nice warnings, but do not change behavior. 6 introduces the changed default.

- Finn Arne

Hi,

On Tue, 10 Mar 2009, Finn Arne Gangstad wrote:

Ah, so you meant that 1-5 should be committed right away, and 6 in one year?

Ciao, Dscho

On Tue, Mar 10, 2009 at 12:01:00PM +0100, Johannes Schindelin wrote:

Yes, that was the intention.

- Finn Arne

Finn Arne Gangstad <finnag@pvv.org> writes:

I think the last four are more or less sane, but I am not sure about the first three, which makes it very unfortunate that the former depends on the latter.

Some design issues and questions regarding the first three; not all of them are objections:

 * Do we use a short-hand for "the default thing" anywhere else in the
   current UI (not just "git push" but in the "git" command set)?

   - If the answer to the above question is "yes", does it use '-' as the
     short-hand too?  In other words, is this new short-hand consistent
     with it, or is it introducing "git-push uses '-' as the short-hand
     for the default, while git-frotz uses something else" confusion?

   - Even if the answer to the above question is "no", are there other
     commands that we currently do not allow a quick shorthand to mean
     "the default thing", but would benefit from having one?  If so, how
     good does it look to use '-' as such a short-hand?

     In other words, is it safe to establish a precedent to use '-' to
     denote "the default thing"?  Would we later regret, saying that
     "'git-frotz command would benefit from a short-hand notation for 'the
     default thing', but - is already taken -- it means send the output to
     the stdout"?

   - Do we use a short-hand '-' to mean something entirely different in
     the UI, making this new use of '-' to mean the default confusing?

     I think '-' for checkout means "the previous one", which already
     answers this question somewhat.

 * What's the point of having --matching option, when you can already say
   ':', i.e.

	$ git push origin :

 * What's the point of having --current option, when you can already say
   HEAD, i.e.

	$ git push origin HEAD

 * Is push.default still necessary if we had "remote.*.push" (where '*' is
   literally an "asterisk") that is used as a fall-back default when there
   is no "remote.<name>.push" for the remote we are about to push to?

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

I need " for these other commands" before the question mark at the end of this sentence.

I need ", or something like that" before the question mark at the end of this sentence.

I am wondering if we can handle this by DWIMming the command line arguments better. For example, in all of these:

	$ git push HEAD
        $ git push :
        $ git push master

when "HEAD", ":", or "master" can only be refspec, we know that the user said "I do not bother saying which repository to --- you know what I mean." It would be natural to DWIM it to "the default remote" without even having to use your '-' notation.

On Mon, Mar 09, 2009 at 05:07:08PM -0700, Junio C Hamano wrote:

No problem splitting them up, there is just a single function that is shared between 1-3 and 4-7 really.

[...]

If you have the name of your remote easily available, --matching is identical to "git push remote :". As I believe I found out, getting the name of the current remote is a bit more tedious than it should be, which is why I also suggested being able to use "-" as the current remote.

If a way to specify the default remote is possible, --matching would not be necessary, but would probably be more obvious to the reader than "git push - :" or whatever we can agree on.

It does something very different. Maybe --tracking would be a better name. --current does basically this:

branch=`git-symbolic-ref HEAD` branch=${branch#refs/heads/} remote=$(git config branch.$branch.remote)

for remotebranch in $(git config branch.$branch.merge); do
	git push $remote $branch:$remotebranch
done

This is the shortest shell script sequence I could find to mimic the behaviour, maybe I have missed something very obvious. All error handling is removed for clarity.

The goal here is to be able to:

git checkout -b junios-next origin/next git push --current <=> git push origin junios-next:next

git push origin HEAD would do git push origin junios-next:junios-next, which was not the intention.

It seems that there is an assumption that branch names are identical in different repositories, we find that that is not the case at all, people choose local names that make sense to themselves. Or, from another viewpoint, even if branches have the same name in two repositories, they are not necessarily (strongly) related!

"A tracks B" can be a much stronger relation than "A has the same name as B".

The main reason for push.default is to be able to change the default behaviour for git push to push nothing in a staged manner, and still let people who are used to and fond of the old behavior continue as before.

You are thinking of something like this in .gitconfig?
[remote "*"]
	push = __something__

Previously you indicated that there is no way to specify the current matching rule in a remote push line I think?

- Finn Arne

On Tue, Mar 10, 2009 at 6:04 AM, Finn Arne Gangstad <finnag@pvv.org> wrote:

No, you can. "push = :" works fine.

However, there's no way to specify "push = nothing" currently.

FWIW, I don't care for using remote.*.push for this use case. I think push.default is clearer here.

j.

Finn Arne Gangstad <finnag@pvv.org> writes:

Ok, now that sort of makes sense, and is very different from people would expect from --current, which I think most people would associate with HEAD. "tracking" or "track back" would be a better name.

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

I think this proposal has deeper problems than just that.

There can be two reasons you may want to give the branch a name other than 'next':

1. Because you also have dschos-next that tracks remotes/dscho/next; or

2. Because you also have junios-next2 that also tracks remotes/origin/next.

The first case indicates that the project is using a workflow where each developer has his own publishing repository [1], and it is very unlikely that Finn Arne has push access to either your or Johannes'es public repositories.

The second case of tracking a single branch with more than one is unnecessarily confusing. If you are on junios-next and you push (and we assume that you are Junio and have push access to the remote repository), after such a push you need to update junios-next2 somehow, either by rebasing or by merging. The reason junios-next2 branch needs updating is because it has changes unrelated to what you pushed out from your junios-next branch to the outside world as 'next'.

In such a case, wouldn't it be much easier to understand and manage if you had a single 'next' branch that has changes ready to be shown to the remote 'next', and make other topic branches fork from and track your local 'next' instead?

Your changes based on the public 'next' that everybody else sees need to get first integrated and tested in your local repository before getting pushed out to the remote 'next' branch in any case.

You certainly could switch between junios-next and junios-next2 branches that both track the public 'next' branch, and make sure you will integrate everything you need to send to the public repository no matter what branch you are currently working on. Unless you do so, 'git push' will refuse to accept an update that isn't a fast-forward anyway, so it certainly possible to work with more than one local branches that track a single remote branch.

But in order to do this correctly, you need to be aware what each branch is meant to contain, and for which public branch you are developing your changes on it. I think that way of working leads to the confusion and perceived need for the "--current" option: "I don't know which remote branch the changes I made on the current branch should be pushed to, and --current option remembers it for me, so I don't have to". That new option may be solving "where to push to" part but I'm afraid the option not just leaves "I still need to know for which public branch I am supposed to make changes while on this branch" unsolved, but by making people rely on the option I think it makes the latter problem much worse.

Dedicating your local 'next' for the integration purpose to prepare what you push to your public 'next' is much easier to understand and explain to new people. Once a topic that is meant to be published on your 'next' becomes ready, you merge the branch locally to your own 'next', and you have a chance to review that you didn't accidentally included changes inappropriate for 'next' when you create the merge. You push the result out after you are happy.

And I think the above discussion holds true if the public 'next' isn't your 'next', but a branch shared with others in a central repository.

I don't understand how the new "--current" makes "sort-of" sense. It looks like it is making the command more complex and the only thing it does is to encourage a confused workflow.

[1] Your http://gitster.livejournal.com/30645.html showed different ways to collaborate very nicely. I think this is the third approach in your article.

On Thu, Mar 12, 2009 at 12:01:09PM +0900, Nanako Shiraishi wrote:

[...]

No, think more of different repositories with different function, such as "my-public", "my-group", "beta", "customers", "public" and so on. You can have multiple repositories with different function. They (can) have branches with the same name, but have different purposes. To track more than one you _must_ rename at least one locally (and just with two remotes "master" is going to give you some issues).

Maybe you want the name in the public repo to be different than the name in your own repo.

[...]

The naming --current was not good, so I have changed it to --tracking in my latest suggestion. Why is it confused? Why do I need to call my branch locally the same as it is named remotely? That does not scale. Branch names are unique per repository, not globally.

I want to be able to "git pull" and then "git push --tracking" back to the same branch, not push somewhere else. Curently this requires a surprisingly complicated shellscript, and is not available from the guis.

The main problem with all these examples is that the underlying assumption is that you can always use the same branch name locally and remotely. This just isn't always the case when you have many remotes, and each remote repository has some implicit function (e.g. "beta", "john", "graphics-group", "my-public", .....), and they have an active "master" branch for example.

- Finn Arne

Finn Arne Gangstad <finnag@pvv.org> writes:

Presumably the push --track option would be used with an explicit branch name given to push anyway, right? Then it can use that info to set up the tracking flexibly (and with sane defaults).

E.g.,, simple case:

    git push --track SOME_REMOTE BRANCH_NAME

complex case:

    git push --track SOME_REMOTE MY-BRANCH:REMOTE-BRANCH

-Miles

On Thu, Mar 12, 2009 at 07:52:29PM +0900, Miles Bader wrote:

Yes, git push --track ... would typically do the same thing to the config as git checkout -b MY-BRANCH SOME_REMOTE/REMOTE-BRANCH, which is enough for push --tracking to do its thing.

I am not sure if you mean that git push --track could do something extra to make --tracking unecessary for git push, currently it cannot do that since the push configuration is per remote, not per branch.

- Finn Arne

Finn Arne Gangstad <finnag@pvv.org> writes:

Hmm, now I'm confused... I was just thinking about --track, but am not sure what --tracking is ... need to go grovel past posts...

-Miles

Hi,

   What's the status of these patches?  Will be commited?

John

2009/3/13 Miles Bader <miles@gnu.org>:

On Mon, Mar 09, 2009 at 11:35:44PM +0100, Finn Arne Gangstad wrote:

I have not been following this topic too closely, so can you please explain (or point me to an explanation about) something? How do these options interact with refspecs given on the command line? That is, why would I choose to use:

  git push --current

over

  git push - HEAD

(assuming your earlier patch is applied, or "git push HEAD" if Junio's suggested DWIMmery is implemented). And what does it mean to say

  git push --matching - HEAD

? Those are conflicting instructions. Is one followed and one discarded? Are they merged?

-Peff

On Tue, Mar 10, 2009 at 01:52:33PM -0400, Jeff King wrote:

--current pushs the current branch to whatever it is tracking, no matter what name it has (i.e. it can push to a branch of different name). If it is not tracking anything, it will not push.

git push - HEAD pushes the current branch to a branch of the same name on the "current remote", which defaults to origin if nothing is set up for the branch.

It would be an error, no refspecs can be specified with --matching.

- Finn Arne

On Tue, Mar 10, 2009 at 11:04:00PM +0100, Finn Arne Gangstad wrote:

OK, that's what I was missing. Thanks.

-Peff

On Tue, Mar 10, 2009 at 6:04 PM, Finn Arne Gangstad <finnag@pvv.org> wrote:

I think the option is definitely misnamed then. If it survives the list feedback, it should probably be called something like --tracked.

j.