gnuastro-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gnuastro-devel] Merged NoiseChiselPaper branch with master


From: Mohammad Akhlaghi
Subject: [gnuastro-devel] Merged NoiseChiselPaper branch with master
Date: Fri, 6 May 2016 15:17:09 +0900
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

Dear Gnuastro developers,

The dead-end `NoiseChiselPaper' branch (which contained version 0.0) of the main respository was finally merged with master (using `git merge -s ours'). See the P.S. for the commit message explaining the (historical!) reason behind the existence of this branch and how this merge has fixed the problem without any complications.

The removed branch in the main repo can be removed from your local version with the following command

    git fetch --prune

So, now the main repository only has a `master' branch. Later in the development (as development gets more complicated with more utilities, libraries, and developers) we can introduce more thorough systems for branches in the main repository, for example the "two-phase merge cycle", or the "Large-merging workflows" explained in ProGit:

https://git-scm.com/book/en/v2/Distributed-Git-Maintaining-a-Project#Integrating-Contributed-Work

Cheers,
Mohammad



P.S. Commit message for this merge (5b16c1a):

This is a (very) long overdue merge! The main problem was caused by my lack of experience with Git, combined with the fact that the reproduction pipeline for the NoiseChisel paper (first paper defining Gnuastro, at https://gitlab.com/makhlaghi/NoiseChisel-paper/ ) was actually defined after the paper was accepted for publication. All of these also happened in the last year of my PhD course and when I didn't have much time for a good research into the proper solution.

This caused a complicated situation in the development of Gnuastro because I had made some changes in Gnuastro (and NoiseChisel in particular) ever-since the paper was accepted (which was prior to the idea of a reproduction pipeline). So to make the old results of that paper exactly reproducible in the reproduction pipeline, I created a parallel branch, which only kept the properties needed for the reproduction of the NoiseChisel paper. The final commit in that branch was used in the NoiseChisel paper reproduction pipeline and was tagged as version 0.0. The branch was left as a dead-end/obsolete branch ever since. Work then continued on the main master branch of Gnuastro and a very large number of commits was made. However, keeping this extra obsolete branch in the repository can be very confusing, since all our new features are defined as branches that will later be merged with `master'. So after some searching, the proper solution in Git was found.

Fortunately Git's merge utility has a strategy for such cases (`ours') and in-fact it is also included as one of the examples in its man page: "Merge branch `obsolete' into the current branch, using `ours' merge strategy:"

    git merge -s ours obsolete

From the git-merge man page for this strategy: "the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches". So it was exactly what I should have used back when the 0.0 tag was set. With this merge, Gnuastro no-longer contains an obsolete (dead-end) branch and its future development and maintenance can be much more clear.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]