<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 5/01/2011 10:50 PM, Erik Lindahl wrote:
<blockquote
cite="mid:1998D7CF-3770-4973-8AEB-3022241A8EF2@cbr.su.se"
type="cite">Hi,
<div><br>
<div>
<div>On Jan 5, 2011, at 4:27 AM, Mark Abraham wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite"><br>
<br>
<span>On 12/31/10, <b class="name">Erik Lindahl </b> <<a
moz-do-not-send="true" href="mailto:erik@kth.se">erik@kth.se</a>>
wrote:</span>
<blockquote
cite="mid:E2F92382-D4D9-49ED-A2E6-729164C86C6C@kth.se"
class="iwcQuote" style="border-left: 1px solid rgb(0, 0,
255); padding-left: 13px; margin-left: 0pt;" type="cite">
<div class="mimepart text plain">Hi!<br>
<br>
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.<br>
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.</div>
</blockquote>
<br>
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.</blockquote>
<blockquote type="cite"><br>
Later, once "unstable" has matured a bit, <br>
<br>
git rebase master<br>
git checkout master<br>
git merge unstable<br>
<br>
will create the impression that development on master was
seamless. No ugly "merge commits", and the "unstable" branch
just quietly goes away afterwards.<br>
</blockquote>
<div><br>
</div>
<div>That would work fine if master hadn't changed at all in
the mean time.</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<br>
OK. <br>
<br>
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.<br>
<br>
I Googled a bit, and found
<a class="moz-txt-link-freetext" href="http://stackoverflow.com/questions/1897585/how-does-git-handle-merging-code-that-was-moved-to-a-different-file">http://stackoverflow.com/questions/1897585/how-does-git-handle-merging-code-that-was-moved-to-a-different-file</a>
and
<a class="moz-txt-link-freetext" href="http://stackoverflow.com/questions/3491270/git-merge-apply-changes-to-code-that-moved-to-a-different-file">http://stackoverflow.com/questions/3491270/git-merge-apply-changes-to-code-that-moved-to-a-different-file</a>
which seem to agree that git is not going to cope well. I also found
<a class="moz-txt-link-freetext" href="http://codicesoftware.blogspot.com/2010/07/xmerge-to-merge-refactored-code.html">http://codicesoftware.blogspot.com/2010/07/xmerge-to-merge-refactored-code.html</a>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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. :-)<br>
<br>
Cheers,<br>
<br>
Mark<br>
<br>
<blockquote
cite="mid:1998D7CF-3770-4973-8AEB-3022241A8EF2@cbr.su.se"
type="cite">
<div>
<div>
<div>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!</div>
<div><br>
</div>
<div>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! </div>
<div><br>
</div>
<div>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!</div>
<div><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>Erik</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>