Hi,

On Fri, 8 Feb 2008, Martin Langhoff wrote:

quoted text
> To git+ssh://git.catalyst.net.nz/var/git/moodle-r2.git
>  ! [rejected]        mdl17-ceo -> mdl17-ceo (non-fast forward)
>  ! [rejected]        mdl18-local -> mdl18-local (non-fast forward)
>  ! [rejected]        mdl18-masseyedu-wimbatest ->
> mdl18-masseyedu-wimbatest (non-fast forward)
>  ! [rejected]        mdl18-nmit -> mdl18-nmit (non-fast forward)
>  ! [rejected]        mdl18-proxy -> mdl18-proxy (non-fast forward)
>  ! [rejected]        mdl18-shared -> mdl18-shared (non-fast forward)
>  ! [rejected]        mdl18-sqm -> mdl18-sqm (non-fast forward)
>  ! [rejected]        mdl18-stcuthberts -> mdl18-stcuthberts (non-fast forward)
>  ! [rejected]        mdl18-topnz -> mdl18-topnz (non-fast forward)
>  ! [rejected]        mdl19-dbperf -> mdl19-dbperf (non-fast forward)
>  ! [rejected]        mdl19-ucol -> mdl19-ucol (non-fast forward)
>  ! [rejected]        mdl19-uow -> mdl19-uow (non-fast forward)
> error: failed to push to 'git+ssh://git.catalyst.net.nz/var/git/moodle-r2.git'
> 
> The error messages ("! rejected", "error: failed to push") appear even
> if one or two branches did get pushed... I think they are a bit over
> the top. None of these "rejected" branches have anything _new_, they
> are just stale.

So you're saying that the local sides' refs are ancestors of the remote 
sides' refs?

The problem is that the local side cannot tell, and we try to avoid 
putting load on the server, because in many cases, there will be one 
central server and many clients.

So I think this is not technically feasible.  Or do you have another idea 
how to find out that the "[rejected]" ref is a stale ref (i.e. an ancestor 
of the remote side) as opposed to properly rejected?

Another way to "solve" this issue, of course, is to use the remote layout.  
I did the switchover myself some time ago; it was hard at first, since I 
was so used to just check out the branches I just fetched.  But in the 
long run the distinction between local and tracking branches made life 
much easier for me.

Related is this idea that I did not really follow up: often, you want to 
work on a branch which you are tracking already, but there is no local 
branch.  And most often, you just want to create a local branch of the 
same name.  So maybe we should just introduce a new flag, like

	$ git checkout -c origin/next

which would create (or fast-forward) the local branch "next" to what's in 
origin/next.  The long option would read --create-local.

In the same vein, maybe "git branch -d next" should be taught to look at 
the remote branches of name "<nick>/next", too, when checking if that ref 
is an ancestor of HEAD?

Ciao,
Dscho

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