Re: [PATCH v3 0/5] push: update remote tags only with force
Angelo Borsotti angelo.borso...@gmail.com writes: I am *not* convinced that the refs/tags/ is the only special hierarchy whose contents should not move is a bad limitation we should avoid, but if it indeed is a bad limitation, the above is one possible way to think about avoiding it. What other hierarchy besides branches and tags is there? Do you have in mind some other that should not move? People use their own hierarchies for various purposes that are not pre-defined by git-core, e.g. refs/changes/, refs/pull/, etc. Depending on the semantics the projects want out of these hierarchies, some of them may well be considered create-only. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] push: update remote tags only with force
On Wed, Nov 14, 2012 at 12:29:14AM -0600, Chris Rorvick wrote: 2. Require force when updating tag references, even on a fast-forward. push: flag updates push: flag updates that require force push: update remote tags only with force An email thread initiated by Angelo Borsotti did not come to a consensus on how push should behave with regard to tag references. I think the original motivation of allowing fast-forward updates to tags was for people who wanted to have today's recommended version tag that can float from day to day. I tend to think that was a misguided notion and it is better implemented with a tip of a branch (iow, I personally am OK with the change to forbid tag updates altogether, without --force). I think a key point is that you currently cannot be sure your push will not clobber a tag (lightweight or not) in the remote. Do not update, only add new may be a good feature, but at the same time I have this suspicion that its usefulness may not necessarily be limited to refs/tags/* hierarchy. I dunno. Are you suggesting allowing forwards for just refs/heads/*? I initially went this route based on some feedback in the original thread, but being that specific broke a couple tests in t5516 (i.e., pushing to refs/remotes/origin/master and another into refs/tmp/*.) My initial thought was that I'd broken something and I need to modify the patch, but now I think I should just modify those tests. Branches are restricted to refs/heads/* (if I understand correctly), so allowing fast-forwards when pushing should be limited to this hierarchy, too. What about notes? I think they should be treated in the same way as branches. My impression is that tags are exceptional in this respect. -- Kacper -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] push: update remote tags only with force
Chris Rorvick ch...@rorvick.com writes: Do not update, only add new may be a good feature, but at the same time I have this suspicion that its usefulness may not necessarily be limited to refs/tags/* hierarchy. I dunno. Are you suggesting allowing forwards for just refs/heads/*? No, it is a nonsense to unconditionally forbid fast-forwards to refs outside refs/heads/ hierarchy. I was imagining a more general feature to allow the *user* to ask Git not to fast-forward some refs (not limited to refs/tags/) during a push. If such a general feature were in place, you can think of your patch as automatically making the user to ask Git not to fast-forward refs in refs/tags/, which would be a mere special case of it. And I was wondering if such a general feature makes sense. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] push: update remote tags only with force
Hi Junio, actually, I proposed to add a key in config files, e.g. pushTagsNoChange to be set in the remote repo do disallow changes to tags, similar to pushNonFastForward that disallows non-fastforward changes to branches. I still have the impression that this is simple and clear, and allows the owner of the remote repository to enforce the policy s/he wants on her/his repository. -Angelo On 14 November 2012 14:22, Junio C Hamano gits...@pobox.com wrote: Chris Rorvick ch...@rorvick.com writes: Do not update, only add new may be a good feature, but at the same time I have this suspicion that its usefulness may not necessarily be limited to refs/tags/* hierarchy. I dunno. Are you suggesting allowing forwards for just refs/heads/*? No, it is a nonsense to unconditionally forbid fast-forwards to refs outside refs/heads/ hierarchy. I was imagining a more general feature to allow the *user* to ask Git not to fast-forward some refs (not limited to refs/tags/) during a push. If such a general feature were in place, you can think of your patch as automatically making the user to ask Git not to fast-forward refs in refs/tags/, which would be a mere special case of it. And I was wondering if such a general feature makes sense. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] push: update remote tags only with force
Angelo Borsotti angelo.borso...@gmail.com writes: actually, I proposed to add a key in config files, e.g. pushTagsNoChange to be set in the remote repo do disallow changes to tags, similar to pushNonFastForward that disallows non-fastforward changes to branches. I still have the impression that this is simple and clear, and allows the owner of the remote repository to enforce the policy s/he wants on her/his repository. That is an independent issue of deciding to accept or reject receiving a push from outside, no? You can implement any such policy in the pre-receive hook on the receiving end with a simple and clear manner, instead of adding specific logic to enforce a single hardcoded policy to the code that is flipped on with a configuration variable. In any case, I thought this series was about users who run push voluntarily stopping themselves from pushing updates to tags that may happen to fast-forward, so if we were to go with the configuration route, the suggestion would be more like [push] updateNeedsForce = refs/tags/:refs/frotz/ or perhaps [remote origin] updateNeedsForce = refs/tags/:refs/frotz/ if we want to configure it per-remote, to specify that you would need to say --force to update the refs in the listed hierarchies. Then your patch series could become just the matter of declaring that the value of push.updateNeedsForce, when unspecified, defaults to refs/tags/. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] push: update remote tags only with force
Hi Junio, That is an independent issue of deciding to accept or reject receiving a push from outside, no? Yes, it is. Actually I thought some means to let the owner do decide what to accept were already present (the pushNonFastForward config key), and going along this avenue I thought it could be appropriate to extent this a bit. -Angelo On 14 November 2012 18:32, Junio C Hamano gits...@pobox.com wrote: Angelo Borsotti angelo.borso...@gmail.com writes: actually, I proposed to add a key in config files, e.g. pushTagsNoChange to be set in the remote repo do disallow changes to tags, similar to pushNonFastForward that disallows non-fastforward changes to branches. I still have the impression that this is simple and clear, and allows the owner of the remote repository to enforce the policy s/he wants on her/his repository. That is an independent issue of deciding to accept or reject receiving a push from outside, no? You can implement any such policy in the pre-receive hook on the receiving end with a simple and clear manner, instead of adding specific logic to enforce a single hardcoded policy to the code that is flipped on with a configuration variable. In any case, I thought this series was about users who run push voluntarily stopping themselves from pushing updates to tags that may happen to fast-forward, so if we were to go with the configuration route, the suggestion would be more like [push] updateNeedsForce = refs/tags/:refs/frotz/ or perhaps [remote origin] updateNeedsForce = refs/tags/:refs/frotz/ if we want to configure it per-remote, to specify that you would need to say --force to update the refs in the listed hierarchies. Then your patch series could become just the matter of declaring that the value of push.updateNeedsForce, when unspecified, defaults to refs/tags/. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] push: update remote tags only with force
Hi Junio, I am *not* convinced that the refs/tags/ is the only special hierarchy whose contents should not move is a bad limitation we should avoid, but if it indeed is a bad limitation, the above is one possible way to think about avoiding it. What other hierarchy besides branches and tags is there? Do you have in mind some other that should not move? -Angelo On 15 November 2012 01:09, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Addendum. In any case, I thought this series was about users who run push voluntarily stopping themselves from pushing updates to tags that may happen to fast-forward, so if we were to go with the configuration route, the suggestion would be more like [push] updateNeedsForce = refs/tags/:refs/frotz/ or perhaps [remote origin] updateNeedsForce = refs/tags/:refs/frotz/ if we want to configure it per-remote, to specify that you would need to say --force to update the refs in the listed hierarchies. Then your patch series could become just the matter of declaring that the value of push.updateNeedsForce, when unspecified, defaults to refs/tags/. The above is not a you should do it this way suggestion, by the way. I was just explaining what I meant by it may be a good feature, but may not necessarily be limited to refs/tags in my earlier message in a different way ... and a possible design that lifts the limitation may go like this. I am *not* convinced that the refs/tags/ is the only special hierarchy whose contents should not move is a bad limitation we should avoid, but if it indeed is a bad limitation, the above is one possible way to think about avoiding it. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] push: update remote tags only with force
Chris Rorvick ch...@rorvick.com writes: Minor changes since from v2 set. Reposting primarily because I mucked up the Cc: list (again) and hoping to route feedback to the appropriate audience. This patch set can be divided into two sets: 1. Provide useful advice for rejected tag references. push: return reject reasons via a mask push: add advice for rejected tag reference Recommending a merge to resolve a rejected tag update seems nonsensical since the tag does not come along for the ride. These patches change the advice for rejected tags to suggest using push -f. Below, I take that you mean by tag reference everything under refs/tags/ (not limited to annotated tag objects, but also lightweight tags). Given that the second point below is to strongly discourage updating of existing any tag, it might be even better to advise *not* to push tags in the first place, instead of destructive push -f, no? 2. Require force when updating tag references, even on a fast-forward. push: flag updates push: flag updates that require force push: update remote tags only with force An email thread initiated by Angelo Borsotti did not come to a consensus on how push should behave with regard to tag references. I think the original motivation of allowing fast-forward updates to tags was for people who wanted to have today's recommended version tag that can float from day to day. I tend to think that was a misguided notion and it is better implemented with a tip of a branch (iow, I personally am OK with the change to forbid tag updates altogether, without --force). I think a key point is that you currently cannot be sure your push will not clobber a tag (lightweight or not) in the remote. Do not update, only add new may be a good feature, but at the same time I have this suspicion that its usefulness may not necessarily be limited to refs/tags/* hierarchy. I dunno. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] push: update remote tags only with force
On Sun, Nov 11, 2012 at 11:08 PM, Chris Rorvick ch...@rorvick.com wrote: Minor changes since from v2 set. . An email thread initiated by Angelo Borsotti did not come to a consensus on how push should behave with regard to tag references. Minor Nit: Without the link to gmane it is an exercise left to the reviewer to find that you're talking about this thread: http://thread.gmane.org/gmane.comp.version-control.git/208354 Cheers. -- -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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/5] push: update remote tags only with force
Minor changes since from v2 set. Reposting primarily because I mucked up the Cc: list (again) and hoping to route feedback to the appropriate audience. This patch set can be divided into two sets: 1. Provide useful advice for rejected tag references. push: return reject reasons via a mask push: add advice for rejected tag reference Recommending a merge to resolve a rejected tag update seems nonsensical since the tag does not come along for the ride. These patches change the advice for rejected tags to suggest using push -f. 2. Require force when updating tag references, even on a fast-forward. push: flag updates push: flag updates that require force push: update remote tags only with force An email thread initiated by Angelo Borsotti did not come to a consensus on how push should behave with regard to tag references. I think a key point is that you currently cannot be sure your push will not clobber a tag (lightweight or not) in the remote. Also, I wonder what workflow would rely on this fast-forward feature of pushed tag references that would not be better served a branch? This patch set contains some minor updates from the previous set: * remote.c: remove redundant check of ref-update * transport.c: remove extraneous tab in indent * builtin/send-pack.c: fix call to transport_print_push_status() (per feedback from Peff) Also, rebased against the latest master in git://github.com/peff/git.git to pickup changes in nd/builtin-to-libgit. Chris Rorvick (5): push: return reject reasons via a mask push: add advice for rejected tag reference push: flag updates push: flag updates that require force push: update remote tags only with force Documentation/git-push.txt | 10 +- builtin/push.c | 24 +++- builtin/send-pack.c| 9 +++-- cache.h| 7 ++- remote.c | 38 ++ send-pack.c| 1 + t/t5516-fetch-push.sh | 30 +- transport-helper.c | 6 ++ transport.c| 25 +++-- transport.h| 10 ++ 10 files changed, 120 insertions(+), 40 deletions(-) -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
