Skip to content
Snippets Groups Projects

Feature/peakfind refactoring

Merged eric pellegrini requested to merge feature/peakfind_refactoring into develop

Peakfind dialog completed.

Merge request reports

Pipeline #1162 passed

Pipeline passed for a59c292d on feature/peakfind_refactoring

Merged by avatar (Jan 2, 2025 10:11pm UTC)

Loading

Pipeline #1163 passed

Pipeline passed for ea987829 on develop

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • eric pellegrini Enabled an automatic merge when the build for 2466435c succeeds

    Enabled an automatic merge when the build for 2466435c succeeds

  • eric pellegrini Canceled the automatic merge

    Canceled the automatic merge

  • @jmfisher I completed the peakfind dialog refactoring updated with the outcome of #60 (closed) . I finally decided to keep the kernel factory design for the reasons mentioned in #60 (closed).

  • I will test on biodiff data and enable automatic merge provided everything works as usual

  • there is a minor bug (which I believe already existed in develop) which I will fix before merging

  • OK. Good. BTW, I take that merge opportunity to ask you a question about our gitflow implementation. In the present case, I

    • created a new feature namely peakfind-refactoring
    • published it
    • made some commits My concern is when the time has come to merge. As stated before, it is good that we create merge requests each time we want to merge a feature on develop. If I follow the gitflow procedure until the last step, I should normally finish my feature. However, finishing it and pushing to develop will not create a merge request. I have the feeling that introducing a merge request, yet desirable, somewhat breaks the gitflow procedure. What do you think ?
  • as far as I understand, using git flow to finish the feature from command line is just a macro for git merge. In that case, it is definitely better to create a gitlab merge request and finish the feature this way (as we are doing now). From the point of view of the git log it should be identical, but we get the advantage of having a gitlab merge request page where we can have discussions.

    Also, for minor bugfixes (which are labeled bugfix rather than feature) I am ok with just doing automatic merge after successful CI build.

  • Jonathan Fisher Added 2 commits:

    Added 2 commits:

    • b901143c - bugfix: getInterpolatedState segfault when called on last frame
    • a59c292d - fix bug in DeltaKernel constructor

    Compare with previous version

  • Jonathan Fisher Enabled an automatic merge when the build for a59c292d succeeds

    Enabled an automatic merge when the build for a59c292d succeeds

  • Jonathan Fisher Status changed to merged

    Status changed to merged

  • Jonathan Fisher Mentioned in commit ea987829

    Mentioned in commit ea987829

  • I agree that for bugfix there is no need to prompt for merging. BTW, you mentionned bugfix as a kind of special case of feature branch. Does it mean that you do not use the git flow package ? That would explain the occurence of bugfix- branches in the repository that I wanted to create.

    Edited by eric pellegrini
  • git flow, or at least my version of it, supports branches tagged as feature, bugfix, release, hotfix, and support. So bugfix is a type of branch distinct from feature. They are named starting with bugfix/.

    I recently pushed a bugfix branch and I had to modify the gitlab-ci yaml because it was building only master/develop/feature, so I added bugfix builds as well.

    Edited by Jonathan Fisher
  • that's normal because, I just checked, the git flow for trusty does not provide the bugfix branch name. Ony, feature, release, hotfix and support.

  • I use arch for development so my version if git flow is without a doubt newer. If you don't mind please name bugfix branches as bugfix/* manually without using git flow. Or just update to a newer git flow on your development PC.

  • I didn't try, but it may even be possible to simply add bugfix branches by modifying the git flow config without updating to a newer version.

  • no problem I will find a way. Indeed, I was really thinking that this kind of branch was missing

  • After doing a bit of searching I realized that the difference is that I am using the AVH edition of git flow. See https://github.com/petervanderdoes/gitflow-avh. I am using the arch package but it should be easy to build from source if there is no ubuntu package available.

  • thanks Jonathan for the hint

  • I just added a link to AVH edition on the wiki page. If you have any trouble installing on ubuntu please add some instructions to the wiki.

    Edited by Jonathan Fisher
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
Please register or sign in to reply
Loading