Re: error: src refspec refs/heads/master matches more than one.

[Ingo Rohloff]

Duy Nguyen pclouds at gmail.com writes:
 Prevent is a strong word. I meant we only do it if they force
 it. Something like this..
 

I would propose to make this even stronger:
Forbid to create any branches which start with any of:
- refs/
- heads/
- remotes/
- tags/

as long as you do not use the force option.

The idea here is that you also will not get ambiguities later when you pull
new branches into your repository.

so long
  Ingo


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ambiguous branch names...

[Ingo Rohloff]

Hello,

while trying out git (version 1.7.9.5), I did this:

git clone -- ssh://myserver/~rohloff/git/w1.git w1

So I just cloned a test repository.
The in the cloned w1 repository I executed:

git branch origin/master
git branch remotes/origin/master
git branch refs/remotes/origin/master

I now have got three *local* branches with the above names, which
now seems to make it impossible to refer to the master branch
from the origin *remote* repository.

Wouldn't it make sense to forbid such names for local branches ?
For example to enforce some rules like a local branch name *must not*
start with remotes/ or refs/ ?

so long
  Ingo
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Documentation about push.default=upstream is confusing

[Ingo Rohloff]

Hello,

I recently started to use git and now are digging through more and more
of the low level details.

What I recently tried was to do this for a repository created by Bob:

  git remote add -t for_bob anna url

So setup a remote (created by anna) for which a branch called 
for_bob is fetched.
Then git fetch anna.

Then
  git checkout -b from_anna anna/for_bob

So create a from_anna branch in Bobs repository which tracks the for_bob
branch in the remote anna repository.

Now git pull works as expected for the from_anna branch.

But git push does not, because from_anna has a different branch name
than the branch you want to push to (you want to push to the for_bob
branch).

So after googling I found out about the push.default=upstream config
option, which seems to do exactly what I want: It uses the tracking
information to decide to which remote branch I want to push.

Now for cross checking I looked up the documentation of push.default at
http://git-scm.com . It says:

- snip --
push.default ...

upstream - push the current branch back to the branch whose changes are
usually integrated into the current branch (which is called @{upstream}).
This mode only makes sense if you are pushing to the same repository you
would normally pull from (i.e. central workflow).

- snip -

I think the second sentence here is quite confusing.
To me it seems push.default=upstream is actually the best choice for a
*de-centralized* workflow.

Rationale:
Assume I pull the master branch from several remote repositories
(de-centralized workflow I guess).

To handle that I setup several remote tracking branches called:
  repo1_master   (tracks repo1/master)
  repo2_master   (tracks repo2/master)
  reap3_master   (tracks repo3/master)

Now without push.default=upstream I would have to either always explicitly
do something like:
  git push repo1 repo1_master:master
  git push repo2 repo2_master:master

Or modify .git/config to add that per default via push= entries.

Whereas with push.default=upstream everything works as expected it seems.

So if I am not wrong here, I would propose to rephrase the sentence
-- snip -
This mode only makes sense if you are pushing to the same repository you 
would normally pull from (i.e. central workflow).
-- snip -

To do that: Could someone point out, when it does NOT make sense to use
push.default=upstream ?

with best regards
  Ingo
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html