On Nov 22, 2007, at 9:23 AM, Junio C Hamano wrote:
Steffen Prohaska <prohaska@xxxxxx> writes:
On Nov 22, 2007, at 2:48 AM, Junio C Hamano wrote:
...
An alternative could be to split [remote "name"] url into two
variants, fetch-url and push-url. While fetching by default
from two places without telling from which one does not make any
sense, pushing by default to two different places is quite a
normal thing to do, and we already do support more than one url
entries in [remote "name"] section used for pushing.
If we were to do this, it might also make sense to rename the
word 'origin' we use for the default remote name to 'default' or
something. People with shared repository workflow would fetch
from one repository and push back to the same repository, so the
distinction would not matter, but for others who need something
like you suggest, the default repository for fetching and
pushing are different, and while you may still consider where
you fetch from your 'origin', where you push into is not your
'origin' anymore.
I like this idea.
But in addition, we should have a branch.$name.push line that
can contain a remote head to push to.
Yes, but.
At that point, I think you would introduce a mismatch between
the traditional semantics of refspec and what you are trying to
do, unless you are careful.
The traditional semantics of refspecs-tied-to-remote is strongly
based on the assumption: "I will push to this remote when these
local branches are all ready to be pushed out, and they will all
go there together as an atomic update. When I am _that_ ready
to push, it does not matter which local branch I am on. The
branches that matter are all in good shape when I push."
You are making the behaviour of push dependent on which branch
you are on. During such a push, it is safe to assume that the
current branch is ready to be pushed out, but other ones can be
very much un-ready. The user needs a safety valve to prevent
other branches from being pushed out. Otherwise the user would
not be adding branch.$name.push to begin with.
This is not the only reason. If I'm thinking of a workflow
based on a shared repo, I see two more reasons
The user wants to limit the push to the current branch
because different branches in the remote (shared) repo may
have advanced. The user does not want to the see errors by
"git push" that complain about non-fast-forwards. The safety
valve is needed to protect from changes in the remote repo
(not for changes in the local one).
The second use case is to have multiple local branches that
refer to the same (shared) remote branch. If you want to push
the changes directly to the (shared) remote branch, you need to
"rename" the branch during the push. But you want to push only
a single branch: the current branch you're on. Hence you need
a per-branch configuration if you want "git push" to to the
work for you automatically. It would be nice if "git branch"
could be asked to set up branch.$name.push to point to the
correct remote branch (similar to "--track").
With what I have in mind in the longterm you could do
git checkout -b foo origin/master
work work work
git checkout -b bar origin/master
work work work
git checkout foo
git pull # or git fetch; git rebase
git push
git checkout bar
git branch -d foo
work work, ... and later push bar, too
Note, there are several other changes needed before this would
work:
- "git checkout" would have to set branch.$name.push.
- "-d" would needs to be accept deletion if all changes are on
shared remote branch.
It would probably need to become a target ref or a list of <URL,
target ref>, not a list of general refspecs like the value for
remote.$there.push variable. For example, you would want to say
"while on master, push it to repository A as refs/heads/master
and to repository B as refs/remotes/satellite/master", which
would be a typical arrangement if you are working on a satellite
machine, A is the shared central repository and B is mothership
to your satellite machine. The specification would talk only
about the target ref (not just "'can contain' a remote head to
push to"), and the source ref would always be the current
branch.
I guess you could use general refspec on branch.$name.push and
implement the safety by requiring (1) only one refspec appears
for such a variable, and (2) the LHS of the refspec matches the
$name of the branch, in order to make the parsing easier and to
keep the syntax uniform.
Or maybe I am being overly cautious again not to introduce any
more unnecessary user confusion, and just should give them even
longer rope to hang themselves. I dunno.
Yes.
In the simplest version, branch.$name.push should only contain
the remote part of the refspec. It should be symmetric to
branch.$name.merge.
So if branch.$name.push is set, "git push" means
git push <url-from-remote> $name:<value of branch.$name.push>
This is what I proposed earlier.
Steffen
-
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
