Re: Minor annoyance with git push

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

Actually, after carefully examining what I have been doing, I think this "somebody cries 'git push ;# nothing else' does not work, and old timer needs to remember to check one extra thing to help" has been a bit overblown.

To diagnose "git push ;# nothing else", you would already need to ask the following _anyway_:

 - On what branch are you?

 - Do you have "branch.$current_branch.remote"?

 - What is "branch.$current_branch.remote" set to?

 - Do you have remote.$that_remote.url?

   - If it is http://, do you have very new version of curl
     library, often not even in distro?

   - If it is http://, does it end with '/'?

   - If it is http://, do you have DAV enabled over there?

   - If it is host:path, does your non-interactive ssh get
     appropriate PATH at the other end?

   - Is your username there the same as local?  Otherwise do you
     have "User your_name_over_there" set up in your
     $HOME/.ssh/config?

   - 47 other questions about transfers.

 - Do you have remote.$that_remote.push?

 - What local branches do you have?

 - What local branches does $that_remote have?

So it is not _so_ unreasonable if we add an extra configuration or two to this mix.

What configuration semantics is reasonable is a different matter. Let's back up a bit.

The "matching" semantics has been advertised as a convenient way to keep track of which branches you would want publish and which ones to keep private without having to have extra configuration. This is very true for people whose workflow is based on _owned_ public distribution points. The destination is controlled by you and you alone, and after pushing the branches you want to show out explicitly, the destination repository _remembers_ which branches you are interested in publishing for later "matching" pushes. When you are no longer interested in showing that work, you remove it from the remote and matching and that (1) stops publishing and at the same time (2) remembers you are no longer interested in publishing.

However, when you allow others to push into the destination, the set of branches there obviously cannot serve as your private configuration anymore. So "matching" can never be a convenient way if your push is to a shared repository.

Which would mean that "matching" is not a personal taste nor even per-repository matter. I think it is reasonable to set this per-remote.

    You may have a repository you use during daytime on your
    desktop, and the repository may have more than one remotes
    defined.  "origin" may point to a shared repository you push to
    and fetch from in order to work together with others, "backup"
    may point to another repository on your server you push your
    work into, and "satellite" may point to yet another repository
    on your notebook when you are done for the day and take your WIP
    along with you.

    You may not want "matching" when interacting with the shared
    repository (if you always want "current only" is a different
    matter, but let's pretend you do), but you would want
    "matching" when pushing back to "satellite", and you would
    want "mirror" when pushing to "backup".

So perhaps we can have "remote.*.push" that says "current" in some way. Tentatively let's say the syntax is like this:

	[remote "origin"]
        	url = server.oss.example.org:/pub/project.git/
                push = HEAD
                fetch = +refs/heads/*:refs/remotes/origin/*
	[remote "backup"]
        	url = server.example.com:/home/me/mine.git/
                push = +refs/*:refs/*
	[remote "satellite"]
        	url = notebook.example.com:/home/me/mine.git/

	[branch "master"]
        	remote = "origin"
                merge = refs/heads/master
	[branch "ticket-47"]
               	remote = "origin"
                merge = refs/heads/ticket-47

While on "master", "git push" will say...

	Ah, you are too lazy to say where to push to.
	branch.master.remote says "origin", so that is it.

	And you are too lazy to say what to push either.
	remote.origin.push says HEAD which is a special token
	that means the current branch.

	Let's pretend you told me "git push origin master"

I was hoping we can do without the "remote.*.push = HEAD" if we can detect the remote is a shared repository while talking to it, but I think it is a bit too much magic, because we cannot visualize what the pushing side and the receiving side are negotiating.

Putting this "push = HEAD" by default when "git clone" and "git remote add" creates the [remote "$remote"] section is probably possible, and at that stage we may even be able to do the "if the other end is shared, then set this up automagically", as the result of the magic can be inspected in the resulting config file.