Re: git push tags

2012-10-30 Thread Chris Rorvick
On Mon, Oct 29, 2012 at 4:35 PM, Jeff King p...@peff.net wrote: On Mon, Oct 29, 2012 at 06:23:30PM +0100, Kacper Kornet wrote: That patch just blocks non-forced updates to refs/tags/. I think a saner start would be to disallow updating non-commit objects without a force. We already do so

Re: git push tags

2012-10-30 Thread Chris Rorvick
On Tue, Oct 30, 2012 at 1:34 PM, Angelo Borsotti angelo.borso...@gmail.com wrote: Hi Cris, I think a key in the config file of the remote repo is better than an option on git-push for what concerns security: it allows the owner of the remote repo to enforce the policy not to overwrite tags,

Re: git push tags

2012-10-29 Thread Angelo Borsotti
Hi, Pro Git, By Scott Chacon says: 2.6 Like most VCSs, Git has the ability to tag specific points in history as being important. Generally, people use this functionality to mark release points (v1.0, and so on). 2.6.2: A [lightweight] tag is very much like a branch that does not change

Re: git push tags

2012-10-29 Thread Michael Haggerty
I agree with you that it is too easy to create chaos by changing tags in a published repository and that git should do more to prevent this from happening without explicit user forcing. The fact that git internally handles tags similarly to other references is IMO an excuse for the current

Re: git push tags

2012-10-29 Thread Kacper Kornet
On Mon, Oct 29, 2012 at 09:12:52AM +0100, Angelo Borsotti wrote: Hi, to let the owner of a remote repository (one on which git-push deposits objects) disallow others to change tags, a key on its config file could be used. An option on git-push, or environment variable, or key in config file

Re: git push tags

2012-10-29 Thread Jeff King
On Mon, Oct 29, 2012 at 10:58:07AM +0100, Michael Haggerty wrote: I agree with you that it is too easy to create chaos by changing tags in a published repository and that git should do more to prevent this from happening without explicit user forcing. The fact that git internally handles

Re: git push tags

2012-10-29 Thread Drew Northup
On Mon, Oct 29, 2012 at 6:38 AM, Jeff King p...@peff.net wrote: On Mon, Oct 29, 2012 at 10:58:07AM +0100, Michael Haggerty wrote: I agree with you that it is too easy to create chaos by changing tags in a published repository and that git should do more to prevent this from happening without

Re: git push tags

2012-10-29 Thread Angelo Borsotti
Hi Drew, sure. That is a good starting point. I would suggest to block tag updates of existing tags if a dedicated option is present in the config of the remote repo, like, e.g. pushOverwriteTags. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to

Re: git push tags

2012-10-29 Thread Jeff King
On Mon, Oct 29, 2012 at 07:21:52AM -0400, Drew Northup wrote: I would have expected git to at least complain about updating an annotated tag with another annotated tag. But it actually uses the same fast-forward rule, just on the pointed-to commits. So a fast-forward annotated re-tag will

Re: git push tags

2012-10-29 Thread Drew Northup
On Mon, Oct 29, 2012 at 7:35 AM, Jeff King p...@peff.net wrote: On Mon, Oct 29, 2012 at 07:21:52AM -0400, Drew Northup wrote: I would have expected git to at least complain about updating an annotated tag with another annotated tag. But it actually uses the same fast-forward rule, just on

Re: git push tags

2012-10-29 Thread Angelo Borsotti
Jeff, Then on top of that we can talk about what lightweight tags should do. I'm not sure. If tags (even the lightweight ones) do not behave differently from branches, then they are of no use, and the main difference is that they do not move. So, I would suggest not to move them either.

Re: git push tags

2012-10-29 Thread Kacper Kornet
On Mon, Oct 29, 2012 at 07:35:00AM -0400, Jeff King wrote: On Mon, Oct 29, 2012 at 07:21:52AM -0400, Drew Northup wrote: I would have expected git to at least complain about updating an annotated tag with another annotated tag. But it actually uses the same fast-forward rule, just on

Re: git push tags

2012-10-29 Thread Jeff King
On Mon, Oct 29, 2012 at 06:23:30PM +0100, Kacper Kornet wrote: That patch just blocks non-forced updates to refs/tags/. I think a saner start would be to disallow updating non-commit objects without a force. We already do so for blobs and trees because they are not (and cannot be) fast

Re: git push tags

2012-10-28 Thread Johannes Sixt
Am 25.10.2012 08:58, schrieb Angelo Borsotti: Hello, git push tag updates silently the specified tag. E.g. git init --bare release.git git clone release.git integrator cd integrator git branch -avv touch f1; git add f1; git commit -m A git tag v1 git push origin tag v1 touch f2; git

Re: git push tags

2012-10-28 Thread Chris Rorvick
On Sun, Oct 28, 2012 at 1:15 PM, Johannes Sixt j...@kdbg.org wrote: Tags are refs, just like branches. Tags don't move is just a convention, and git doesn't even respect it (except possibly in one place[1]). You can't reseat tags unless you use -f, which is exactly the same with branches,

