Junio C Hamano <gitster@xxxxxxxxx> writes: > My knee-jerk reaction is to avoid "--heads" and instead use > "--branches", if this is about pushing all local branches. The > option "--heads" may still remain in some commands added to the > system in the earliest part of our history, but soon we started > to use "branch" over "head", as it is a more commonly used word. OK, that's true, I just misled by some existing '--heads' in other commands. > How should it interact with --follow-tags? Just as if you listed > all local branch names on the command line? I.e. is Actually I didn't try '--follow-tags' before, but the documentation about it is a ittle hard to understand for me on first reading. Then, I think it supports to use as negative '--[no-]follow-tags' but not marked in the git-push.txt documentation. > git push $URL --heads > > equivalent to the long-hand > > git push $URL $(git for-each-ref --format='%(refname)' refs/heads/\*) git push $URL $(git for-each-ref --format='%(refname)' refs/heads/\*\*) maybe to recursivly subdirectories matching? Actually I didn't get why you represent this, maybe try to let's us know there is another way we could make it as the same result? > and because of that, does > > git push $URL --any --other --option --heads > > behave identically to the long-hand with these other options added? I think you concerned about the compatibility with the interaction of the options, if so, I think a direct way is to keep --all and --heads both have the some behavior when interact with other options, a little confused why we have to use the long-hand to do that. By the way, it seems like there are no specify tests for '--all', maybe we can add some tests about '--all' first if this RFC patch is worthy to continue. Thanks.
