Re: State of the repository conversion

[Steinar Bang]

>>>>> Florian Weimer <address@hidden>:

> This complicates the history of the master branch.  It is not clear if
> it adds any useful information,

It makes later merges more likely to only contain the relevant changes.

And the merge happens at a time where I can remember what was done and
what the changes should be.

That is useful information the way I see it.

> especially if there is no expectation of ever doing development on
> release branches and merge this development back to the master branch
> later.

Like I said, the pattern that works well for me, and gives a nice
history on the file level, and the "git blame" level, is to do the fix
on the earliest release branch were it is relevant, and then merge it
forward. 

But that requires that the master is kept in sync with cherry picks
applied to the release branches.  If it isn't, the merge results can be
strange, and it can be challenging to see what has happened (not
impossible, and as long as nothing is committed or pushed, recovery is
easy).

> Tool support is generally better if you make the change in the oldest
> supported release branch and merge that forward, but in practice, this
> doesn't work that well.  Often, you don't know for sure what the
> oldest release branch that needs the change is.

True.  So one always end up with some cherry picks. 

> And from a general engineering point of view, it is better to develop
> the best fix possible on the master branch, test it, and then start
> backporting it, taking shortcuts as necessary.

Er... no.  It's not possible to generalize like that. For one particular
fix this may have been the right approach.  For another it may not.

Basically, the way important release fixes have come to me, they have
been reported as bugs against the released version, and then I naturally
start with the release branch for that version, and figure out the
problem, and do the fix.

Once that fix is complete and pushed (released as a patch, or as a new
version or whatever, and sent to the customer), I look at if the fix is
relevant in master and later releases.  If the code has changed little
enough that a merge seems to be possible, I merge the older release
branches forward.

In many fixes, this is the case.

If the code has changed so much that a merge isn't possible I try to
figure out if the bug is still present in the master branch, and if it
is, how to best fix it (it may be a completely different fix to what was
done in the release branch).

> If you do it in the other order, you tend to end up with a suboptimal
> change in the master branch.

Only if you merge blindly and assume that the fix will be correct for
all versions.

> And the development history becomes really, really complicated, too.

In what way? Could you be specific?