Re: [PATCH 5/8] push, send-pack: support pushing HEAD to real ref name

On Oct 28, 2007, at 9:58 PM, Junio C Hamano wrote:

Steffen Prohaska [off-list ref] writes:

quoted

On Oct 28, 2007, at 5:03 PM, Junio C Hamano wrote:
...

quoted

An alternative, just to let me keep my nicer public image by
pretending to be constructive ;-)

Introduce a configuration "remote.$name.push_default" whose
value can be a list of refs.  Teach the push command without
refspecs:

	$ git push
	$ git push $remote

to pretend as if the listed refspecs are given, instead of the
traditional "matching branches" behaviour.

Then, introduce another option

	$ git push --matching
	$ git push --matching $remote

to override that configuration, if set, so that the user who
usually pushes only the selected branches can use the "matching
branches" behaviour when needed.

Along with your earlier "git push $remote HEAD" patch, this will
allow you to say:

	[remote "origin"]
        	push_default = HEAD

and your

	$ git push

will push only the current branch.

Sounds reasonable; but it is more work. I'm not starting to
implement this today.

Take your time; nobody is in a hurry.

If somebody usually uses "matching" behaviour, i.e. without
remote.$name.push_default configuration, but wants to push only
the current branch as a one-shot operation, we can obviously use
"git push $remote HEAD".  But to be complete, it may make sense
to have another option

	$ git push --current

that lets you omit $remote (and default to the value configured
with branch.$name.remote).

Here is an alternative proposal.

The idea is that in a workflow based on a shared repository
git pull and git push should be 'more' symmetric than they are
in a pull-only based workflow. The integration of changes is
'more' direct. Working against a shared repository may require
to integrate new changes before pushing. Changes are also
pushed directly to the remote branch you originally branched
off. Both is different from a pull-only workflow, where I first
push my changes to a privately owned but publicly readable repo
and someone else does the integration by pulling from there.

The branch in the shared repository serves as the single
'integration' branch. One can use 'git branch --track' to set
up local branches that automatically merge changes from the
shared 'integration' branch. That is git pull without further
arguments is the right command to integrate changes from the
shared branch to the local branch. (git provides more advanced
ways, but git pull is simple and in principle does the right
thing.)

What is missing is a simple way to 'push' local changes back
to shared integration branch in the remote repository. This
can be seen as a 'symmetric' operation to pulling. So, git push
should do the right thing. And the right thing is pushing the
current branch to the shared 'integration' branch.

The automerge behaviour stores information in branch.$name.remote
and branch.$name.merge that provide sufficient information to
make "git pull" the equivalent of

    git pull <remoteURL> <remoteref>

where <remoteURL> is the full URL of the remote stored in
branch.$name.remote, and <remoteref> is the value of
branch.$name.merge.

A 'symmetric' push command would push the current branch to the
remote head it originally was branched off, that is

    git push <remoteURL> <currentbranch>:<remoteref>

Now, the proposal is

- add a configuration variable branch.$name.push

- change git push to check if the push configuration variable
   is set for the current branch $name, and if so run the
   equivalent of

     git push branch.$name.remote $name:branch.$name.push


- teach git branch a flag --push/--no-push that sets up
   branch.$name.push. Add branch.autosetuppush configuration
   flag to configure if --push or --no-push is the default.
   (maybe we need better names here).


This breaks the symmetry between git fetch/git push and
replaces it with a symmetry between git pull/git push for some
branches. I believe this might be the right thing to do for
a workflow based on shared repos.

	Steffen