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

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

git branch --current

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

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.

git push --current

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

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:

quoted

git push --current

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

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

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

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

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.

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 ;-).

git branch --current

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

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.)

git push --current

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

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...

-- 
				Petr "Pasky" Baudis
If you can't see the value in jet powered ants you should turn in
your nerd card. -- Dunbal (464142)

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

I'm used to git symbolic-ref HEAD. I like the fact that human-friendly
and scripting interfaces are mostly separated to different commands.

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

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.