On 13.03.2012 18:41, Junio C Hamano wrote:
Holger Hellmuth<hellmuth@xxxxxxxxxx> writes:
If Peff's "push to same branch in a different remote" is a bug (and
IMHO it is) it should not count as a reason for what should be the
default.
I may phrased it poorly, but I don't think you mean "if the bug is fixed,
then the behaviour of upstream is simple and easy to understand". The
I think the behaviour of the whole pull/push system is not easy to
understand. One has to learn a lot of concepts about git before being
able to answer the simple question "if I do 'git push' now, what happens?".
Since I am using git without any collaboration I never had much need to
play around with the whole porcelain remote configuration (cloning and
using git config was enough). So today I tried to create a bidirectional
link between a local and a remote branch using only porcelain commands
(i.e. without using git config directly). Somehow I didn't succeed. I
can either use git checkout --track or git push -u to make a pull
connection between the two, but to automatically push I would have to
create a branch of the same name (and know that this is the magical
ingredient that makes it work!)
Maybe what is missing is a parameter to git-push that tells git that
from now on this is what git push should do per default in this branch
(Similar to what git checkout --track does). This would mean that even
new users could do most remote configuration with just the knowledge of
git checkout and git push.
By the way I think I found another "hole" in the porcelain: If you add a
single branch to follow with git remote add -t <branch> ..., you can't
add another. A second git remote add -t <otherbranch> ... will be met
with an error that the remote is already configured. I would have to
delete the remote and add it again with git add -t <branch> -t
<otherbranch> ..... Or use a different remote name (which would be
confusing later on). Did I miss something?
--
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