On Fri, Oct 26, 2012 at 2:42 AM, Angelo Borsotti <angelo.borsotti@xxxxxxxxx> wrote: > Hi Drew, > ------Adding for clarity: On Thurs, Oct 25, 2012 at 17:16 EDT, Drew Northup wrote: >> >> Changing the tag in the local repository is a tag modification >> operation. Pushing that change to a remote repository DOES NOT execute >> "git tag...." in the remote. Plain and simple the two are different >> operations. >> > > They are different for what concerns the implementation. They are not > necessarily so for what concerns their semantics, and the most > straightforward is to apply to the remote repository the changes done > on the local one -- the changes that can legally done on it -- and > changing a tag is not one allowed (unless forced). So you want the rules of "git tag" to be forced upon "git push." I heard (read) that already. By what means do you intend to enforce that? Please go look at the code of "git push" (builtin/push.c) before coming back with an answer. > Obviously, the semantics of git-push is different, and then needs to > be described clearly. > Note that some (probably most) of the operations that are disallowed > on the local repo are also disallowed by git-push, like, e.g. deleting > the current branch. But the user cannot tell what is disallowed and > what not if the man page does not state it. If you think something is inadequately documented then do please submit a patch proposing the changes you would like to see. Even if it isn't quite right the first time you can get help from interested people on the list getting it accepted. If nothing else you'll get some constructive discussion going. (As for deleting the current branch, you can't really do that on a proper bare remote anyway as there is no such thing as a "current branch" in that context.) >> So here we come to the core argument. Is sounds to me like you want >> changes to remote tags to work differently from push updates to ALL >> other references. The required change, if I'm not mistaken, would be >> for tags to not permit fast-forward updates while all other references >> would be pushed normally. From my brief and un-enlightened look at the >> push code I can't see that being as easy as it sounds. >> > > No, I was hoping that git-push refused to change tags at all, unless > forced (e.g. prefixing them with +), as it is on a local repository. I'm not sure how you get to negate my statement and then restate it and think that you are saying something different. Please go look at the the source code. Tags are just a class of refs that we set aside for human consumption while also providing them with meaning that the computer can understand. What are refs then? Refs are REFERENCES to specific objects (at this point I know only of commits being _referenced_ that way) by their sha hashes (literally, that's what the file contains) in the repository. That's it. Git push/pull doesn't handle them any differently may they be heads or tags. (Remote heads, aka tracking branches, are references to objects in the repository that do not exist in a local branch. It doesn't look like we push those, but I could be wrong.) What Git does do is allow you the flexibility of pushing refs selectively (with some caveats). Once tags are loaded into the queue of references to be pushed they are handled like any other kind of reference. If you think there would be a benefit to making the reference pushing code "type aware" then do please look into the code and submit a patch. I am not going to waste any more time arguing about how it "should be" if you cannot go to the trouble of reading the code and coming up with a solution that implements what you would like to see happen. Frankly, if all you can come up with is pseudocode you still will at least have a chance of working with the people here on this list to to write up something that implements the behavior you would like to see. The first step to that is understanding how it actually works now. -- -Drew Northup -------------------------------------------------------------- "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html