Skip to contentSkip to conversation

Wishlist for branch management

DISCUSSION H. Peter Anvin 3 participants 5 messages Jun 15, 2016

lore
Share & tools
lore
#0 lore raw

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

Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.
#1 lore raw
Quoted 4 lines · H. Peter Anvin

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.

Quoted 3 lines

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

#2 lore raw
Quoted 5 lines · Björn Steinbrink
Quoted 4 lines

git push --current

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

Quoted 9 lines

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

Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.
#3 lore raw
In reply to H. Peter Anvin
Quoted 6 lines · H. Peter Anvin

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

Quoted 4 lines

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

Quoted 3 lines

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

Signature · 3 lines
				Petr "Pasky" Baudis
If you can't see the value in jet powered ants you should turn in
your nerd card. -- Dunbal (464142)
#4 lore raw
Quoted 2 lines · Petr Baudis

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

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