Community
Participate
Working Groups
We're using hierarchical branch names, e.g., "streams/4.0". When creating a new local branch to track those remote branches (e.g., "origin/streams/4.0") the default branch name always seems to be the last segment of the remote branch name. It's all to easy for unexperienced users like myself to forget to add "streams/" before hitting Ok. Can you change that default to contain everything but the leading "/refs/heads/origin/"? Or am I completely misunderstanding something?
Created attachment 206159 [details] Screenshot
(In reply to comment #0) > Can you change that default to contain everything but the leading > "/refs/heads/origin/"? The latter should read "refs/remotes/origin/". Having learned a little more about Git it seems that the default local branch name is a little harder to determine because the fetch refspec seems involved, too. The canonical format of a refspec parameter is "?<src>:<dst>" where <src> is in the remote and <dst> is in the local clone. The push refspec seems to be involved, too. A refspec parameter's format is the same, but <src> is in the local clone and <dst> is in the remote. For a reasonable and common workflow between a remote and a clone it seems that the push <src> is identical to the fetch <src>. That implies that a reasonable default for local branch names (push <src>) that fork from remote tracking branches (fetch <dst>) is the fetch <src>, i.e. the string that results from "reverse-applying" the fetch refspec to the remote tracking branch name.
Proposed fix pushed to: http://egit.eclipse.org/r/4632
> We're using hierarchical branch names, e.g., "streams/4.0". When creating a new > local branch to track those remote branches (e.g., "origin/streams/4.0") the > default branch name always seems to be the last segment of the remote branch > name. Why do you create a local branch to track a remote branch? Branches like "origin/streams/4.0" already are called "remote tracking branch" because they track a remote branch. Normally a local branch is only created for local development. > That implies that a reasonable default for local branch names (push <src>) that > fork from remote tracking branches (fetch <dst>) is the fetch <src>, i.e. the > string that results from "reverse-applying" the fetch refspec to the remote > tracking branch name. I do not think that the fetch refspec is relevant for the default name of a local branch. The fetch refspec matches a branch name on the remote server (<src>) with the name of the remote tracking branch on the local repository (<dst>). There is no local branch name involved. I also do not think that an existing push refspec plays a role here. There may be many push refspecs which have the remote branch as target which is tracked by the remote tracking branch. Therefore I think, that commit 00c48f8d0e350ddcd6ef42303f045233bf386411 fixes the problem of "/" in the branch name.
