You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Emmanuel Bourg <eb...@apache.org> on 2019/10/24 08:28:33 UTC
Re: Git status update
Le 09/09/2019 à 17:29, Gary Gregory a écrit :
> What I meant is that, when we successfully create a release, then the
> release tag should go under 'rel/' instead of ''. Sorry for the
> misunderstanding.
If the vote mail mentions the tag name and the commit hash I don't see
the need to use read-only tags. The mail is archived all around the net
and the commit isn't going away. The risk of losing a release is zero.
I can see the downsides of using rel/ tags though:
* it can't be reverted and errors can't be corrected (without bugging
the infra team I guess, but they've more important things to do)
* it's inconsistent with past releases and we probably don't want to
retag all our repositories
* it doesn't look great, shorter tags look nicer
* it's longer to type when checking out tags from the command line
* it's non standard (never seen that anywhere)
* it doesn't solve any actual issue
* we want fewer steps to our release process, not more
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Git status update
Posted by sebb <se...@gmail.com>.
On Thu, 24 Oct 2019 at 12:54, Emmanuel Bourg <eb...@apache.org> wrote:
>
> Le 24/10/2019 à 12:54, sebb a écrit :
>
> > Without a fixed tag pointing to a commit, AIUI the commit can be
> > eliminated through a force push.
>
> Force pushing a branch doesn't erase the tags along it nor its parent
> commits. The commit and the tag still exist in the repository.
>
>
> > That is deliberate, to avoid the lost commit issue.
>
> Git commits aren't easily lost. They can be recovered from ASF backups,
> GitHub, developers working repositories and from the affected repository
> itself until it's garbage collected.
>
AFAIK all of the above eventually expire, so the commit can only be
recovered if its loss is noticed soon enough.
Provenance is far too important to have to rely on such time-consuming
and non-guaranteed methods.
> > It's standard within the ASF now.
>
> It's a feature provided by the ASF infrastructure if we are interested
> in using it, not a mandatory policy. I'm not interested in more complexity.
But you don't seem to mind if someone else has the complex job of
recovering a commit?
>
> >> * it doesn't solve any actual issue
> >
> > Yes, it does solve an issue - see above.
>
> Sorry but no, it never happened in Commons, this is purely theoretical.
How do you know if a commit has been lost?
Commons was using SVN until recently; SVN does not have the issue.
Also force pushes have only been enabled recently.
AIUI the point of the rel/* tags is to guard against misuse
(accidental or otherwise) of force-push.
> And should it happen anyway it's trivial to restore the original branch
> from a developer repository.
Assuming that the missing commit is noticed before the developer resyncs.
>
> >> * we want fewer steps to our release process, not more
> >
> > No, we want as few as possible, but no fewer.
>
> It's possible to work without read-only tags, so let's not overload our
> processes even more please.
Of course it's possible, but is it sensible?
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Git status update
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 24/10/2019 à 12:54, sebb a écrit :
> Without a fixed tag pointing to a commit, AIUI the commit can be
> eliminated through a force push.
Force pushing a branch doesn't erase the tags along it nor its parent
commits. The commit and the tag still exist in the repository.
> That is deliberate, to avoid the lost commit issue.
Git commits aren't easily lost. They can be recovered from ASF backups,
GitHub, developers working repositories and from the affected repository
itself until it's garbage collected.
> It's standard within the ASF now.
It's a feature provided by the ASF infrastructure if we are interested
in using it, not a mandatory policy. I'm not interested in more complexity.
>> * it doesn't solve any actual issue
>
> Yes, it does solve an issue - see above.
Sorry but no, it never happened in Commons, this is purely theoretical.
And should it happen anyway it's trivial to restore the original branch
from a developer repository.
>> * we want fewer steps to our release process, not more
>
> No, we want as few as possible, but no fewer.
It's possible to work without read-only tags, so let's not overload our
processes even more please.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Git status update
Posted by sebb <se...@gmail.com>.
On Thu, 24 Oct 2019 at 09:28, Emmanuel Bourg <eb...@apache.org> wrote:
>
> Le 09/09/2019 à 17:29, Gary Gregory a écrit :
>
> > What I meant is that, when we successfully create a release, then the
> > release tag should go under 'rel/' instead of ''. Sorry for the
> > misunderstanding.
>
> If the vote mail mentions the tag name and the commit hash I don't see
> the need to use read-only tags. The mail is archived all around the net
> and the commit isn't going away. The risk of losing a release is zero.
That disagrees with the statement made by David Nalley:
"thus any tags under rel, will have their entire commit history."
Without a fixed tag pointing to a commit, AIUI the commit can be
eliminated through a force push.
> I can see the downsides of using rel/ tags though:
> * it can't be reverted and errors can't be corrected (without bugging
> the infra team I guess, but they've more important things to do)
That is deliberate, to avoid the lost commit issue.
> * it's inconsistent with past releases and we probably don't want to
> retag all our repositories
> * it doesn't look great, shorter tags look nicer
> * it's longer to type when checking out tags from the command line
> * it's non standard (never seen that anywhere)
It's standard within the ASF now.
> * it doesn't solve any actual issue
Yes, it does solve an issue - see above.
> * we want fewer steps to our release process, not more
No, we want as few as possible, but no fewer.
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org