On 10/25/12 13:36 , Bernd Machenschalk wrote: >> On 22.10.12 20:28, Nicolás Alvarez wrote: >> (ugh, they are still using that stupid checkin_notes file?) > > Yes they do. Hopefully only until they realize that this _must_ unavoidably > cause conflicts in every merge or cherry-pick they try. > > Seriously: drop that file. The information meant to be in it is redundant at > best, in reality less reliable than what's available int the SCM (that's > what an SCM tool is made for, right?) and it generates unnecessary > dependencies between commits that every SCM guideline I came across > recommends to > avoid.
Yes, please! The file is useless anyway and it hinders the SCM workflow. Have a look at your merges so far: 4f422d5, e273e4f, 22fe7a0. All of them had a merge conflict in that file -- which is to be expected as you all make your updates at the top of the file. The same is true for cherry-pick'ing which most likely won't work if the commit of interest contains checkin_notes as an unrelated artifact. Honestly, use the commit messages for what they're meant for. When you want to see the history of a particular file you'll use "git log" or a GUI doing the same. When you want to see what happened in a file you'll use "git blame" or a GUI. If you need a change log exported to accompany your next release you'll use "git log" as well. All of that just depends on proper commit messages. In no case a separate file will help here, but it'll make things more tedious. It will even hinder frequent commits as you'll always have to edit an additional file for no practical benefit. For the potential argument that you want to keep the change log separate from the SCM tool: did you ever loose history because you switched to another SCM system? No. Best, Oliver _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
