Jakub Narebski <jnareb@xxxxxxxxx> writes:
> Brief recap, to check if I understand things correctly:
>
> 1. If you use "matching" more often, then it should be enough to provide
> remote.<remotename>.push with refspec or wildcard refspec.
Eh, excuse me, what refspec would you write there? "matching"
is defined to push the intersection of what we have and what
they have when "git-push" is run. I do not think there is any
way to write that in remote.$there.push and cast in stone.
With "matching", you can arrange a set of semi-permanent
branches to be shown to others and let others build on, in
either "publishing" or "shared repository" model, while keeping
experimental branches in your private repository, and:
$ git push $there
will only send what are in "the set of semi-permament branches",
like 'master' and 'maint. Adding a new branch to that set is
just the matter of a one-shot:
$ git push $there next
(older git may have choked and asked you to be more explicit by
"next:refs/heads/next"). After you do it once, "matching" will
push 'master', 'maint', 'next' without any additional
configuration. Removing a branch from the set is also just a
matter of one-shot:
$ git push $there :next
When you replace 'next' in the above with something that is a
lot short lived, the principle is the same. I can push a topic
branch (say, jn/gitweb), asking "I have queued your patches but
I am having trouble merging this back to 'master' due to heavy
conflicts; could you do the honors instead?". While waiting for
you to respond to that request, I may add more commits to that
branch and the "matching" push by me will update what is shown
$there. Hopefully you would eventually pick it up and merge,
and either push the result back to my 'master' directly or
publish the result elsewhere for me to pull to my 'master'.
After all the interaction is done, the topic branch does not
have to stay $there and can be deleted. Then 'matching' will
not touch the topic branch anymore, even if I still keep it
privately in my repository.
> ... If one wants to push only current branch, one
> would use "git push --current" or "git push <remotename> HEAD".
I think that is the proposal by Steffen (added back CC).
I am wondering if an alternative approach could be simpler. If
we teach "git-push" to notice when only the refspecs are given
without remotename, and default to branch.$current.remote in
such a case, IOW, make these:
$ git push HEAD
$ git push next
push the obvious thing to the default remote, I _think_ we can
achieve the same effect as --current and a bit more.
The latter could be run after I made the 'next' integration
branch into a good shape, switched to 'pu' to merge up other
bits but before finishing that merging yet (it would not help me
personally as I do not work that way --- I push things out only
after I am done with all the public branches --- but it may help
the others).
> Question: what to do if there is no remote.<remotename>.push? Assume
> 1-1 matching?
One-to-one is what 'matching' does, and the way to trigger it is
not to have a remote.$there.push.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
