You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Luc Maisonobe <lu...@spaceroots.org> on 2016/01/06 14:49:09 UTC
[math] big batch of commits coming
Hi all,
As discussed a few weeks ago, I ported the new field-based ode feature
from MATH_3_X to master. I was finally able to do that without losing
the about hundred commits history, by replaying them with some scripting.
In case this is of interest for some of you, here is how I managed to
do that.
First, I had to find the commit lists in the MATH_3_X branch that
were of interest, concentrating only on the real code change commits
(i.e. ignoring the merge commits that occurred two or three time
between the topic branch field-ode and MATH_3_X branch). This was
done by identifying a start and an end commit and listing the
intermediate ones with the following command:
git rev-list ^4685d03~1 b5276e9 --author=Luc --max-parents=1 --reverse
I put this list in a file for later looping over this.
Then I wrote a small script that extracted from one commit identifier
the commit message in one temporary file, and the diff in another
temporary file, with all math3 strings replaced with math4. The
diff was then applied, spurious .orig and .rej files eliminated, and
the commit performed with the same message as the original commit. Here
are the few commands:
git show --pretty=format:"%s%n%n%b" --no-patch $1 \
> $tmpdir/commit-message
git show --pretty=format:"" $1 | sed 's,math3,math4,g' \
> $tmpdir/commit-patch
patch -p1 < $tmpdir/commit-patch && |
find . -name '*.orig' -exec rm {} \; \
-o -name '*.rej' -exec rm {} \; && \
git add . && \
git commit -F $tmpdir/commit-message
It worked quite well, with only a few glitches that forced me to
interrupt the loop, remove a few commits, correct the command, and
restart the loop.
After that, I replayed a number of additional commits picked up
individually one at a time, for commits that occurred more recently
than the range before and were interspersed with other commits in
the MATH_3_X branch. So at the end, I had 101 commits.
All of this was done on a local tmp branch, so I coud roll back and
restart from scratch easily if anything went wrong. When I was certain
that this tmp branch was complete, I merged it into master.
You will see the last step in a few minutes, with a git push that will
update master with the 101 commits that are in the pipe. I'm sorry for
the noise.
At the end, we will have a master branch with the same feature as the
MATH_3_X branch, and a full history of the development of this feature.
best regards,
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Feature development model
Posted by Gilles <gi...@harfang.homelinux.org>.
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 <gi...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Feature development model
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Hi Sebb,
Le 07/01/2016 04:21, sebb a écrit :
> On 7 January 2016 at 01:48, Gilles <gi...@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-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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Feature development model
Posted by sebb <se...@gmail.com>.
On 7 January 2016 at 01:48, Gilles <gi...@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-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: [Math] Feature development model
Posted by Phil Steitz <ph...@gmail.com>.
On Wed, Jan 6, 2016 at 6:48 PM, Gilles <gi...@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.
>>
>> 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).
>>
>
I am OK with all of this as long as we have incremental development
visibility (as we did with the field-ode stuff). The blog post said
something about feature branches just living on developer or subteam repos
and IIUC that would not give the visibility that I at least would like to
have. I would also like to as much as possible keep the feature branches
not too huge / long-running. We also want it to be very easy for
non-committer contributors to collaborate with committers on features, so
they need to be able submit PRs against these. I assume all that is easy.
>
> 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.
>
> Deleting a "feature" branch is not deleting history. The code
> would become history only when this branch is merged in
> "development".
>
Right, and per sebb's comments, this will not be a problem from ASF policy
standpoint. The key is to keep these merges from getting too monstrously
large, IMO.
> 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 think I agree here; but need more experience with the model here to know
for sure. I will be more comfortable with it if the feature commits are
not that big and they include good commit messages.
>
> 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.
>
Also, CI runs against "develop" and it is the target for feature branch
merges.
>
> 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
>
I don't think we need that. We can always create release branches from
"develop."
> * "release" for release candidates.
>
+1 for always using release branches (what Luc just did)
> 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).
>
I think you are right there, modulo comment on feature branches not getting
too big.
Phil
>
> Best,
> Gilles
>
>
> best regards,
>> Luc
>>
>>
>>> [...]
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Math] Feature development model
Posted by Gilles <gi...@harfang.homelinux.org>.
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.
>
> 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.
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).
Best,
Gilles
> best regards,
> Luc
>
>>
>> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Feature development model (Was: big batch of commits
coming)
Posted by Luc Maisonobe <lu...@spaceroots.org>.
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.
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).
best regards,
Luc
>
>
> Best regards,
> Gilles
>
> On Wed, 6 Jan 2016 14:49:09 +0100, Luc Maisonobe wrote:
>> Hi all,
>>
>> As discussed a few weeks ago, I ported the new field-based ode feature
>> from MATH_3_X to master. I was finally able to do that without losing
>> the about hundred commits history, by replaying them with some scripting.
>>
>> In case this is of interest for some of you, here is how I managed to
>> do that.
>>
>> First, I had to find the commit lists in the MATH_3_X branch that
>> were of interest, concentrating only on the real code change commits
>> (i.e. ignoring the merge commits that occurred two or three time
>> between the topic branch field-ode and MATH_3_X branch). This was
>> done by identifying a start and an end commit and listing the
>> intermediate ones with the following command:
>>
>> git rev-list ^4685d03~1 b5276e9 --author=Luc --max-parents=1 --reverse
>>
>> I put this list in a file for later looping over this.
>>
>> Then I wrote a small script that extracted from one commit identifier
>> the commit message in one temporary file, and the diff in another
>> temporary file, with all math3 strings replaced with math4. The
>> diff was then applied, spurious .orig and .rej files eliminated, and
>> the commit performed with the same message as the original commit. Here
>> are the few commands:
>>
>> git show --pretty=format:"%s%n%n%b" --no-patch $1 \
>> > $tmpdir/commit-message
>> git show --pretty=format:"" $1 | sed 's,math3,math4,g' \
>> > $tmpdir/commit-patch
>>
>> patch -p1 < $tmpdir/commit-patch && |
>> find . -name '*.orig' -exec rm {} \; \
>> -o -name '*.rej' -exec rm {} \; && \
>> git add . && \
>> git commit -F $tmpdir/commit-message
>>
>> It worked quite well, with only a few glitches that forced me to
>> interrupt the loop, remove a few commits, correct the command, and
>> restart the loop.
>>
>> After that, I replayed a number of additional commits picked up
>> individually one at a time, for commits that occurred more recently
>> than the range before and were interspersed with other commits in
>> the MATH_3_X branch. So at the end, I had 101 commits.
>>
>> All of this was done on a local tmp branch, so I coud roll back and
>> restart from scratch easily if anything went wrong. When I was certain
>> that this tmp branch was complete, I merged it into master.
>>
>> You will see the last step in a few minutes, with a git push that will
>> update master with the 101 commits that are in the pipe. I'm sorry for
>> the noise.
>>
>> At the end, we will have a master branch with the same feature as the
>> MATH_3_X branch, and a full history of the development of this feature.
>>
>> best regards,
>> Luc
>
>
> ---------------------------------------------------------------------
> 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
[Math] Feature development model (Was: big batch of commits coming)
Posted by Gilles <gi...@harfang.homelinux.org>.
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.
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.
Best regards,
Gilles
On Wed, 6 Jan 2016 14:49:09 +0100, Luc Maisonobe wrote:
> Hi all,
>
> As discussed a few weeks ago, I ported the new field-based ode
> feature
> from MATH_3_X to master. I was finally able to do that without losing
> the about hundred commits history, by replaying them with some
> scripting.
>
> In case this is of interest for some of you, here is how I managed to
> do that.
>
> First, I had to find the commit lists in the MATH_3_X branch that
> were of interest, concentrating only on the real code change commits
> (i.e. ignoring the merge commits that occurred two or three time
> between the topic branch field-ode and MATH_3_X branch). This was
> done by identifying a start and an end commit and listing the
> intermediate ones with the following command:
>
> git rev-list ^4685d03~1 b5276e9 --author=Luc --max-parents=1
> --reverse
>
> I put this list in a file for later looping over this.
>
> Then I wrote a small script that extracted from one commit identifier
> the commit message in one temporary file, and the diff in another
> temporary file, with all math3 strings replaced with math4. The
> diff was then applied, spurious .orig and .rej files eliminated, and
> the commit performed with the same message as the original commit.
> Here
> are the few commands:
>
> git show --pretty=format:"%s%n%n%b" --no-patch $1 \
> > $tmpdir/commit-message
> git show --pretty=format:"" $1 | sed 's,math3,math4,g' \
> > $tmpdir/commit-patch
>
> patch -p1 < $tmpdir/commit-patch && |
> find . -name '*.orig' -exec rm {} \; \
> -o -name '*.rej' -exec rm {} \; && \
> git add . && \
> git commit -F $tmpdir/commit-message
>
> It worked quite well, with only a few glitches that forced me to
> interrupt the loop, remove a few commits, correct the command, and
> restart the loop.
>
> After that, I replayed a number of additional commits picked up
> individually one at a time, for commits that occurred more recently
> than the range before and were interspersed with other commits in
> the MATH_3_X branch. So at the end, I had 101 commits.
>
> All of this was done on a local tmp branch, so I coud roll back and
> restart from scratch easily if anything went wrong. When I was
> certain
> that this tmp branch was complete, I merged it into master.
>
> You will see the last step in a few minutes, with a git push that
> will
> update master with the 101 commits that are in the pipe. I'm sorry
> for
> the noise.
>
> At the end, we will have a master branch with the same feature as the
> MATH_3_X branch, and a full history of the development of this
> feature.
>
> best regards,
> Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] big batch of commits coming
Posted by Gary Gregory <ga...@gmail.com>.
Very cool!
Gary
On Wed, Jan 6, 2016 at 5:49 AM, Luc Maisonobe <lu...@spaceroots.org> wrote:
> Hi all,
>
> As discussed a few weeks ago, I ported the new field-based ode feature
> from MATH_3_X to master. I was finally able to do that without losing
> the about hundred commits history, by replaying them with some scripting.
>
> In case this is of interest for some of you, here is how I managed to
> do that.
>
> First, I had to find the commit lists in the MATH_3_X branch that
> were of interest, concentrating only on the real code change commits
> (i.e. ignoring the merge commits that occurred two or three time
> between the topic branch field-ode and MATH_3_X branch). This was
> done by identifying a start and an end commit and listing the
> intermediate ones with the following command:
>
> git rev-list ^4685d03~1 b5276e9 --author=Luc --max-parents=1 --reverse
>
> I put this list in a file for later looping over this.
>
> Then I wrote a small script that extracted from one commit identifier
> the commit message in one temporary file, and the diff in another
> temporary file, with all math3 strings replaced with math4. The
> diff was then applied, spurious .orig and .rej files eliminated, and
> the commit performed with the same message as the original commit. Here
> are the few commands:
>
> git show --pretty=format:"%s%n%n%b" --no-patch $1 \
> > $tmpdir/commit-message
> git show --pretty=format:"" $1 | sed 's,math3,math4,g' \
> > $tmpdir/commit-patch
>
> patch -p1 < $tmpdir/commit-patch && |
> find . -name '*.orig' -exec rm {} \; \
> -o -name '*.rej' -exec rm {} \; && \
> git add . && \
> git commit -F $tmpdir/commit-message
>
> It worked quite well, with only a few glitches that forced me to
> interrupt the loop, remove a few commits, correct the command, and
> restart the loop.
>
> After that, I replayed a number of additional commits picked up
> individually one at a time, for commits that occurred more recently
> than the range before and were interspersed with other commits in
> the MATH_3_X branch. So at the end, I had 101 commits.
>
> All of this was done on a local tmp branch, so I coud roll back and
> restart from scratch easily if anything went wrong. When I was certain
> that this tmp branch was complete, I merged it into master.
>
> You will see the last step in a few minutes, with a git push that will
> update master with the 101 commits that are in the pipe. I'm sorry for
> the noise.
>
> At the end, we will have a master branch with the same feature as the
> MATH_3_X branch, and a full history of the development of this feature.
>
> best regards,
> Luc
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory