[gnuastro-devel] [bug #49932] alphabetical and numerical order do not always match

[Mohammad Akhlaghi]

Update of bug #49932 (project gnuastro):

                  Status:                    None => In Progress            
             Assigned to:                    None => boud                   

    _______________________________________________________

Follow-up Comment #2:

Thank you very much Boud, it was an interesting observation and correction.

I wanted to merge it into the main master branch, but there was a complication
in the history. It now looks like this on my system:


*   fdb3983 (boad/master) Merged typos into master
|\  
| *   1903fa7 Merge branch 'master' into typos
| |\  
| |/  
|/|   
* | bc565a5 (HEAD -> master, origin/master) Minor typo corrected in
gnuastro.texi
* | 275a27e Small correction to section crop in ImageCrop
* | 4a0f674 Trivial typos: READMEs, gnuastro.texi
| * f1e4e12 * trivial typos: READMEs, gnuastro.texi
|/  
| * 5d35f4a (boad/non_alphabetical_authors_sort) Missing --numbered option in
git shortlog for generating AUTHORS.
|/  
* 2136295 Minimum sharp PSF spectrum is now an option not macro
* 2dfa164 Corrected bad status usage in wcsp2s and wcss2p


Apparently, you hadn't synced/pulled from the main repo before this commit and
pushing it (and your master branch) to your fork. Because I corrected the
message in the typo commit (originally f1e4e12), its hash (and thus the whole
commit object) was changed to 4a0f674 (ofcourse, the author and date
information haven't changed). The new/corrected commit was pushed to the main
repo, not the original one.

But since you didn't pull from the main repository before the commit, you
merged the original (f1e4e12) typos branch with your master locally on your
system. This has caused this strange history on my system.

The solution to this is that you should never merge your branches with the
master branch yourself. In this workflow, only the main maintainer should
merge with the master branch. After you make the announcement that there is a
branch ready to merge, I will do the merging and push the merged result to the
main repo. Then I will reply/comment on the bug/task, confirming that the
branch has been merged with master.

You can then pull from the main repo and see that the job of merging has been
done and you can simply delete the old branch name. A working example with
explanations is given in the Forking tutorial
<https://www.gnu.org/software/gnuastro/manual/html_node/Forking-tutorial.html>
section of the book.

I also had a comment about the `TODO' in the comments above the Git command:
Fortunately Git does have a mechanism for this (developers with multiple email
addresses) and it is implemented in Gnuastro's .mailmap
<http://git.savannah.gnu.org/cgit/gnuastro.git/tree/.mailmap> file (which is
in the top Gnuastro source directory). The issue currently only occurs for me:
my first commits in Gnuastro were before it was accepted as a GNU project, so
I used a different email.

I also had another comment: Savannah converts any text in the format of `task
#XXXXXX', or `bug #XXXXXX' to a link to the respective bug/task. But in the
previous comment, since you hadn't included the `bug', it hasn't been
converted to a link. 

Sorry for this long comment, as soon as you correct the issue above about the
mixed history (and remove the `.mailmap' issue in the TODO), I will merge it
into master. Maybe the easiest way would be to just clone the full repository
again and make the correction and commit it (You can just copy the
`.git/config' file from the old clone to the new one to have all your remotes
set as before).

Bu the way, I personally agree with your first choice of defining a new bug
report for this issue. The correction is small, but it is specific.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?49932>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/