[gmx-developers] Major code reorganization in git coming up

[Mark Abraham]

On 5/01/2011 10:50 PM, Erik Lindahl wrote:
> Hi,
>
> On Jan 5, 2011, at 4:27 AM, Mark Abraham wrote:
>
>>
>>
>> On 12/31/10, *Erik Lindahl * <erik at kth.se <mailto:erik at kth.se>> wrote:
>>> Hi!
>>>
>>> We figured we'd celebrate the upcoming new year with some major 
>>> changes in the git development branch, consisting primarily of C++ 
>>> support and a more modular organization of files.
>>> This is a gradual process, so this mail is a bit of a 
>>> warning-message that the master/development branch might have some 
>>> issues with compilers/build environments the next couple of weeks.
>>
>> Wouldn't creating an "unstable" branch be a better approach to a 
>> known lengthy period of instability? Now people working off (or 
>> fixing) the master branch don't have to change their workflows at 
>> all. If bugfix commits or merges from release-4-5-patches happen into 
>> master, that's great, and don't affect unstable at all. git branches 
>> are lightweight and seem correct to use on almost any excuse.
>>
>> Later, once "unstable" has matured a bit,
>>
>> git rebase master
>> git checkout master
>> git merge unstable
>>
>> will create the impression that development on master was seamless. 
>> No ugly "merge commits", and the "unstable" branch just quietly goes 
>> away afterwards.
>
> That would work fine if master hadn't changed at all in the mean time.
>
> The problem is that in practice there will be lots changes in both 
> branches, with the big architectural changes happening in the 
> "unstable" branch, and we are then forcing the people already doing 
> that work to spend lots of time either on continuously merging in all 
> changes from the master branch (which will be really nasty when both 
> files and the organization is different), or even worse do a huge 
> amount of work for a final single merge when all existing code in 
> master would have to be ported to the architecture new unstable branch 
> first.

OK.

Wow. I'd believed that git would cope well with this kind of code 
refactoring because it is supposed to track content, not files. So a 
code movement in one branch would merge automatically with a change to 
the same code in its original location in another branch. This was not 
true, in a variety of simple tests I did.

I Googled a bit, and found 
http://stackoverflow.com/questions/1897585/how-does-git-handle-merging-code-that-was-moved-to-a-different-file 
and 
http://stackoverflow.com/questions/3491270/git-merge-apply-changes-to-code-that-moved-to-a-different-file 
which seem to agree that git is not going to cope well. I also found 
http://codicesoftware.blogspot.com/2010/07/xmerge-to-merge-refactored-code.html 
who have a tool that they claim copes with the problem. There's still 
human interaction, but at least you don't have to go and search for the 
new location of the old content to resolve the conflict.

Using git blame -C to track how content has moved between files works 
better if you use separate commits for code movement and code changes, 
and we should certainly be doing that.

Back on the topic of my suggestion, I'd still encourage the use of an 
unstable branch *together* with discouraging of the use of master. If 
nobody does update master, then there is no difference. There will still 
be a headache when cross-porting bugfixes, etc. from release-4-5-patches 
into unstable when it approaches maturity. However, if someone who 
hasn't read their email (or just forgets) does commit to master, then at 
least they don't create an extra problem for themselves or anybody else 
then or later. When unstable matures, release-4-5-patches is merged into 
master, and the result merged (via the expected headache) into unstable, 
which becomes the new master.

Basically, I'd rather rely on a change of name enforcing a degree of 
isolation, than people remembering things not really connected to their 
daily doings. :-)

Cheers,

Mark

> So, while I see the problem it is ultimately a question of balance, 
> and we don't want to push even more work on the people already doing 
> the heavy lifting!
>
> Second, I'd like to stress that right now there isn't really any 
> killer functionality in master over release-4-5-patches (well, apart 
> from C++ as of this week :-), so we already have a stable branch that 
> won't move much in the shape of release-4-5-patches!
>
> If it turns out that the master branch takes longer to stabilize than 
> expected and there are new features we all want to use, we can easily 
> create a 4.6 release based on the current patches branch!
>
> Cheers,
>
> Erik
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20110106/f37658c5/attachment.html>