<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
On 02/15/2011 11:54 PM, Robert Špalek wrote:
<blockquote
cite="mid:AANLkTi=o22sOJMWNKWJwvCdygLYSvibF-e00bePfEQ4V@mail.gmail.com"
type="cite">On Tue, Feb 15, 2011 at 8:17 AM, Max Horn <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:max@quendi.de">max@quendi.de</a>></span>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
BUT watch out, there is a big caveat to that: If you do this,
things will work nicely most of the time. But not always:
Sometimes, git is not able to perform the rebase on its own.
If Filippos' commit had modified the same files as Arnaud's,
in the same lines, then git would not have known how to handle
this. so then, the rebase would have failed. If you had only a
handful of local commits, this is usually not so bad, and you
can recover from this using the information git prints on the
command line (basically, you manually fix the conflicts; then
"git add" the conflicted files; then run "git rebase
--continue"). But sometimes it *does* get problematic, and
then you might need some experience, or need to read up on
this (or ask for help from folks in #scummvm) to recover.<br>
<br>
</blockquote>
<div>in my experience, rebase is only good to do when being
trivial or almost trivial. if a rebase conflict occurs, then
it's usually better in the long term to merge, because merges
keep in the history the following two actions separate:</div>
<div><br>
</div>
<div>(1) programming and debugging your feature</div>
<div>(2) solving a merge conflict</div>
</div>
<div><br>
</div>
<div>these action were always separate and the benefit of having
them separate even in the repository is usually larger than the
extra mess introduced by nonlinearities.</div>
<div><br>
</div>
if one performs rebase and continues development without thorough
testing, and the rebase has brought some subtle bug that will be
discovered much later, then there will be no copy of a working
version of the commit in the repository anymore (!), only a
screwed one after botched rebase. however, if one instead
performs merge, then even if he finds a bug later, it is possible
to check out the earlier unmerged version and merge it again, now
properly. it's even possible to display a diff between the
original and merged version.
<div>
<br>
</div>
<div>essentially this is the workflow when ones uses feature
branches, but I'm advocating this approach even for single
commits when the rebase is not trivial.<br>
</div>
</blockquote>
<br>
That all seems very sensible to me. I would rather think we should
go this approach than forcing to rebase for bigger changes, at least
it seems much more appealing to have a better way of testing on
whether the initial change or some other change in the main
development line caused any problems than to have a linear history
and no real good way of testing that.<br>
<br>
// Johannes<br>
</body>
</html>