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. 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. > Deleting a "feature" branch is not deleting history. The code > would become history only when this branch is merged in > "development". > 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.] > > 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). > [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). > > 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. > 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
