Wishlist for branch management

A wishlist for better handling of branches:

git clone --branches

... git clone, with the additional step of setting up local branches for each one of the remote branches.

git branch --current

... list the current branch name, for use in scripts.  Equivalent to:
	"git branch | grep '^\*' | cut -c3-"

git push --current

... push the current branch, and only the current branch...

	-hpa

On 2010.01.31 17:18:39 -0800, H. Peter Anvin wrote:

In scripts, plumbing should be used. I use:
	git rev-parse --symbolic-full-name HEAD

This gives either the full refname of the checked out branch head, e.g. refs/heads/master, or HEAD in case of a detached HEAD.

Unless you want to push to a different ref remotely, e.g. pushing
refs/heads/master-public to refs/heads/master, you can use:
	git push <remote> HEAD

For example, when refs/heads/master is checked out, then:
	git push origin HEAD
acts the same as:
	git push origin refs/heads/master

Björn

On 01/31/2010 05:31 PM, Björn Steinbrink wrote:

Whatever is used, it should respect the configuration. This requires knowing what the configuration is set up as.

	-hpa

On Sun, Jan 31, 2010 at 05:18:39PM -0800, H. Peter Anvin wrote:

Yes please! ;-) However, there should be a corresponding command to do this with a remote within existing repository. Perhaps something like

	git remote populate

(stealing some syntax from topgit ;-).

I'm used to git symbolic-ref HEAD. I like the fact that human-friendly and scripting interfaces are mostly separated to different commands. This also has saner behaviour when HEAD is not on a branch. (Which is also a reason why operation like this should be done only when there's a damn good reason to need to know the branch name.)

Yes. Even in the HEAD form, it would be nice to have something that does not require me to write out 'origin' or whatever my remote default is. Perhaps `git push - HEAD`. There's certain disparity, we have an alias for the current branch (HEAD) but not for the current remote.

P.S.: I know. It's all just bikeshedding without patches...

On 02/01/2010 01:19 AM, Petr Baudis wrote:

It's makes the learning curve for scripting git unnecessarily large. Furthermore, it's rather unrealistic for people who are not git people to follow this dictum -- I have seen the git scripts that the kernel people write, including myself, and they generally tend to use the same commands they're used to using themselves.

So I think it's actually a really bad UI design. It helps making clear what is scriptable (stable) and what isn't, but expecting people to use a different mental rubric when scripting than when working on the command line is completely unrealistic.

	-hpa