Re: git push tags

2012-10-28 Thread Philip Oakley
From: Chris Rorvick ch...@rorvick.com Sent: Sunday, October 28, 2012 7:59 PM On Sun, Oct 28, 2012 at 1:15 PM, Johannes Sixt j...@kdbg.org wrote: Tags are refs, just like branches. Tags don't move is just a convention, and git doesn't even respect it (except possibly in one place[1]). You can't

Re: git push tags

2012-10-28 Thread Drew Northup
On Sun, Oct 28, 2012 at 5:49 PM, Philip Oakley philipoak...@iee.org wrote: If I read it right it was where two users can tag two different commits with the same tag name [e.g. 'Release_V3.3'] and the last person to push wins, so anyone in the team can change what is to be the released version!

Re: git push tags

2012-10-28 Thread Chris Rorvick
On Sun, Oct 28, 2012 at 4:49 PM, Philip Oakley philipoak...@iee.org wrote: From: Chris Rorvick ch...@rorvick.com Sent: Sunday, October 28, 2012 7:59 PM On Sun, Oct 28, 2012 at 1:15 PM, Johannes Sixt j...@kdbg.org wrote: Tags are refs, just like branches. Tags don't move is just a

Re: git push tags

2012-10-26 Thread Angelo Borsotti
Hi Drew, 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

Re: git push tags

2012-10-26 Thread Drew Northup
On Fri, Oct 26, 2012 at 2:42 AM, Angelo Borsotti angelo.borso...@gmail.com 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

Re: git push tags

2012-10-26 Thread Chris Rorvick
On Fri, Oct 26, 2012 at 8:37 AM, Drew Northup n1xim.em...@gmail.com wrote: (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.) Really? When I clone a bare repository I see a HEAD, and Git

Re: git push tags

2012-10-26 Thread Angelo Borsotti
Hi Drew, git is an open source, community project, which means that it benefits from all the contributions of many people, and they are not restricted to patches. If the only one suggestions that were taken into account were patches sent by people that had the time to study the sources and

Re: git push tags

2012-10-26 Thread Drew Northup
On Fri, Oct 26, 2012 at 1:42 PM, Kacper Kornet drae...@pld-linux.org wrote: On Thu, Oct 25, 2012 at 05:16:00PM -0400, Drew Northup wrote: On Thu, Oct 25, 2012 at 3:05 PM, Angelo Borsotti angelo.borso...@gmail.com wrote: Are remote repositories less protected than the local ones? I think

Re: git push tags

2012-10-26 Thread Kacper Kornet
On Thu, Oct 25, 2012 at 05:16:00PM -0400, Drew Northup wrote: On Thu, Oct 25, 2012 at 3:05 PM, Angelo Borsotti angelo.borso...@gmail.com wrote: Are remote repositories less protected than the local ones? I think that to be consistent, the same strategy should be used on all repositories,

Re: git push tags

2012-10-26 Thread Kacper Kornet
On Fri, Oct 26, 2012 at 02:07:09PM -0400, Drew Northup wrote: On Fri, Oct 26, 2012 at 1:42 PM, Kacper Kornet drae...@pld-linux.org wrote: On Thu, Oct 25, 2012 at 05:16:00PM -0400, Drew Northup wrote: On Thu, Oct 25, 2012 at 3:05 PM, Angelo Borsotti angelo.borso...@gmail.com wrote: Are

Re: git push tags

2012-10-26 Thread Angelo Borsotti
Hello Drew, I made some further tests on git-push to see if it handled branches and tags in the same way, and have discovered the following differences: - git push origin --delete master remote: error: By default, deleting the current branch is denied - git push origin --delete

Re: git push tags

2012-10-26 Thread Kacper Kornet
On Fri, Oct 26, 2012 at 08:35:50PM +0200, Angelo Borsotti wrote: Hello Drew, I made some further tests on git-push to see if it handled branches and tags in the same way, and have discovered the following differences: - git push origin --delete master remote: error: By default,

Re: git push tags

2012-10-26 Thread Drew Northup
On Fri, Oct 26, 2012 at 3:00 PM, Kacper Kornet drae...@pld-linux.org wrote: On Fri, Oct 26, 2012 at 08:35:50PM +0200, Angelo Borsotti wrote: Hello Drew, Kacper thank you for the patch. To keep downward compatibility, the denial to update tags should perhaps be enabled with some

Re: git push tags

2012-10-25 Thread Drew Northup
On Thu, Oct 25, 2012 at 2:58 AM, Angelo Borsotti angelo.borso...@gmail.com wrote: Hello, git push tag updates silently the specified tag. E.g. git init --bare release.git git clone release.git integrator cd integrator git branch -avv touch f1; git add f1; git commit -m A git tag v1 git

Re: git push tags

2012-10-25 Thread Angelo Borsotti
Hi Drew, You specified -f (force) and it did exactly what you asked. That is fully documented (git help tag). Yes, it is, and I used it to show that there is a need to specify explicitly the intent to change a tag, that without such an indication would not be changed. Tags have many uses.