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

From: Steffen Prohaska <prohaska@zib.de>
Date: Oct 31, 2007, 15:08 UTC
Message-ID: <104D272D-AD9E-49D7-A503-E9402766CF6F@zib.de>
In-Reply-To: <7v1wbfufbo.fsf@gitster.siamese.dyndns.org>

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

Show 53 quoted lines

> Steffen Prohaska <prohaska@zib.de> writes:
>
>> On Oct 28, 2007, at 5:03 PM, Junio C Hamano wrote:
>> ...
>>> 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