----- Original Message ----- From: David van der Spoel &lt;spoel@xray.bmc.uu.se&gt; Date: Thursday, August 26, 2010 16:59 Subject: Re: [gmx-developers] Git master broken To: Discussion list for GROMACS development &lt;gmx-developers@gromacs.org&gt; &gt; On 2010-08-26 06.21, Mark Abraham wrote: &gt; &gt;----- Original Message ----- &gt; &gt;From: Christoph Junghans &lt;junghans@mpip-mainz.mpg.de&gt; &gt; &gt;Date: Thursday, August 26, 2010 1:57 &gt; &gt;Subject: Re: [gmx-developers] Git master broken &gt; &gt;To: Discussion list for GROMACS development &lt;gmx- &gt; developers@gromacs.org&gt;&gt; &gt; &gt; &gt; Hi, &gt; &gt; &gt; &gt; &gt; &gt; the merge was not 100% trivial, there were two simple conflicts &gt; &gt; &gt; due to a define renaming in include/vec.h and a argument  &gt; change in &gt; &gt; &gt; split of include/string2.h, which only happened in the  &gt; master branch. &gt; &gt; &gt; That is why I committed it with the standard commit message. &gt; &gt; &gt; &gt;"git log -p 5e3473a" has a merge commit message, but has new  &gt; content as &gt; &gt;well. This fools some parts of git-log into not showing that new &gt; &gt;content. The graphical depiction in gitk on master branch makes this &gt; &gt;clear too... that commit forms a single thread of development  &gt; until DvdS &gt; &gt;tried to merge it. &gt; &gt; &gt; &gt;Anyone who's done development work on either master or &gt; &gt;release-4-5-patches might have this kind of problem at some  &gt; point. Only &gt; &gt;if your development footprint interacts with current progress  &gt; on will &gt; &gt;you have an issue, and there's no getting around having to  &gt; resolve merge &gt; &gt;conflicts regardless of the branch you're on. Things are less  &gt; hairy if &gt; &gt;people know which branch is supposed to get updated (currently, &gt; &gt;release-4-5-patches). Having started work from master (say) and &gt; &gt;committed your present work to your private copy of the master  &gt; branch,&gt;coping strategies for merging your material into release- &gt; 4-5-patches &gt; &gt;include: &gt; &gt; &gt; &gt;* Use "git rebase release-4-5-patches" to switch the base of that &gt; &gt;private branch from master to release-4-5-patches. You will  &gt; still have &gt; &gt;to resolve merge conflicts, but the result will be immediately  &gt; ready to &gt; &gt;push into origin/release-4-5-patches. [IMO the most elegant strategy, &gt; &gt;because there's only a single merge, and pulling future updates  &gt; will be &gt; &gt;easy] &gt;  &gt; Thanks for clarifications Mark. &gt;  &gt; Just to make this exquisitely clear (maybe I misunderstood you):  &gt; we should NOT merge the master branch into the release-4-5- &gt; patches branch, because there is some new stuff there already. You understood me right, but I made a poor starting assumption. If there's stuff in master that does not belong in 4.5, then my second and third strategies are invalid. git rebase is an extremely good tool for all many of interesting things (editing local commit history, squashing and expanding commits) Mark &nbsp; &gt; About updating the master branch with release-4-5-patches: In  &gt; general it seems good if the branches don't diverge more than  &gt; necessary due to new code, hence the presumably bug-fix-only  &gt; changes in 4.5 should be propagated to master. Rossen has  &gt; described this quite clear on the website, including an example  &gt; of what to do when you do not want to merge everything. Yes. Mark &nbsp; &gt; &gt; &gt; &gt;* "git pull master" (resolve conflicts), then "git pull &gt; &gt;release-4-5-patches" (resolve conflicts), then merge into &gt; &gt;release-4-5-patches trivially. [IMO this is more work and  &gt; creates a more &gt; &gt;cluttered development history, but depending on the nature of the &gt; &gt;conflicts, the two merging stages might be conceptually simpler  &gt; than the &gt; &gt;one-stage merge above.] &gt; &gt; &gt; &gt;* Merge release-4-5-patches into master, then "git pull master"  &gt; (resolve&gt;conflicts), then merge into release-4-5-patches. [IMO  &gt; ugly, but I can't &gt; &gt;think of a technical flaw] &gt; &gt; &gt; &gt; &gt; I just did the merge, because the master branch missed a header &gt; &gt; &gt; of some kernel, which was fixed in 4.5 branch. After the  &gt; merge I &gt; &gt; &gt; did a build check and it worked, so this was not a build break. &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Concerning the current merge policy: &gt; &gt; &gt; I think the problem by now is that the main work happens on the &gt; &gt; &gt; 4.5 branch and this has to be merged into the master branch &gt; &gt; &gt; immediately. Otherwise the first one, who wants to merge &gt; &gt; &gt; something in the master branch, in the above case me, has to &gt; &gt; &gt; decide about all the 4.5 changes of all the other  &gt; developers. At &gt; &gt; &gt; the current point of development this is not a big deal, because &gt; &gt; &gt; master and 4.5 are not very different. &gt; &gt; &gt; &gt;Work on release-4-5-patches doesn't have to be merged into master &gt; &gt;immediately, absent some artificial policy. In fact, if nobody's &gt; &gt;committing to master then there's no reason to merge to master  &gt; at all, &gt; &gt;and there's no reason to have branched. However, branching is  &gt; easy and &gt; &gt;lightweight and should be encouraged. &gt; &gt; &gt; &gt;It must be noted that the merge conflict problem occurs  &gt; independently of &gt; &gt;whether branching occurred. Here, Christoph wanted to do: &gt; &gt; &gt; &gt;diff --git a/include/resall.h b/include/resall.h &gt; &gt;index f4e547e..4349551 100644 &gt; &gt;--- a/include/resall.h &gt; &gt;+++ b/include/resall.h &gt; &gt;@@ -45,18 +45,18 @@ &gt; &gt;extern "C" { &gt; &gt;#endif &gt; &gt; &gt; &gt;-extern t_restp *search_rtp(const char *key,int nrtp,t_restp rtp[]); &gt; &gt;+t_restp *search_rtp(const char *key,int nrtp,t_restp rtp[]); &gt; &gt;/* Search for an entry in the rtp database */ &gt; &gt; &gt; &gt;and Berk wanted to do &gt; &gt; &gt; &gt;diff --git a/include/resall.h b/include/resall.h &gt; &gt;index 4349551..e23f808 100644 &gt; &gt;--- a/include/resall.h &gt; &gt;+++ b/include/resall.h &gt; &gt;@@ -45,8 +45,16 @@ &gt; &gt;extern "C" { &gt; &gt;#endif &gt; &gt; &gt; &gt;-t_restp *search_rtp(const char *key,int nrtp,t_restp rtp[]); &gt; &gt;-/* Search for an entry in the rtp database */ &gt; &gt;+char *search_rtp(const char *key,int nrtp,t_restp rtp[]); &gt; &gt; &gt; &gt;Now that's trivial to merge with a word-based diff (change 'extern &gt; &gt;t_restp *' to 'char *' by the two stages of "remove 'extern'" and &gt; &gt;"change 't_restp' to 'char'"), but the default diff is line- &gt; based. Even &gt; &gt;if there had never been a release-4-5-patches branch, whoever  &gt; got their &gt; &gt;commit in first was home free, and the other would have to have  &gt; resolved&gt;this merge. &gt; &gt; &gt; &gt; &gt; However, what still puzzles me is the origin of the  &gt; conflicts in &gt; &gt; &gt; the case of David's merge. For human eyes most of them look &gt; &gt; &gt; trivial, but git doesn't get it. &gt; &gt; &gt; &gt;I hope I helped there. &gt; &gt; &gt; &gt;Mark &gt; &gt; &gt;  &gt;  &gt; --  &gt; David van der Spoel, Ph.D., Professor of Biology &gt; Dept. of Cell &amp; Molec. Biol., Uppsala University. &gt; Box 596, 75124 Uppsala, Sweden. Phone:        +46184714205. &gt; spoel@xray.bmc.uu.se&nbsp;&nbsp;&nbsp; http://folding.bmc.uu.se &gt; --  &gt; gmx-developers mailing list &gt; gmx-developers@gromacs.org &gt; http://lists.gromacs.org/mailman/listinfo/gmx-developers &gt; Please don't post (un)subscribe requests to the list. Use the  &gt; www interface or send it to gmx-developers-request@gromacs.org.