On Thu, 7 Jan 2016 21:29:48 +0100, Luc Maisonobe wrote:
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.
Can't we decide here about the convention which we adopt for
development (i.e. the model discussed in the blog post referred
to above)?
I mean:
* Do we stop updating "master" with ongoing work (i.e. only
allowing released code to be merged into it)?
* Do we create a "development" branch (consequence of "Yes" to
the above question)?
* Do we create a feature branch for each new feature that we'd
like to allow other people to look at and review and test before
it is included in the "development" branch?
* What is the OK convention for directly updating "development"
(i.e. for a bug fix)?
* What is the OK convention for merging a feature branch?
* ...
* Do we follow the same approach for MATH_3_X?
This links to my other post about the development management
(or any other word or expression that is meant to clarify
what developers can expect in the coming months):
* Do we continue maintaining "MATH_3_X" beyond bug-fixing (as was
done for the previous cycle with backporting)?
* "Yes" or "no" to the above is likely to have an impact on what
people think is fair game for 4.0. And for choosing a target
Java version (which in turn will have a big impact on how
likely the library is going to evolve.
Hopefully we can advance before we know whether we'll be allowed
to delete the temporary branches...
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
