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
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,
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
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
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
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
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
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
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
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
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.
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
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
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
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,
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
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!
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
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
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
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
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
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
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,
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
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
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,
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
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
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.
30 matches
Mail list logo