git-push [--all] and tags

Hello people,

`git-push --all --tags` does not work because git-push ends up calling git-send-pack --all refs/tags/*, which the latter does not deal with.

Looking at the code, it seems that previously, --all would push everything, not just refs/heads/*. What's the reason that this was changed? Why aren't tags considered part of --all?

If I wanted to fix this, so that --all pushes heads and --all --tags pushes heads and tags, I could do so in two ways:

  1. instead of --all, pass refs/heads/* to git-send-pack
  2. add --tags to git-send-pack

which of these two would you prefer and why?

Thanks,

martin f krafft wrote:

Think is, pushing tags is considered to be something that needs to be done very explicitly; the convention, after all, is that published tags are forever. Whereas branches change all the time. So, pushing tags should require an extra flag.

Sam.

On Sun, 7 Oct 2007, Sam Vilain wrote:

Well, I agrewe with Martin, and I think you missed his point.

Sure, pushing tags should require you to say so explicitly, but right now you cannot (for example) push *both* the common branches *and* tags easily.

You can do

	git push

to push common branches, and you can do

	git push --tags

to push tags, but there's no way to say "push both the common branches _and_ all tags".

(And the same is true of "--all" and "--tags").

So I do think Martin is right. I think we should:

 - make sure that "--all --tags" DTRT, namely send all branches and all 
   tags. Right now they are actually very similar things (one works on 
   "refs/heads", while the other works on "refs/tags"), but they are 
   implemented using *totally* different logic, and they don't work 
   together.

 - I think it would be a good idea to implement a "--shared" flag, which 
   is the current default behavior when there are no command line flags, 
   and there are no listed branches to push in the config file. That would 
   allow doing "git push --shared --tags" to update shared branches _and_ 
   tags, but it would probably *also* make it easier to explain the 
   default behaviour of "git push", by making the behavior more explicit.

   (IOW, you can introduce the notion of "--shared updates all branches 
   that exists both locally and remotely under the same names" separately 
   early on as a command line option, and then later just explain that if 
   there is nothing else telling git what to push, it will default to 
   that shared branch behavior)

Hmm? I do agree with "git push" as it now stands has a lot of warts, although I don't really agree with the people who want to change the default behavior.

			Linus

also sprach Linus Torvalds <torvalds@linux-foundation.org> [2007.10.07.0226 +0100]:

(he did)

So am I right if I say that all the logic should really be happening in send-pack and that push is really just an interface when it comes to selecting the refs to push, so it should basically feed through the options and refs, meaning that send-pack should get --tags and --shared as well?

Or should push enumerate all refs needed and pass them directly to send-pack, effectively making send-pack's --all option obsolete?

On Sun, 7 Oct 2007, martin f krafft wrote:

I really don't have any strong personal opinions. I don't think anybody is ever supposed to use send-pack directly, so I don't think it really much matters whether send-pack is taught to do all the helper options too, or whether it should just get the list of refs..

But yes, I suspect it would be cleanest to just remove the "expand --tags" logic from builtin-push, and make the actual sending side do that.

I don't think this works very well - builtin-push doesn't even know what the remote branches _are_, so it cannot list "these branches are shared". So we'd always have to have that shared behaviour embedded in send-pack anyway, so I think the most logical thing is to also do the logic for --all and --tags there.

IOW, builtin-push would just be a wrapper around send-pack, doing the "for each remote" thing, but just passing down all/tags/shared.

		Linus