Hi Sebb, Le 07/01/2016 04:21, sebb a écrit : > On 7 January 2016 at 01:48, Gilles <gil...@harfang.homelinux.org> wrote: >> On Wed, 6 Jan 2016 18:42:06 +0100, Luc Maisonobe wrote: >>> >>> Le 06/01/2016 15:56, Gilles a écrit : >>>> >>>> Hi. >>>> >>>> I've reread this article (which IIRC was advertised on this list some >>>> time ago): >>>> http://nvie.com/posts/a-successful-git-branching-model/ >>>> >>>> It is quite clear and I think that it would easy to get used to. >>> >>> >>> Yes, it is quite a good model. >>> >>>> Unless there are shortcomings that would prevent its use with the CM >>>> repository, I propose that we adopt it officially, and assume its >>>> nomenclature in order to eventually develop scripts similar to >>>> what is mentioned below. >>> >>> >>> That would be fine with me. One should however be aware that we >>> cannot delete branches in Apache git repository anymore (at least >>> I think this is something that is now enforced). The reason is >>> that history should never be lost, or rewritten. So everything >>> that hits the repository remains there. > > Infra intended this as a temporary measure whilst the implications of > allowing deletes were worked out and a better solution found.
OK. Thanks for the clarification. > > I expect the restriction will be relaxed soon. > >>> >>> Considering this, having very short lived hotfix branches may >>> prove unpractical. I would not like on the other hand having >>> such short lived branches fly around outside of Apache infrastructure >>> (like github or anything), as these would defeat the purpose of >>> preserving history. >>> >>> However, using more topic branches seems good to me. This is what >>> was done for the field-doe (and the branch is still there). >> >> >> Given the "git" model, it would make sense to allow deleting >> branches whose sole purpose is to allow developers to exchange >> work that is experimental. > > Agreed, but the problem is ensuring that the appropriate parts of the > repo are locked down. Yes, and sometimes we can learn from errors. I also had a few cases when I tried something, found it was bad, deleted it to try something else, only to find a few months later that in fact there was still a part I could have reused. But this is a corner case. If you delete something important and not saved elsewhere, you just blame yourself. > >> Deleting a "feature" branch is not deleting history. The code >> would become history only when this branch is merged in >> "development". If the branch is merged at the end, yes, history is preserved. It can be tricky to find again as you don't have a pointer on the tip of the branch, but the commits are there. >> IIUC, you have preserved all the history of your commits when >> merging your work into "master". [By the way, I think that >> it would be better to squash one "feature" into a single >> commit so that it is trivial to figure out whether this >> commit introduced some problem (as is advised in the article >> IIUC). The detailed history of a "feature" work is not >> necessary since even if a bug is uncovered, it is unlikely >> that one will search for a commit to be reverted rather than >> make a new one with the fix! And it will avoid a flood of >> messages to the ML which only code archaeologists would ever >> read.] I could have done both ways. When I proposed this a few weeks ago, it was thought that the history was worth preserving, moreover remembering that these commits are not in the common ancestors of the master branch (they occurred after MATH_3_X was forked). Perhaps next time I will do it at once. Or better perhaps next time we will not have to go through these hops because we can use more straightforward git commands (git cherry-pick and the like). Using the other classical way of squashing commits using git rebase interactive will certainly not be allowed by infra, as this really is a dangerous command and it opens ways to destroy or rewrite history). >> >> So (from the article), >> * the "master" branch is the one from which tags for released >> code are made and is of course "history", >> * the "develop" branch is "history"; >> and those must not be deleted, obviously. >> >> If we want to avoid the proliferation of short-lived branches >> that are also "history" (of hot fixes and releases), we could >> perhaps further simplify the model and have two long-lived >> branches: >> * "hotfix" for hot fixes, and >> * "release" for release candidates. >> In the latter, a tag is enough to indicate the commit that is >> the target of the vote (IIUC). This is basically what was done for the last release. The tag was also signed with my key so it coud be checked by anyone, and its SHA1 id was sent in the vote message. >> [Anyway, this point is fairly moot, as we don't expect many >> hot fixes or releases in CM...] >> >> But the "feature" branches, why keep them? >> The code that is in such a branch will become "history" once >> it is merged into "develop" (and only in that case, if we follow >> the convention). As above, yes if the code is merged, the feature branch could be deleted. >> >> Keeping all those short-lived branches is as if files in the >> "home" directories were archived and the owner would be >> forbidden to delete his own files... >> Or, suppose that I'd create a hypothetical branch, in which I >> would suddenly start to do some crazy stuff to the RNG code... >> Wouldn't we want to be able to delete this ASAP? 8-/ >> >> So, in summary, it is sufficient to enforce a "no delete" policy >> only for the "history"-making branches: "master", "develop", >> "hotfix" and "release". >> We should be allowed to delete anything else (if I did not miss >> anything). > > The problem is determining what must be kept and what is transient. > Commons may agree on only using these 4 branch names, however other > projects may use different names. > > Since Git does not have restrictions on what branch names are used, > this is a non-trivial issue to solve. > > This is really a discussion for Infra. Yes, I think so. I don't know what is the current status of their thoughts about this. best regards, Luc > >> Best, >> Gilles >> >> >>> best regards, >>> Luc >>> >>>> >>>> [...] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
